6 ms·

This is interesting, but the article and I differ greatly at this point: "Being non-standards-compliant in a way that privileges their flows relative to others

This is interesting, but the article and I differ greatly at this point: "Being non-standards-compliant in a way that privileges their flows relative to others seems more than a little hypocritical from a company that's making such a fuss about network neutrality." No, no it's not. This has nothing to do with network neutrality; it's a purely server-side change/fix. Not only that, they're benefiting users without requiring anyone else to change while they wait for standards bodies to catch up. This is a similar scenario to HTML5 video, and distinctly more clear-cut than e.g. '802.11n draft' wireless routers in my opinion.

jamesaguilar 16y ago
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.
- chollida1 16y ago
  > 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".
  - jamesaguilar 16y ago
    They're only famous when they are the last words said. But they are said far more often and wind up being proved correct.
    - chollida1 16y ago
      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"
bstrong 16y ago
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.
- dedward 16y ago
  It doesn't make it okay, it just makes it not a "net neutrality" issue. It's more of a "good neighbour" issue.
  - cperciva 16y ago
    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.
  - spudlyo 16y ago
    Are neutrality and hostility mutually exclusive?
    - pyre 16y ago
      Being a bad neighbor doesn't imply hostility.
  - bstrong 16y ago
    Fair point. In retrospect, invoking net neutrality wasn't really called for.
dedward 16y ago
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.
shadowmatter 16y ago
"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 >_<
- kragen 16y ago
  > 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.
  - shadowmatter 16y ago
    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).

jamesaguilar 16y ago

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.

chollida1 16y ago
> 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".
- jamesaguilar 16y ago
  They're only famous when they are the last words said. But they are said far more often and wind up being proved correct.
  - chollida1 16y ago
    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"

bstrong 16y ago

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.

dedward 16y ago
It doesn't make it okay, it just makes it not a "net neutrality" issue. It's more of a "good neighbour" issue.
- cperciva 16y ago
  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.
- spudlyo 16y ago
  Are neutrality and hostility mutually exclusive?
  - pyre 16y ago
    Being a bad neighbor doesn't imply hostility.
- bstrong 16y ago
  Fair point. In retrospect, invoking net neutrality wasn't really called for.

dedward 16y ago

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.

shadowmatter 16y ago

"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 >_<

kragen 16y ago
> 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.
- shadowmatter 16y ago
  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).