"Benefiting _their_ users," yes. But they're not benefiting whoever else is sharing the smallest-capacity link -- what he's arguing is that Google is crowding them out.

Net neutrality is not the only way to privilege your flows on the Internet: There's nothing to stop me from writing a crude application-layer protocol atop UDP that implements reliability but not congestion control. (You maybe had to implement something like this for your networking class in school; otherwise you could start with a protocol like DCCP.) If I were to use that to send data as fast as I could to some remote computer, I could be sending more data than the smallest-capacity link could handle. Other TCP/IP connections sharing that link would detect data loss and thus reduce the amount of data they put in transit, but my protocol wouldn't have to. I can monopolize that link.

So assuming your physical layer is tin cans and string, what he's arguing is that if you have a link with a capacity of 12 segments, then data from Google will use 10 of them and a client will never expand its outstanding data beyond 2 segments. If both used vanilla TCP/IP, they should share the link evenly.

Of course, speed is a critical factor for Google. Android by default uses TCP Westwood+.

It's been six years since I tinkered with TCP/IP and really focused on networking, so someone please correct me if I'm wrong >_<

> So assuming your physical layer is tin cans and string, what he's arguing is that if you have a link with a capacity of 12 segments, then data from Google will use 10 of them and a client will never expand its outstanding data beyond 2 segments. If both used vanilla TCP/IP, they should share the link evenly.

He's not showing any evidence that Google wouldn't back off to a smaller window in the face of packet loss; he's just saying their initial window is 9 segments. Once one of those 10 segments in your tin-can router falls out of its receive buffer, Google will be down to 9 and the other guys get up to 3, and packet loss will random-walk toward fairness.

Right? I've never tinkered with this stuff, so please correct me if I'm wrong.

I thought that the minimum value cwnd could assume is IW, but looking at RFC 2581 that isn't true: "Upon a timeout cwnd MUST be set to no more than the loss window, LW, which equals 1 full-sized segment (regardless of the value of IW)." They even explicitly call out what I erroneously believed, so you are right -- I apologize!

If you really have a tin cans and string physical layer, Google's larger IW could be more disruptive to other connections on the link: A vanilla TCP connection would ramp up cwnd from 1 segment until congestion is observed (in the slow-start phase) and then grow cwnd conservatively (after ssthresh is first set). If congestion would be observed at a cwnd value less than 10 segments, then starting with IW at 10 segments could be very disruptive to others sharing the connection.

Mind you, this argument feels very... academic. As you pointed out, Google's connection would converge toward fairness anyway. (Unless so little data is actually transmitted, then the connection probably isn't open long enough for that to happen.) And most shared links don't saturate at 12 segments. I'd guess that a high-capacity link would only be at risk if it has a lot of connections (so that every connection has a cwnd not much greater than 10) and there are always many (albeit, short-lived) connections to Google always being created (which could appear as fewer long-lived connections with a constant cwnd of 10, more than would be fair).

While it's true that Google is starting aggressively they are still using the slow-start algorithm, not ignoring it. If your physical layer is tin cans with string sure you'll get crowded out, but then the connection will degrade in the same way it would if they were using the default window size.

Microsoft on the other hand should really use slow-start.

I think it's difficult to argue that the profile of the underlying network hasn't changed since the last time an RFC was standardized on this issue. The problem is revving the magic numbers in the standards periodically to reflect changes in topology.

While you can say that Google should stick to the standard, unlike other net neutrality issues this isn't a change available only to a few large companies. Anyone with control of their stack can make this configuration.

The issue in net neutrality is to ensure that changes which are economically feasible for only a small group of companies are not enacted so that they cannot form a defacto monopoly.

that sums about the "trick" i used in 97-98 over "tin cans and string" Russian links of the time to make sure that my large data would make it. It was really hard on my "neighbors" at the time.

You re spot on. Whether the protocol needs to change with changing times and network speeds is an entirely different question.

I'm not sure how the fact that it's a server-side change makes it ok. I think that everyone would agree that turning off congestion control entirely on the server side would be bad and would negatively impact other flows.

The question, then, is whether this change is significant enough to increase internet congestion (and therefore packet loss for others). This is a subject of heated debate at the moment.

It doesn't make it okay, it just makes it not a "net neutrality" issue. It's more of a "good neighbour" issue.

Network neutrality says "you shouldn't be able to buy better network performance than your competition". What google is doing is violating standards in order to give themselves better network performance than their competition.

It's not exactly the network neutrality issue, no; but it's related, and where it differs, I'd say that what Google is doing is worse -- at least having companies pay for packet prioritization won't cause internet congestion collapse.

Fair point. In retrospect, invoking net neutrality wasn't really called for.

Are neutrality and hostility mutually exclusive?

Being a bad neighbor doesn't imply hostility.

Also, as a technical point, the amount of total internet utilization caused by the fetching of http web pages is so small that I doubt this practice could significantly harm any other traffic.

> that I doubt this practice could significantly harm any other traffic.

I agree with you, but whenever I see something like this the back of my mind always chimes in with "famous last words".

They're only famous when they are the last words said. But they are said far more often and wind up being proved correct.

I think you're reading too much into this:)

It's just an expression, who's meaning has moved away from it's literal translation to now mean something like: "How bad could it be" or "I know this is going to bite me in the ass someday"

IT has nothing to do with net neutrality, but it does have to do with the stability and reliability of the internet at large. If everyone, for example, tweaked TCP in different, incompatible ways, we'd have contention all over and things just wouldn't work well.