Steve Casner's paper, which you cited, and Sue Moon's paper at http://an.kaist.ac.kr/~sbmoon/paper/infocom2004.pdf, both report very limited variation in delay within the ISP network. Sue's paper goes on to describe points of variation on the order of ten and 100 ms in some detail as well as reporting the general case of low variation in delay. But most people don't live within the PE-PE domain, where these studies were done - they connect to the backbone ISP through an access carrier or through an enterprise network, or connect via some longer path. So responding defensively "give me numbers" and citing as proof of your case a paper that only looks at the path within the ISP has the effect of shutting down and making an end-to-end discussion appear to be invalid when Casner and Moon in fact only perform a measurement of a part of the path.
uh, fred. it was vicky who made the comparison i2 to internet, not i. i2 does not include site links, and some are good and some are bad. it is common wisdom today that the internet backbone is not where congestion occurs, but rather the customer tails. though one should always be suspicious of common wisdom, this particular bit seems pretty well supported, pings from uganda's makerere university notwithstanding. you/ve been pushing qos for a long time, fred. but, in the current situation, where the tails are the issue, signaling back from dest to source is still the big gap. imiho, from the ops perspective, only sally's ecn has made any useful approach. sadly, we may be able to judge the actual demand for e2e qos by ecn's very slow deployment. i think this is unfortunate, as ecn is pretty cool. but, in this community, the question would seem to be how long the current situation will prevail, where it is far simpler and less expensive to throw bandwidth at the backbone, as opposed to spending even more on opex-eating complexety and ever more complex and expensive routers. i suspect it'll be a while before we even see cotton balls being blown, and a very long while before new ducts. i.e., raw bandwidth costs will likely stay low. even the price of lighting it is declining. this has been discussed recently, both here and in simon lam's 2004 sigcomm award paper (recent ccr). so, i think we should o encorage i2 as the usg's way of subsidizing higher ed [0] and providing a playpen where big spikes and other traffic anomalies are not discouraged o encourage qos research o keep the real internet as simple as possible, after all, it is fools such as i who have to run it randy --- [0] - and i mean it. the lack of govt support for education in the us is a horrifying tragedy ever in the making
On Wed, 27 Apr 2005, Randy Bush wrote:
to source is still the big gap. imiho, from the ops perspective, only sally's ecn has made any useful approach. sadly, we may be able to judge the actual demand for e2e qos by ecn's very slow deployment. i think this is unfortunate, as ecn is pretty cool.
The low demand is partially due to IWF[0] who unwittingly block it. Many OSes deploy with ecn support but default it off due to the IWF problem. And there are so many IWF that applying enough cluebats to clear the path for ECN is going to take enormous effort. We could demonstrate how cool ECN is, if there werent so many IWF making this impossible. Entities who try to deploy ECN are deluged with "hey wtf I cant reach site XYZ anymore, your shit is broken, fix it you *******!" I have no idea if microsoft supports ECN yet, but if they dont then I suspect that a sufficiently embarassing benchmark would prod them into adding it. I wonder how many network operators on nanog block ECN. If you do, why? -Dan [0]Idiots With Firewalls. See http://urchin.earth.li/cgi-bin/ecn.pl
* Dan Hollis:
And there are so many IWF that applying enough cluebats to clear the path for ECN is going to take enormous effort.
ECN favors non-conformant endpoints. Therefore, it won't help you in the long run if the congestion is on a path which is shared by multiple customers. Popular file sharing software will just set the proper flags to decrease the discard probability, just like Netscape opened multiple HTTP connections to the same server.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, comments in-line: Dan Hollis wrote: | On Wed, 27 Apr 2005, Randy Bush wrote: | |>to source is still the big gap. imiho, from the ops perspective, |>only sally's ecn has made any useful approach. sadly, we may be |>able to judge the actual demand for e2e qos by ecn's very slow |>deployment. i think this is unfortunate, as ecn is pretty cool. - ------------- yeah ecn make sense to us as well. We are currently looking at piece mealing this deployment at our end. fyi - I think kernel.org has also implemented ecn at their end. | | | The low demand is partially due to IWF[0] who unwittingly block it. Many | OSes deploy with ecn support but default it off due to the IWF problem. - ----------- True enough. Plus devices (by default) may not honor CE (congestion experienced) bits and hence could become non compliant end node which could result in an unnecessary packet drop in the network. | | And there are so many IWF that applying enough cluebats to clear the path | for ECN is going to take enormous effort. | | We could demonstrate how cool ECN is, if there werent so many IWF making | this impossible. Entities who try to deploy ECN are deluged with "hey wtf | I cant reach site XYZ anymore, your shit is broken, fix it you *******!" | | I have no idea if microsoft supports ECN yet, but if they dont then I | suspect that a sufficiently embarassing benchmark would prod them into | adding it. | | I wonder how many network operators on nanog block ECN. If you do, why? - ------------ In fact I raised similar point at NANOG33 in two separate sessions (How to Use Network Design Principles to Differentiate the Good, the Bad, and the Ugly AND IP Fast-Reroute: An Analysis of Applicability to a Core Network) about vendor experience/feedback in this area. Didn't get much feedback. regards, /vicky | | -Dan | | [0]Idiots With Firewalls. See http://urchin.earth.li/cgi-bin/ecn.pl | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCctVxpbZvCIJx1bcRAgwcAKDvvBlpDBZBaXfUJysTJ0GUByLUIACgln1F HFQixDoE4zvsyPmdQy7Aa98= =R64s -----END PGP SIGNATURE-----
participants (4)
-
Dan Hollis
-
Florian Weimer
-
Randy Bush
-
Vicky Rode