Hacker News Reader

> 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.