* Posts by Peter

2 publicly visible posts • joined 15 Dec 2008

Google hints at the End of Net Neutrality

Peter
Alert

@prathlev

The article has been edited now, which messes up my paragraph reference.

Anyway, I am commenting on the article and one paragraph specifically, not the author. I don't care who he is, if his written argument doesn't stack up, his experience, title, or reputation are irrelevant. I was not 'assuming' he was wrong in that paragraph, I was saying he *is* wrong.

re your paragraph:

"Wether this should be considered "breaking the rules" with regard to NN is an open question. Does NN prohibit only the use of DiffServ classification and prioritisation? Is the "special treatment" only against NN rules when you would clearly prioritise traffic *at the expense of other traffic*?"

You make the same mistake Richard did. There is no 'special treatment', all the packets are 'treated' exactly the same *when they reach a router*. It just so happens that as the Google cache is close to the destination device MORE google packets get onto congested links. Look, if I download an HD Video and a webpage at the same time, I flood my cable connection with Video packets, but I don't accuse the Video stream of being 'prioritised' over the web-page. If I download two videos, one hosted in my country and one hosted in another I don't accuse the local country video host of being prioritised over the out of country one. All Google/Akami/Amazon S3 are doing is moving their websites closer to the user.

I don't follow the net neutrality debate very closely, but people shouldn't try and build their arguments on incorrect networking facts. Yes, Packeteer and other devices that specifically interfere with packet flow, traffic engineering, queuing, marking, policing, etc ARE non-network neutral. Location of caches is not.

Peter
Alert

what a load of rubbish!

I'm sorry Richard, but the whole of the last paragraph is rubbish, which rather deflates the rest of your argument, especially the references to 'prioritising packet delivery'.

Using your 'logic', you are arguing that ANY website less AS hops and latency from the customer has a 'raised delivery priority' than one further away. You confuse TCP backoff and windowing mechanisms with QOS. Yes in principle throughput can increase when congestion is lower, and yes less hops generally means less percentage packet loss (reducing TCP back-off) and also less latency (less likelihood that you reach TCP window limits), but to suggest that affects delivery *priority* is wrong. Two packets arriving at the next hop router to the customers ISP link are NOT treated differently. It's just that there is a higher percentage chance that the packets in the queue are Googles because the serving device is closer to the customer so the end-to-end TCP connection's potential throughput is higher. Google fills a higher percentage of the queue on the interface to your last-mile link because there is less congestion and loss to their server from your device when compared to a TCP connection to a server further away. The actual packets Google sends you are given no priority over any other packets when they reach that router so that doesn't 'breal' net neutrality.

By your logic we'd have to make every web-server an equal number of AS hops and latency from each customer to have a 'neutral' service Internet! Congestion and latency are inherent to the structure of the Internet, and caching services like Akami, Amazon S3 (and now Google peering) are designed to reduce those inherent (Speed of light related) performance issues, not 'bypass' net neutrality.

You need to separate the concepts of individual packet 'priority' and the effect of things like congestion and latency effects on TCP throughput. Until you do that your argument isn't one.