From lars.eggert at netlab.nec.de Tue Mar 1 05:19:27 2005 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Tue, 01 Mar 2005 14:19:27 +0100 Subject: [e2e] TCP losses In-Reply-To: <6.2.1.2.2.20050228093632.05d7e3f0@mira-sjc5-b.cisco.com> References: <4222EA41.2020201@tuhh.de> <6.2.1.2.2.20050228093632.05d7e3f0@mira-sjc5-b.cisco.com> Message-ID: <42246BDF.4020902@netlab.nec.de> Fred Baker wrote: > At 10:54 AM 02/28/05 +0100, Sireen Habib Malik wrote: > >> How long does TCP take to decide that its connection has gone to the >> dogs and that the Application must do something about it? RFC1122 >> (section 4.2.3.5) talks about "atleast" 100seconds. Is this applied >> practically? > > By some, yes, and often not. Practically, a routing outage lasting for > tens of seconds often results in TCP sessions failing. I'm not sure I > would peg it to 100 seconds nowadays, but some do seem a little brittle. FYI, we have a draft in the TCPM working group that lets TCP choose per-connection timeouts in addition to the system wide default, with the idea that you'd use longer timeouts for "important" connections. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-eggert-gont-tcpm-tcp-uto-option-01.txt Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3360 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050301/50460524/smime.bin From jshapiro at cse.msu.edu Tue Mar 1 19:31:28 2005 From: jshapiro at cse.msu.edu (Jonathan Shapiro) Date: Tue, 01 Mar 2005 22:31:28 -0500 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: <42246BDF.4020902@netlab.nec.de> References: <4222EA41.2020201@tuhh.de> <6.2.1.2.2.20050228093632.05d7e3f0@mira-sjc5-b.cisco.com> <42246BDF.4020902@netlab.nec.de> Message-ID: <42253390.5080308@cse.msu.edu> I recently had occaision to read a few papers about the practice of "TCP spoofing" over satellite links---i.e inserting a proxy prior to the satellite link to provide TCP feedback to the sender, effectively splitting into two TCP sessions connected in tandem. I was wondering if anyone had ever proposed a similar idea to improve TCP throughput in overlay networks over terestrial links. /jonathan shapiro From Reiner.Ludwig at ericsson.com Tue Mar 1 21:47:18 2005 From: Reiner.Ludwig at ericsson.com (Reiner Ludwig) Date: Wed, 02 Mar 2005 06:47:18 +0100 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: <42231671.70104@reed.com> References: <42231671.70104@reed.com> Message-ID: <6.1.1.1.1.20050302061920.02a0be98@imap.eed.ericsson.se> I appreciate the e2e argument very much but ... At 14:02 28.02.05, David P. Reed wrote: >Interesting theoretical discussion, but remember that TCP was designed >to run on networks with low packet loss rates, or networks that use >link-level retransmission or FEC to get packet loss rates to less than >1%. This is what was meant by "best efforts". ... this rule with the "magic number 1%" simply can not hold. In the future we will see wireless links running at speeds > 1 Gb/s. Given that the RTT is lower bounded by the laws of physics, we end up with huge bandwidth x delay products. And, we know that TCP does not perform well with a loss rate of 1% in such a regime [FAST-TCP, HS-TCP, Scalable-TCP, etc.]. No single magic number will work for all regimes. One rule of thumb that works, though, is to make the link-level retransmission completely persistent (don't give up until the link is declared DOWN). That way any errors or variations on the link are translated into congestion, and that is something that at least the rate-adaptive end-points understand. So, maybe "best effort" should mean that we try as hard as possible to sucessfully transmit packets, but if congestion builds up we will at some point need to drop (mark) packets. ///Reiner From Reiner.Ludwig at ericsson.com Tue Mar 1 23:56:02 2005 From: Reiner.Ludwig at ericsson.com (Reiner Ludwig) Date: Wed, 02 Mar 2005 08:56:02 +0100 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: References: Message-ID: <6.1.1.1.1.20050302085035.02a6b018@imap.eed.ericsson.se> At 08:12 02.03.05, Lloyd Wood wrote: >That's a "rule of thumb" that completely fails performance-wise on >long-distance wireless links e.g. geostationary satellite, and RFC3366 >warns against the dangers of perfect persistence. > >Reiner, do we have to hash out five years of arguing your personal >beliefs on the IETF pilc mailing list yet AGAIN? I expected you to be one of the first to jump on this, but it is not fair to say that this is only my "personal beliefs". It was the consensus of the PILC WG in the IETF: RFC3819. ///Reiner From Reiner.Ludwig at ericsson.com Wed Mar 2 00:13:22 2005 From: Reiner.Ludwig at ericsson.com (Reiner Ludwig) Date: Wed, 02 Mar 2005 09:13:22 +0100 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: References: Message-ID: <6.1.1.1.1.20050302091217.02a78cd8@imap.eed.ericsson.se> At 09:01 02.03.05, Lloyd Wood wrote: >On Wed, 2 Mar 2005, Reiner Ludwig wrote: > >> At 08:12 02.03.05, Lloyd Wood wrote: >> >That's a "rule of thumb" that completely fails performance-wise on >> >long-distance wireless links e.g. geostationary satellite, and >RFC3366 >> >warns against the dangers of perfect persistence. >> > >> >Reiner, do we have to hash out five years of arguing your personal >> >beliefs on the IETF pilc mailing list yet AGAIN? >> >> I expected you to be one of the first to jump on this, but it is not >> fair to say that this is only my "personal beliefs". >> >> It was the consensus of the PILC WG in the IETF: RFC3819. > >And RFC3819 refers to RFC3366. > >Your point? The reading you have to do yourself, but I'll help you once more: sections 8.1 and 8.2 in RFC3819 (BCP). ///Reiner From Jon.Crowcroft at cl.cam.ac.uk Wed Mar 2 02:17:50 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 02 Mar 2005 10:17:50 +0000 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: Message from Jonathan Shapiro of "Tue, 01 Mar 2005 22:31:28 EST." <42253390.5080308@cse.msu.edu> Message-ID: an overlay that uses TCP is already doing multiple TCP hops - this gives at least 1 advantage over a pure end2end TCP connection which is that the steady state throughput for TCP is a function of 1/rtt - but for an overlay the RTT concerned will be the maximum rtt of overlay hops, not the end2end one - ofcourse, with some p2p algoriths this might actually be longer than an end2end rtt:-) but with most sensible overlay routing schemes it will be shorter... the effects of localizing loss recovery to an "overlay hop" will be more complex to evaluate - it isnt obvious whether this will have a benefit or not (compared say to lowish latency wide area wireless links, where localizing the recovery through a TCP splice/proxy can be good, just as link layer ARQ or FEC to recover from loss on a hop can be good, in some cases - not all) - in the overlay case, you are stuck with the whole TCP behaviour when you do localized recovery on the tcp hops - so you might end up with lots of seperate slow starts operating (i.e. you are at the mercy of many unsynchronised TCP machines;) i dont know if anyone has looked at that side of "hop-by-hop tcp"... personally, i dont know why people use TCP In missive <42253390.5080308 at cse.msu.edu>, Jonathan Shapiro typed: >>I recently had occaision to read a few papers about the practice of "TCP >>spoofing" over satellite links---i.e inserting a proxy prior to the >>satellite link to provide TCP feedback to the sender, effectively >>splitting into two TCP sessions connected in tandem. I was wondering if >>anyone had ever proposed a similar idea to improve TCP throughput in >>overlay networks over terestrial links. >> >>/jonathan shapiro >> cheers jon From dpreed at reed.com Wed Mar 2 04:27:30 2005 From: dpreed at reed.com (David P. Reed) Date: Wed, 02 Mar 2005 07:27:30 -0500 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: References: Message-ID: <4225B132.60808@reed.com> Jon Crowcroft wrote: >the effects of localizing loss recovery to an "overlay hop" will be >more complex to evaluate - it isnt obvious whether this will have a >benefit or not (compared say to lowish latency wide area wireless >links, where localizing the recovery through a TCP splice/proxy can be >good, just as link layer ARQ or FEC to recover from loss on a hop can >be good, in some cases - not all) - in the overlay case, you are stuck >with the whole TCP behaviour when you do localized recovery on the tcp >hops - so you might end up with lots of seperate slow starts operating >(i.e. you are at the mercy of many unsynchronised TCP machines;) > > > Au contraire, there has been lots of experience running TCP over "reliable links". Lots of experience in the field with using frame relay as a "hop", and turning on end-to-end reliability by accident, suggests that the underlay TCP will interact with the overlay in a disastrous postive feedback control loop creating unstable end-to-end behavior. It is *essential* that the underlay TCP *not* try to hide congestion, which is signaled by packet drops. In other words if you are spoofing IP with TCP-based links, you have to create a situation in which the underlay does not allow its buffering to expand elasticly. From Jon.Crowcroft at cl.cam.ac.uk Wed Mar 2 04:55:57 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 02 Mar 2005 12:55:57 +0000 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: Message from "David P. Reed" of "Wed, 02 Mar 2005 07:27:30 EST." <4225B132.60808@reed.com> Message-ID: you're making lots of assumptions about how the software operates at the splice point. there are lots of ways to mitigate the problems you describe - and papers about it i think in fact we had rather more experience of this this side of the pond than elsewhere with TCP/IP on 2Mbps X.25 nets in Europe, and, at one point, the X.25 implemented between Cisco boxes over TCP:) so we know the pitfalls but a non-oblivious overlay can easily obviate this - there's ample evidence that a p2p system is exactly that. In missive <4225B132.60808 at reed.com>, "David P. Reed" typed: >>Au contraire, there has been lots of experience running TCP over >>"reliable links". Lots of experience in the field with using frame relay >>as a "hop", and turning on end-to-end reliability by accident, suggests >>that the underlay TCP will interact with the overlay in a disastrous >>postive feedback control loop creating unstable end-to-end behavior. >>It is *essential* that the underlay TCP *not* try to hide congestion, >>which is signaled by packet drops. In other words if you are spoofing >>IP with TCP-based links, you have to create a situation in which the >>underlay does not allow its buffering to expand elasticly. cheers jon From dpreed at reed.com Wed Mar 2 06:25:43 2005 From: dpreed at reed.com (David P. Reed) Date: Wed, 02 Mar 2005 09:25:43 -0500 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: <6.1.1.1.1.20050302061920.02a0be98@imap.eed.ericsson.se> References: <42231671.70104@reed.com> <6.1.1.1.1.20050302061920.02a0be98@imap.eed.ericsson.se> Message-ID: <4225CCE7.3080208@reed.com> Reiner Ludwig wrote: > >... this rule with the "magic number 1%" simply can not hold. In the future we will see wireless links running at speeds > 1 Gb/s. Given that the RTT is lower bounded by the laws of physics, we end up with huge bandwidth x delay products. And, we know that TCP does not perform well with a loss rate of 1% in such a regime [FAST-TCP, HS-TCP, Scalable-TCP, etc.]. No single magic number will work for all regimes. > >One rule of thumb that works, though, is to make the link-level retransmission completely persistent (don't give up until the link is declared DOWN). That way any errors or variations on the link are translated into congestion, and that is something that at least the rate-adaptive end-points understand. > > You and I are on the same page in suggesting that TCP need not be the only place where optimization occurs, and that link level is a pragmatic and appropriate place to get part of the way there. The 1% was not intended as a "magic number". However, your "magic solution" goes way too far in the opposite direction, introducing a link-layer "perfect efforts" rather than "best efforts" reliability function that unilaterally declares that a link knows what the endpoints want more than they do. The end-to-end argument we wrote about (as opposed to many strawman interpretations, and mere misunderstandings) says that there are network functions that are definable and implementable fully only at the endpoints - those are called end-to-end functions. The reliability/retransmission tradeoff is one such function. There are MANY reasons not to have low-level links trying to second-guess the endpoints need for retransmission. The end-to-end argument just suggests extreme caution in introducing such ideas. Just as ECN/RED is quite compatible with the end-to-end argument (and ECN/RED is not just a TCP function! various UDP functions like RTP should also be using it), time-bounded link-level retransmission is quite appropriate as well. ECN and RED are special cases of multicasting the output of congestion sensors to those known to be interested at the edges - a very nice theory of how to provide general and application-independent/protocol-independent network state reflection). The network layer under TCP that works best is one that has a latency end-to-end that is predominantly driven by congestion, and does not hide failures that might be handled by the end-to-end protocol (retransmission or route switching) or application (the user canceling the transaction if it takes too long being the most trivial application control loop). From swany at cis.udel.edu Wed Mar 2 10:45:16 2005 From: swany at cis.udel.edu (Martin Swany) Date: Wed, 2 Mar 2005 13:45:16 -0500 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: <42253390.5080308@cse.msu.edu> References: <4222EA41.2020201@tuhh.de> <6.2.1.2.2.20050228093632.05d7e3f0@mira-sjc5-b.cisco.com> <42246BDF.4020902@netlab.nec.de> <42253390.5080308@cse.msu.edu> Message-ID: <47c6849f56948bef0186d2bb4a5c3055@cis.udel.edu> Hi there, > I recently had occaision to read a few papers about the practice of > "TCP spoofing" over satellite links---i.e inserting a proxy prior to > the satellite link to provide TCP feedback to the sender, effectively > splitting into two TCP sessions connected in tandem. I was wondering > if anyone had ever proposed a similar idea to improve TCP throughput > in overlay networks over terestrial links. We proposed such an approach in terms of an E2E "session" layer. The 2001 tech report (and some newer information) is available here: http://www.cis.udel.edu/~swany/projects/lsl regards, martin From kkrama at research.att.com Wed Mar 2 13:38:08 2005 From: kkrama at research.att.com (K. K. Ramakrishnan) Date: Wed, 02 Mar 2005 16:38:08 -0500 Subject: [e2e] CfP: ANCS 2005: Symp on Architectures for Networking and Communications Systems Message-ID: <42263240.9090903@research.att.com> ***** CALL FOR PAPERS ***** 1st Symposium on Architectures for Networking and Communications Systems ANCS 2005 http://www.ancsconf.org October 26-28, 2005 Princeton, New Jersey, USA Sponsored by: ACM Special Interest Group on Computer Architecture (SIGARCH) ACM Special Interest Group on Communications (SIGCOMM) IEEE Computer Society Tech. Committee on Computer Architecture IEEE Communications Society Tech. Committee on Computer Communications ---------------------------------------------------------------------- ANCS is new research conference that focuses on the design of the hardware and software components used to create modern communication networks. The combination of increasing network line speeds and expanding functional requirements pose continuing and growing challenges for system designers. New technology elements, including network processors, content addressable memories, configurable logic and special-purpose components offer new opportunities for meeting these challenges, but also raise a variety of new issues. ANCS focuses on architectures for networking and communication in the broad sense, including novel architectures, architectural support for advanced communication, algorithms and protocols for advanced architectures, software and applications for next-generation networking architectures, and methodology and benchmarking for evaluating advanced communication architectures. Areas of interest include, but are not limited to: * Network/communications processors * Intelligent co-processors * Router architectures * Switch fabrics/interconnection networks * Link scheduling, processor/thread scheduling, switch scheduling * Network adaptors * Application-specific networks (e.g. SAN) * Programmable /extensible networks * Secure communication * Traffic management * Packet classification * Content inspection and filtering * Energy-efficient designs We particularly encourage submissions containing highly original ideas. Submissions will be judged on originality, significance, interest, clarity, and correctness. The PAPER DEADLINE for submissions is May 9, 2005 at 11:59PM PST (US). NO FURTHER EXTENSIONS WILL BE GRANTED. ANCS will use double-blind reviewing, so submitted papers should not include the authors' names. All papers must be submitted electronically, in PDF format for letter-size paper. Submissions must be viewable by Adobe Acrobat Reader (version 5.0 or higher) and should not exceed 7,000 words or 10 pages of conference paper format using 10 pt fonts. Submissions exceeding the required limit will not be reviewed by the program committee. Detailed submission instructions will be available by April 1, 2005 at: http://www.ancsconf.org. Like other conferences, ANCS requires that papers not be submitted simultaneously to any other conferences or publications, that submissions not be previously published, and that accepted papers not be subsequently published elsewhere. All submissions will be acknowledged by July 30, 2002. If your submission is not acknowledged by this date, please contact the program chairs promptly at ancsPCchairs at arl.wustl.edu. Important Dates Submission deadline: May 9, 2005 Author notification: July 30, 2005 Final camera-ready copy: September 6, 2005 Tutorials A series of tutorials will be held immediately preceding the symposium. Tutorial proposals will be accepted until June 30, 2005. If you wish to give a tutorial (1/2 or 1 day), email a proposal to the Tutorials Chair (Erik Johnson, Erik.Johnson at intel.com). For tutorials, the proposal must include title, brief description of topics to be covered, and bio of the speakers. ---------------------------------------------------------------------- General Chair: Alan Berenbaum, Consultant Steering Committee: Alan Berenbaum, Consultant Patrick Crowley, Washington Univ. at St. Louis Mark Franklin, Washington Univ. at St. Louis Haldun Hadimioglu, Polytechnic Univ. Nick McKeown, Stanford Univ. Peter Z. Onufryk, IDT K. K. Ramakrishnan, AT&T Labs Research Program Co-Chairs: Kai Li, Princeton University Jonathan Turner, Washington University at St. Louis Program Committee: Andrew Campbell, Columbia Univ. Patrick Crowley, Washington Univ. at St. Louis Cezary Dubnicki, NEC Hans Eberle, Sun Microsystems Dirk Grunwald, Univ. Of Colorado Roch Guerin, Univ. of Pennsylvania T.V. Lakshman, Bell Labs Dan Lenoski, Cisco Systems Bill Mangione-Smith, UCLA Kenneth McKenzie, Georgia Tech. Nick McKeown, Stanford Univ. Peter Onufryk, IDT Li-Shuian Peh, Princeton Univ. Mohammad Peyravian, IBM Henning Schulzrinne, Columbia Univ. Steve Scott, Cray Dimitrious Stiliadis, Bell Labs Ion Stoica, UC Berkeley Chuck Thacker, Microsoft Harrick Vin, UT Austin Tilman Wolf, UM Amherst Raj Yavatkar, Intel Hui Zhang, CMU -- K. K. Ramakrishnan Email: kkrama at research.att.com AT&T Labs-Research, Rm. A117 Tel: (973)360-8764 180 Park Ave, Florham Park, NJ 07932 Fax: (973) 360-8871 URL: http://www.research.att.com/info/kkrama From touch at ISI.EDU Wed Mar 2 15:07:08 2005 From: touch at ISI.EDU (Joe Touch) Date: Wed, 02 Mar 2005 15:07:08 -0800 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: <42253390.5080308@cse.msu.edu> References: <4222EA41.2020201@tuhh.de> <6.2.1.2.2.20050228093632.05d7e3f0@mira-sjc5-b.cisco.com> <42246BDF.4020902@netlab.nec.de> <42253390.5080308@cse.msu.edu> Message-ID: <4226471C.7010809@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Shapiro wrote: | I recently had occaision to read a few papers about the practice of "TCP | spoofing" over satellite links---i.e inserting a proxy prior to the | satellite link to provide TCP feedback to the sender, effectively | splitting into two TCP sessions connected in tandem. I was wondering if | anyone had ever proposed a similar idea to improve TCP throughput in | overlay networks over terestrial links. | | /jonathan shapiro TCP 'spoofing' of this sort is basically what TCP Splicing does; there are numerous problems with this - notably that it breaks the E2E utility of TCP (getting an ACK doesn't mean the other end got the data!), as well as challenges when the window sizes of the two TCPs differ. As to whether this is an overlay or not, I don't see how 'overlay' related. You're just spoofing a TCP connection; overlays (IMO) are defined by tunnels. There's no tunnel here (unless you're saying you're tunneling over TCP, which is a bad idea for numerous other reasons). Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJkcbE5f5cImnZrsRAixXAKDacJIxg0KtQ6lwTxlAWzi2KcyKVgCfUREU QXTpT/mYDk1+GXClSwCCylw= =tSYO -----END PGP SIGNATURE----- From sgovind at hpc.serc.iisc.ernet.in Thu Mar 3 03:02:13 2005 From: sgovind at hpc.serc.iisc.ernet.in (S.Govind) Date: Thu, 3 Mar 2005 16:32:13 +0530 (IST) Subject: [e2e] using TCP features in the design of routers Message-ID: hi I am new to this mailing list ,so iam not sure if this is the right place to ask this question. Internet traffic is primarily composed of TCP flows ,so isnt it possible to take advantage of TCP features, for eg: if threads in a router are processing from a given flow and if the router sees that there is a packet loss from a flow so it can allocate resources to other flow (bcoz of congestion,window size reduces of that flow). I havent come across similar work, any pointers in this direction is highly appreciated Iam a novice to networking so may be i would have missed some important point Thanking You, Govind -- From Reiner.Ludwig at ericsson.com Thu Mar 3 05:49:46 2005 From: Reiner.Ludwig at ericsson.com (Reiner Ludwig) Date: Thu, 03 Mar 2005 14:49:46 +0100 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: <4225CCE7.3080208@reed.com> References: <4225CCE7.3080208@reed.com> Message-ID: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> At 15:25 02.03.05, David P. Reed wrote: >You and I are on the same page in suggesting that TCP need not be the >only place where optimization occurs, and that link level is a pragmatic >and appropriate place to get part of the way there. > >The 1% was not intended as a "magic number". OK. >However, your "magic >solution" goes way too far in the opposite direction, introducing a >link-layer "perfect efforts" rather than "best efforts" reliability >function that unilaterally declares that a link knows what the endpoints >want more than they do. Fine. Then we do not agree. But, I'll try to make my point clearer ... For example, assume a wireless link where the optimal size of the retransmission unit - as determined by the link's error characteristics - is 40 Bytes. Why should L2 ARQ give up on a packet, and let it retransmit by TCP? TCP can't do any better, anyway. Completely persistent L2 ARQ translates errors into varying delay and congestion which are two behaviors of the black-box that end-points can adapt to. Error losses inside the black-box can not be understood by the end-points (unless explicitly signaled from within the black-box); they can only be (mis-)interpreted as congestion losses. But why bother about all of this? With a well designed L1, the common case will be that the L2 does not need any or only very few retransmissions, anyway. If it does need many retransmission, though, then the link is broken (at least during a transient period). In that case, nothing except re-routing traffic will help. [Clearly, on a channel that is shared by multiple tranceivers that can be in different physical locations, channel-dependent scheduling is needed in addition to ensure that a user in a bad spot can not cause head-of-line blocking for the others. But that's an orthogonal issue.] Note that this is not saying anything about buffer sizes. Clearly, completely persistent L2 ARQ should be combined with AQM (e.g., RED/ECN). The same arguments also hold when considering a rate-adaptive but delay-sensitive app. like streaming over DCCP/TFRC. And, I think that all of this is well in line with the e2e argument: "best effort" = "try until congestion forces you to drop". ///Reiner From fred at cisco.com Thu Mar 3 08:01:17 2005 From: fred at cisco.com (Baker Fred) Date: Thu, 3 Mar 2005 08:01:17 -0800 Subject: [e2e] using TCP features in the design of routers In-Reply-To: References: Message-ID: <3a92dcfbce828bf9c1c8f74bc32d2509@cisco.com> The most important point you have missed, really, is that TCP operates a level above that of a network layer router. For various purposes they will look into the TCP header on occasion when configured to, but that is usually to disallow a certain application (identified by port number pair) or some such. And if IPsec is in use, the TCP datastream is encrypted and therefore invisible to the router. What we have in fact used the kind of thing you discuss for commercially is to separate TCP (or UDP) sessions into separate interface queues and therefore apportion interface bandwidth among them. Attempting to apportion other router facilities in that way leads in the direction of a lot of work for little gain; once you have identified the TCP session for such purposes, you know enough to forward it, and may as well get it on its way. On Mar 3, 2005, at 3:02 AM, S.Govind wrote: > hi > > I am new to this mailing list ,so iam not sure if this is the right > place > to ask this question. > > Internet traffic is primarily composed of TCP flows ,so isnt it > possible > to take advantage of TCP features, for eg: if threads in a router are > processing from a given flow and if the router sees that there is a > packet > loss from a flow so it can allocate resources to other flow (bcoz of > congestion,window size reduces of that flow). I havent come across > similar work, any pointers in this direction is highly appreciated > > > Iam a novice to networking so may be i would have missed some > important point > > Thanking You, > Govind > > -- > From jshapiro at cse.msu.edu Thu Mar 3 09:29:35 2005 From: jshapiro at cse.msu.edu (Jonathan Shapiro) Date: Thu, 03 Mar 2005 12:29:35 -0500 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: <4226471C.7010809@isi.edu> References: <4222EA41.2020201@tuhh.de> <6.2.1.2.2.20050228093632.05d7e3f0@mira-sjc5-b.cisco.com> <42246BDF.4020902@netlab.nec.de> <42253390.5080308@cse.msu.edu> <4226471C.7010809@isi.edu> Message-ID: <4227497F.4030803@cse.msu.edu> Joe Touch wrote: > > TCP 'spoofing' of this sort is basically what TCP Splicing does; there > are numerous problems with this - notably that it breaks the E2E utility > of TCP (getting an ACK doesn't mean the other end got the data!), as > well as challenges when the window sizes of the two TCPs differ. I hope I am not rehashing an old debate on this list, but did the breaking of E2E semantics and mismatched window sizes prevent the deployment of spoofing/splicing for satellite links? (I'm genuinely curious, having only been recently exposed to this work.) If these were not considered insurmountable problems in that context, why should they be insurmountable for overlay networks? > As to whether this is an overlay or not, I don't see how 'overlay' > related. You're just spoofing a TCP connection; overlays (IMO) are > defined by tunnels. There's no tunnel here (unless you're saying you're > tunneling over TCP, which is a bad idea for numerous other reasons). I guess I have a more inclusive definition of 'overlay' in mind. I would define an overlay network is a graph whose vertices are a set of end-hosts and whose edges are a subset (not nec. a proper subset) of the edges in the complete graph connecting those end-hosts, and represent paths in the underlying network. Whether communication along those paths is multiplexed over tunnels or separated into transport-layer connections would be a choice for the designer---with non-trivial consequences. Maybe this is abuse of terminology, but the above definition seems to be shared by some. My question was, as you point out, about forming overlays without tunnels. The reason to consider this an overlay network is that if one has multiple choices of relays, then one is faced with a routing problem in addition to a session-splicing problem. /jonathan From touch at ISI.EDU Thu Mar 3 09:51:29 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Mar 2005 09:51:29 -0800 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: <4227497F.4030803@cse.msu.edu> References: <4222EA41.2020201@tuhh.de> <6.2.1.2.2.20050228093632.05d7e3f0@mira-sjc5-b.cisco.com> <42246BDF.4020902@netlab.nec.de> <42253390.5080308@cse.msu.edu> <4226471C.7010809@isi.edu> <4227497F.4030803@cse.msu.edu> Message-ID: <42274EA1.3000805@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathan Shapiro wrote: | | | Joe Touch wrote: | |> |> TCP 'spoofing' of this sort is basically what TCP Splicing does; there |> are numerous problems with this - notably that it breaks the E2E utility |> of TCP (getting an ACK doesn't mean the other end got the data!), as |> well as challenges when the window sizes of the two TCPs differ. | | I hope I am not rehashing an old debate on this list, but did the | breaking of E2E semantics and mismatched window sizes prevent the | deployment of spoofing/splicing for satellite links? (I'm genuinely | curious, having only been recently exposed to this work.) If these were | not considered insurmountable problems in that context, why should they | be insurmountable for overlay networks? They were considered either insurmountable or commercially deployable, depending on your perspective. I.e., thye were tried and continue to break E2E semantics, and break where window sizes mismatch, but that doesn't stop people from using them. But there are other issues with using TCP links for overlays: sending packets over a byte-oriented network has problems, notably delays added because: - TCP tries to ACK pairs of segments - uninitiated designers forget to disable Nagle - there is no way to force IP segments to align to TCP segments unless you implement the TCP at both ends of the system; existing TCP stacks will end up fragmenting - retransmission for reliability adds delays |> As to whether this is an overlay or not, I don't see how 'overlay' |> related. You're just spoofing a TCP connection; overlays (IMO) are |> defined by tunnels. There's no tunnel here (unless you're saying you're |> tunneling over TCP, which is a bad idea for numerous other reasons). | | I guess I have a more inclusive definition of 'overlay' in mind. I would | define an overlay network is a graph whose vertices are a set of | end-hosts and whose edges are a subset (not nec. a proper subset) of the | edges in the complete graph connecting those end-hosts, and represent | paths in the underlying network. Edges connect the end hosts how? Tunnels ;-) | Whether communication along those paths | is multiplexed over tunnels or separated into transport-layer | connections would be a choice for the designer---with non-trivial | consequences. IP over TCP is a tunnel. IP over IP is a tunnel The former is very inefficient; the latter less so. Or are you talking about arbitrary application messages, at which point is it even a network? | Maybe this is abuse of terminology, but the above | definition seems to be shared by some. My question was, as you point | out, about forming overlays without tunnels. The reason to consider this | an overlay network is that if one has multiple choices of relays, then | one is faced with a routing problem in addition to a session-splicing | problem. People who do application-layer networking necessarily reinvent transport and network protocols at the application layer. So they will end up needing something to do E2E transport over the IP over the TCP. The most common misconception (IMO) about such systems is the difference between provisioning and forwarding. Selecting among multiple existing tunnels is a forwarding operation; picking which relay to open a connection to is a provision operation. Provisioning is what you do to deploy a network (i.e., IMO, it's external to the network). Forwarding is part of how the network thus deployed works. joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJ06hE5f5cImnZrsRAj43AJ9+43NJGTZoIE9UbUtd4nsOtf7E/wCg77Ki AIPob5UDc+3NKf5BdCsIXMo= =agoo -----END PGP SIGNATURE----- From david.borman at windriver.com Thu Mar 3 11:50:45 2005 From: david.borman at windriver.com (David Borman) Date: Thu, 3 Mar 2005 13:50:45 -0600 Subject: [e2e] TCP spoofing in overlay networks Message-ID: <363d15e2bb6ea9bb697f92f5c7e6b245@windriver.com> It's been done and shipping for several years with all Cray X1 systems. The CNS (Cray Network Server) proxies TCP connections between the Cray and the outside world. This allows the Cray <-> CNS connection to use 64K MTUs and larger TCP windows over the fibre channel connection, and the CNS then deals with all the small 1500 byte packets coming from the outside world. Yes, this does break the end-to-end model. You have two TCP connections, one between the Cray and the CNS, and another between the CNS and the remote host. The CNS mainly passes data between the two endpoints, and uses NAT internally so to the Cray and the remote host, they think they are talking directly to each other, when in reality they are both talking to the CNS. Cray has done a good job over the years of making the CNS as transparent as possible. The performance benefit outweighs any issues of the corner cases that occasionally pop up. You can find documentation on the CNS by going to the CrayDoc website: http://www.cray.com/cgi-bin/swpubs/craydoc30/craydoc.cgi and searching for "CNS". -David Borman On Mar 1, 2005, at 9:31 PM, Jonathan Shapiro wrote: > I recently had occaision to read a few papers about the practice of > "TCP spoofing" over satellite links---i.e inserting a proxy prior to > the satellite link to provide TCP feedback to the sender, effectively > splitting into two TCP sessions connected in tandem. I was wondering > if anyone had ever proposed a similar idea to improve TCP throughput > in overlay networks over terestrial links. > > /jonathan shapiro From touch at ISI.EDU Thu Mar 3 13:48:41 2005 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Mar 2005 13:48:41 -0800 Subject: [e2e] TCP spoofing in overlay networks In-Reply-To: <363d15e2bb6ea9bb697f92f5c7e6b245@windriver.com> References: <363d15e2bb6ea9bb697f92f5c7e6b245@windriver.com> Message-ID: <42278639.5000508@isi.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Borman wrote: | It's been done and shipping for several years with all Cray X1 systems. | The CNS (Cray Network Server) proxies TCP connections between the Cray | and the outside world. This allows the Cray <-> CNS connection to use | 64K MTUs and larger TCP windows over the fibre channel connection, and | the CNS then deals with all the small 1500 byte packets coming from the | outside world. Yes, this does break the end-to-end model. You have two | TCP connections, one between the Cray and the CNS, and another between | the CNS and the remote host. The CNS mainly passes data between the two | endpoints, and uses NAT internally so to the Cray and the remote host, | they think they are talking directly to each other, when in reality | they are both talking to the CNS. Cray has done a good job over the | years of making the CNS as transparent as possible. The performance | benefit outweighs any issues of the corner cases that occasionally pop | up. You can find documentation on the CNS by going to the CrayDoc website: | http://www.cray.com/cgi-bin/swpubs/craydoc30/craydoc.cgi | and searching for "CNS". | | -David Borman This seems less significant in how it violates things; what you do inside what is arguably an 'end system' is your business. If you terminate the data at the CNS's TCP, and relay it internally, whether by TCP or anything else, that seems your perogative. Agreed, it does still 'break' things, and certainly makes the window management challenging, but all three TCPs on your end (your source/sink, and both sides of the proxy) are arguably inside the same 'end system' in this case, no? If so, that's easier to handle (you can coordinate the window changes out-of-band) than dealing with a third-party proxy elsewhere in the path. Joe | On Mar 1, 2005, at 9:31 PM, Jonathan Shapiro wrote: | |> I recently had occaision to read a few papers about the practice of |> "TCP spoofing" over satellite links---i.e inserting a proxy prior to |> the satellite link to provide TCP feedback to the sender, effectively |> splitting into two TCP sessions connected in tandem. I was wondering |> if anyone had ever proposed a similar idea to improve TCP throughput |> in overlay networks over terestrial links. |> |> /jonathan shapiro | | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCJ4Y5E5f5cImnZrsRAlS+AKCyFkqASPkIzAlZ2eMgoiLsRm+9JwCglWss dys2ZHxWkHgQrXdMSQLO6hc= =JEgK -----END PGP SIGNATURE----- From Reiner.Ludwig at ericsson.com Thu Mar 3 20:35:26 2005 From: Reiner.Ludwig at ericsson.com (Reiner Ludwig) Date: Fri, 04 Mar 2005 05:35:26 +0100 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> Message-ID: <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> At 15:32 03.03.05, Lloyd Wood wrote: >> And, I think that all of this is well in line with the e2e argument: >> "best effort" = "try until congestion forces you to drop". > >That's not an e2e argument. The end-to-end paper was first presented >at a conference in 1981. Nagle's RFC896 advice on ameliorating >congestion dates from 1984. > >The end-to-end paper is a comment on systems engineering. It is not a >comment on congestion. I was refering to the e2e argument paper by J.H. Saltzer, D.P. Reed and D.D. Clark from 1984. That paper is frequently referenced (and rightfully so) when argueing that "hop-by-hop functions can not replace an end-to-end function". There seems to be little doubt in the networking community about this e2e argument when discussing functions like 'reliablity'. After 1984, the e2e argument was then also used in the context of the function 'congestion control' (e.g., see discussions on IP vs. X.25). However, the paper also discusses performance in a section called 'Performance aspects': "Clearly, some effort at the lower levels to improve network reliability can have a significant effect on application performance. But the key idea here is that the lower levels need not provide "perfect" reliability. Thus the amount of effort to put into reliability measures within the data communication system is seen to be an engineering tradeoff based on performance, rather than a requirement for correctness." In 1984, the paragraph above made a lot of sense, I think. But since 1988, when V. Jacobson had introduced 'e2e congestion control' and an 'adaptive e2e retransmission timer' that also adapts to RTT variations, I don't think that the paragraph's statement on "no need for perfect reliability" holds any longer; at least not in general and not for the case of 'L2 ARQ'. But you're right, the e2e argument paper does not define the term 'best-effort'. Has it ever been defined? ///Reiner From papiraki at gmail.com Fri Mar 4 05:33:48 2005 From: papiraki at gmail.com (Emmanuel Papirakis) Date: Fri, 4 Mar 2005 08:33:48 -0500 Subject: [e2e] Skype and congestion collapse. Message-ID: <11ad0fa8050304053342514f51@mail.gmail.com> Hello, a VoIP application called Skype is gaining more and more popularity. I did a basic capture using Ethereal. It seems that it continuously sends data at a rate of 10 KB/sec. Obviously, it does not use a sliding window mechanism nor does it consider the rate at which the receiver is able to receive data. Furthermore, it does not attempt to detect periods of silence and during those, it continues to send data at its 10KB/sec constant bit rate. A colleague of mine is very enthousiastic about Skype as it saves him a lot of money on his long distance bills. According to his vision of Skype, one day, everybody is going to use Skype.... This scares me. Intuitively, this looks like the perfect recipe for a congestion collapse. But, he argues that this could not be the case as there are miles and miles of unused copper and fiber opticts out there and that more bandwidth is widely available across the world... IMHO, I think that applications like Skype should be responsible for managing the congestion they could potentially cause. This brings me to my question. If more and more applications start to behave like Skype and selfishly worry more about their business model than about the health of the global Internet, is there still a possibility of a congestion collapse today ? Or, are those worries well behind because the problem can be compensated by introducing more bandwidth into the network ? Thank you Emmanuel -- UNIX IS very user friendly. It is just selective about its friends... From Jon.Crowcroft at cl.cam.ac.uk Fri Mar 4 06:30:07 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 04 Mar 2005 14:30:07 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from Emmanuel Papirakis of "Fri, 04 Mar 2005 08:33:48 EST." <11ad0fa8050304053342514f51@mail.gmail.com> Message-ID: well so a back of the envelope calculation on skype would tell you that even if everyone ran it, 24*7, there must be enough capacity in the world for it - 1/ the PSTN has virtually zero call blocking probability in most europe and north america- so the underlying network has enough for 64kbps, and skype is using 6 times less than that 2/ the internet is no longer an overlay on the core PSTN -= the core internet has its own capacity - in the UK, just one ISP for example, the UK academic net, has a 10Gbps backbone - there are several that big in the UK and many european countries are similar 10Gbps is enough for 10M skype calls - thats 1/5 of the UK population talking simulataneously assuming there is NO locality of calls... if there's any locality at all (and there usually is, even ifd just becuase of timezone differences (ok i know there's not much timezone in the uK - ok, language differences, work, lunch breaks etc) then its no problem... it would not be hard to upgrade the natl net to 40Gbps - in th next few years it ought to be easy to go another order of magnitude without layering any more core fiber (just more lambdas) if there is a bandwidth crunch, imho, the solution is to do probe/measurement based end user call admission control. There is not a lot of room for congestion control _below_ 10kbps oh, skype isnt truly p2p afaik, it has servers- they will get congested LONG before the net does. If they don't, it will be because they have to raise revenue to scale them up - to do that, they will have to charge people - if they generate more than a modest amount of traffic they will have to co-lo in POPs which means they'll have to rent rack space and other facilities - this will quicky mean they rate limit themselves at the aggregate level why use skype anyhow when you can use ichat, marratech and other fine tools that allow video, shared whiteboards and have really really nice interfaces? oh, ok, i admit it - skype is pretty cool:) (I am tempted to say that the internet is in fact a shared illusion caused by a deficit of information, and that in reality, all those pixels lighting up on the screen in front of You<---->Right Now, are just fragements of a dream.) (p.s. I am even more tempted after recent food scares in the UK to say: - Additive Increase: just say no. - Multiplicative Decrease: its too too devisive. - On or off, that should be good enough for the law of large numbers... just given a big enough dice. this is the voice of the mysterons... ... ... In missive <11ad0fa8050304053342514f51 at mail.gmail.com>, Emmanuel Papirakis typed: >>Hello, >> >>a VoIP application called Skype is gaining more and more popularity. I >>did a basic capture using Ethereal. It seems that it continuously >>sends data at a rate of 10 KB/sec. >> >>Obviously, it does not use a sliding window mechanism nor does it >>consider the rate at which the receiver is able to receive data. >>Furthermore, it does not attempt to detect periods of silence and >>during those, it continues to send data at its 10KB/sec constant bit >>rate. >> >>A colleague of mine is very enthousiastic about Skype as it saves him >>a lot of money on his long distance bills. According to his vision of >>Skype, one day, everybody is going to use Skype.... >> >>This scares me. Intuitively, this looks like the perfect recipe for a >>congestion collapse. But, he argues that this could not be the case as >>there are miles and miles of unused copper and fiber opticts out there >>and that more bandwidth is widely available across the world... >> >>IMHO, I think that applications like Skype should be responsible for >>managing the congestion they could potentially cause. This brings me >>to my question. If more and more applications start to behave like >>Skype and selfishly worry more about their business model than about >>the health of the global Internet, is there still a possibility of a >>congestion collapse today ? Or, are those worries well behind because >>the problem can be compensated by introducing more bandwidth into the >>network ? >> >>Thank you >> >>Emmanuel >> >>-- >>UNIX IS very user friendly. It is just selective about its friends... cheers jon From davide+e2e at cs.cmu.edu Fri Mar 4 06:47:24 2005 From: davide+e2e at cs.cmu.edu (Dave Eckhardt) Date: Fri, 04 Mar 2005 09:47:24 -0500 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: Message-ID: <6693.1109947644@piper.nectar.cs.cmu.edu> > I am constantly amazed by how you appear to be reading entirely > different papers and emails to everyone else. Might we discuss this issue in terms of technical merit, data, etc.? Dave Eckhardt From Jon.Crowcroft at cl.cam.ac.uk Fri Mar 4 06:51:12 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 04 Mar 2005 14:51:12 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from Lloyd Wood of "Fri, 04 Mar 2005 14:43:00 GMT." Message-ID: it was an ALLUSION, and it wasnt erudite gosh, i thought that was obvious of course, I am very rarely original, but also rarely wrong (i could go on, but that would be another allusion). btw, faking or spotting allusions Gibson isn't erudite - its like spotting the unoriginal bits in hitchikers guide to the galaxy here's your starter for 10: who really wrote Venus on the Half Shell, and what is the nom de plume a gag about, and dont get me started on the number of sheckley stories that are also lifeted (but made funnier therein)? if you can't be funny, can't dance, and are not food, you know where you can go. [another allusion...] meanwhile, hold the conversation, i have a call on the other skype line... In missive , Lloyd Wood typed: >>On Fri, 4 Mar 2005, Jon Crowcroft wrote: >> >>> (I am tempted to say that the internet is in fact a shared illusion >> >>Cyberspace. A consensual hallucination experienced daily by billions >>of legitimate operators, in every nation, by children being taught >>mathematical concepts... A graphic representation of data abstracted >>from the banks of every computer in the human system. Unthinkable >>complexity. - William Gibson, _Neuromancer_. >> >>L. >> >>if you can't be original, be erudite. >> >>> caused by a deficit of information, and that in reality, all those >>> pixels lighting up on the screen in front of You<---->Right Now, >>> are just fragements of a dream.) >> >> >> cheers jon From dpreed at reed.com Fri Mar 4 07:27:16 2005 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Mar 2005 10:27:16 -0500 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> Message-ID: <42287E54.7040907@reed.com> Just a comment on the Saltzer, Reed, and Clark paper's dates, from one of the co-authors. It's very misleading to compare dates of publication. It was first drafted in late 1978/early 1979, based on my work on my Ph.D. thesis completed that year plus my work on TCP in 1976-1977. In those days it was not atypical to submit a paper for publication in the systems literature and have it take 3 or more years in the pipeline before acquiring a pub date. I gave visitor talks on some of the ideas in 1978 and 1979 as I visited many colleagues around the world, for example at IBM Zurich, Caltech, etc. The genesis of the paper was in my collaborations with my mentor Jerry Saltzer, Dave Clark, and other MIT systems faculty focusing on architectural principles relating to OS's (my S.m. thesis on processor multiplexing in a layerd OS), security (the Multics security kernel work), and network layering choices... In particular it was that Jerry Saltzer, my advisor said to me: David, throughout your thesis and in your reports of the arguments being made about layering in TCP and IP, you keep making the same sort of argument - move the function to the edges of the network, and avoid putting function in the network itself, even when it feels a bit "unnatural". The common argument made by most designers in system design (OS and networks) is to move everything into the common OS and network. So this is really an underappreciated and new design/architectural principle. We should write a paper about it, because it really is not intuitive to many in the field, but it seems important. We did, and since it was such a nice simple example, we used end-to-end reliable delivery as our iconic example, but pointed out how general the idea was and that it was a general form of argumentation that made sense in the systems design world that has to deal with pragmatics of systems that must have a long life, scale across a wide range, and accomodate new, unanticipated applications. Many people read and commented on it in draft form, and it was presented and published in several places. Note that we didn't invent the instances of the end-to-end argument (in fact we took the name from the common terminology in the TCP design team of TCP as an end-to-end protocol, overlaid on a heterogeneous set of networks). We just pointed out that many of the design arguments that we and others in the community were making had that form, and tried to elucidate the benefits of following the argument (primarily in the form of design in the face of unknown and unknowable future needs). From label_label_label_label at yahoo.com Fri Mar 4 08:10:56 2005 From: label_label_label_label at yahoo.com (Zaphod Beeblebrox) Date: Fri, 4 Mar 2005 08:10:56 -0800 (PST) Subject: [e2e] Skype and congestion collapse. In-Reply-To: 6667 Message-ID: <20050304161056.8240.qmail@web51302.mail.yahoo.com> If this is a user feedback, then I must admit it is pretty horrible from where I sit, though better than the standard ones on most IMs. Probably because someone is footing the bill for my bandwidth and Service providers still do not seem to have a fantastic revenue model to sell the access to their fascinating high speed core cheap (or maybe it just happened to be that my alma matter had a gig ring but not much to the external world while my office does not think it is worth paying the horrbile amount they charge) Hey whadda you know MCI was taken over... NSFNET was a research club I guess, who cares when someone else is footing the bill..... I want to start my service too, no chapter XIs here :( __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kempf at docomolabs-usa.com Fri Mar 4 09:17:54 2005 From: kempf at docomolabs-usa.com (James Kempf) Date: Fri, 4 Mar 2005 09:17:54 -0800 Subject: [e2e] Skype and congestion collapse. References: Message-ID: <099601c520de$1f4cc2c0$016115ac@dcml.docomolabsusa.com> Jon, Maybe for the backbone, but what about the access networks? Capacity there is usually a lot less. See RFC 3714 for some musings Sally Floyd and I went through on this topic. jak ----- Original Message ----- From: "Jon Crowcroft" To: "Emmanuel Papirakis" Cc: ; Sent: Friday, March 04, 2005 6:30 AM Subject: Re: [e2e] Skype and congestion collapse. > well so a back of the envelope calculation on skype would tell you that > even if everyone ran it, 24*7, > there must be enough capacity in the world for it - > > 1/ the PSTN has virtually zero call blocking probability in most europe > and north america- so the underlying network has enough for 64kbps, and > skype is using 6 times less than that > > 2/ the internet is no longer an overlay on the core PSTN -= the core > internet has its own capacity - in the UK, just one ISP for example, the > UK academic net, has a 10Gbps backbone - there are several that big in > the UK and many european countries are similar > > 10Gbps is enough for 10M skype calls - thats 1/5 of the UK population > talking simulataneously assuming there is NO locality of calls... > if there's any locality at all (and there usually is, even ifd just > becuase of timezone differences (ok i know there's not much timezone in > the uK - ok, language differences, work, lunch breaks etc) then its no > problem... > > it would not be hard to upgrade the natl net to 40Gbps - > > in th next few years it ought to be easy to go another order of > magnitude without layering any more core fiber (just more lambdas) > > if there is a bandwidth crunch, imho, the solution is to do probe/measurement > based end user call admission control. There is not a lot of room for > congestion control _below_ 10kbps > > oh, skype isnt truly p2p afaik, it has servers- they will get > congested LONG before the net does. If they don't, it will be because > they have to raise revenue to scale them up - to do that, they will have > to charge people - if they generate more than a modest amount of traffic > they will have to co-lo in POPs which means they'll have to rent rack > space and other facilities - this will quicky mean they rate limit > themselves at the aggregate level > > why use skype anyhow when you can use ichat, marratech and other fine > tools that allow video, shared whiteboards and have really really nice > interfaces? > > oh, ok, i admit it - skype is pretty cool:) > > > (I am tempted to say that the internet is in fact a shared illusion > caused by a deficit of information, and that in reality, all those > pixels lighting up on the screen in front of You<---->Right Now, > are just fragements of a dream.) > > (p.s. I am even more tempted after recent food scares in the UK to say: > > - Additive Increase: just say no. > - Multiplicative Decrease: its too too devisive. > - On or off, that should be good enough for the law of large numbers... > just given a big enough dice. > > this is the voice of the mysterons... ... ... > > In missive <11ad0fa8050304053342514f51 at mail.gmail.com>, Emmanuel Papirakis typed: > > >>Hello, > >> > >>a VoIP application called Skype is gaining more and more popularity. I > >>did a basic capture using Ethereal. It seems that it continuously > >>sends data at a rate of 10 KB/sec. > >> > >>Obviously, it does not use a sliding window mechanism nor does it > >>consider the rate at which the receiver is able to receive data. > >>Furthermore, it does not attempt to detect periods of silence and > >>during those, it continues to send data at its 10KB/sec constant bit > >>rate. > >> > >>A colleague of mine is very enthousiastic about Skype as it saves him > >>a lot of money on his long distance bills. According to his vision of > >>Skype, one day, everybody is going to use Skype.... > >> > >>This scares me. Intuitively, this looks like the perfect recipe for a > >>congestion collapse. But, he argues that this could not be the case as > >>there are miles and miles of unused copper and fiber opticts out there > >>and that more bandwidth is widely available across the world... > >> > >>IMHO, I think that applications like Skype should be responsible for > >>managing the congestion they could potentially cause. This brings me > >>to my question. If more and more applications start to behave like > >>Skype and selfishly worry more about their business model than about > >>the health of the global Internet, is there still a possibility of a > >>congestion collapse today ? Or, are those worries well behind because > >>the problem can be compensated by introducing more bandwidth into the > >>network ? > >> > >>Thank you > >> > >>Emmanuel > >> > >>-- > >>UNIX IS very user friendly. It is just selective about its friends... > > cheers > > jon > > From dpreed at reed.com Fri Mar 4 11:09:39 2005 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Mar 2005 14:09:39 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <11ad0fa8050304053342514f51@mail.gmail.com> References: <11ad0fa8050304053342514f51@mail.gmail.com> Message-ID: <4228B273.80102@reed.com> I was going to give a technical response, but it might be better to think whether the question is at all meaningful. Why would Skype be worse than RealVideo, which continuously sends at hundreds of kb/sec, or internet radio, which does no silence suppression, and listeners listen to continuously longer than I typically converse on the phone? These are in heavy use today. Or bittorrent, which when I use it generates bits at me at about 500 KB/sec? What about H.323 video conferencing, also very common in networks that have moderate capacity? Congestion collapse is a well-defined term. It's not the plural of "heavy user". And people pay 10's of dollars per month to their provider to build out access infrastructure that is today orders of magnitude more capacious than the trivial load of 10 KB/sec only when the user is actually making a phone call. Getting real, it's important to realize that "silence suppression" is not what prevents congestion in the phone network. If so, we could bring the phone network down by placing calls and "all together now" shouting "Now" at precisely midnight on March 15th. Of course, Chicken Little got lots of attention by worrying people that the sky is falling, the sky is falling.... maybe the magic words "congestion collapse" can create a magical fantasy world for those who find horror movies believable, that firewalls make a system secure, or who think the TSA's function is to stop terrorists rather than to make the public feel protected. From algold at rnp.br Fri Mar 4 11:22:36 2005 From: algold at rnp.br (Alexandre L. Grojsgold) Date: Fri, 4 Mar 2005 16:22:36 -0300 (E. South America Standard Time) Subject: [e2e] Skype and congestion collapse. In-Reply-To: <11ad0fa8050304053342514f51@mail.gmail.com> References: <11ad0fa8050304053342514f51@mail.gmail.com> Message-ID: > IMHO, I think that applications like Skype should be responsible for > managing the congestion they could potentially cause. This brings me > to my question. If more and more applications start to behave like > Skype and selfishly worry more about their business model than about > the health of the global Internet, I guess that what you mean is that Skipe does not use TCP-like bandwidth reduction, so it selfishly does not give up sending 10Kbps even in case of congestion. Well, one must have in mind that at the end of a skype voice connection ther is as human being that, in case of congestion and excessive packet loss will simply hang up the call - or even be so unhappy that he will never try calling thru Skype again. Probably the "selfish" behavior if skipe is due to the fact that it is unable to make voice go thru using less than 10k - lessening the bandwidth would be useless, so in case of congestion, it will simply hang up - or wait till the user gives up. -- Alexandre. From don at dhoffman.net Fri Mar 4 05:18:36 2005 From: don at dhoffman.net (Donald Hoffman) Date: Fri, 4 Mar 2005 13:18:36 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <11ad0fa8050304053342514f51@mail.gmail.com> References: <11ad0fa8050304053342514f51@mail.gmail.com> Message-ID: <200503041318.37290.don@dhoffman.net> Note that the voice channel for Skype is not at all elastic. As a general rule effectively all VoIP traffic is totally inelastic. You get either all the flow or none. This not specific to Skype. Back in the mid-90s , there were lots of folks looking at mechanisms to make such media flows adaptive in the face of congestion (e.g., Steve McCanne's work.. some stuff I did with Michael Speer) Interesting stuff, but there were a couple of things which kept such approaches from taking off: 1) For the most part codecs are not continuously adjustable in terms of bandwidth. They tend to jump in discrete steps that can be fairly large. E.g., when you jump between major classes of codecs, or when you use typical layering approaches. There was some work in video codecs with lots of steps (e.g., we worked with some stuff Avideh Zakhor did), but none of them seemed to have gained any commercial traction. I think most commercially-oriented work just tried to get as much quality with as little bandwidth as possible. I am certainly not an expert in this area (codec design), but I am guessing that the additional complexity of getting such fined-grained layering was in practical tension with just getting good quality at low cost (complexity and bandwidth). The small number of steps combined with the size of each step made such approaches not worth the trouble for congestion control. They work best for dealing with heterogenous link characteristics (e.g., broadband vs skinny wireless). Skype basically has picked one of the best low bandwidth codecs around that still gives good quality (see RFC 3951 which describes the codec they are reputedly using). Skype claim (on their web site) to vary the bandwidth between 3-16kbps depending on the quality of your link. The iLBC spec suggests two framings which would give effective rates of 15-20Kbps, so that is in some conflict with the Skype claims and is by no means adaptive. This codec does have some nice error concealment properties that mean random congestion-induced drops will not totally trash your voice stream, so while the other TCP flows are backing off to make room for your inelastic flow (or when they rudely try to probe for more bandwidth) you can continue to talk :-). In any event, once you have picked the best audio codec you can, at the lowest rate, there is really no multiplicative decrease possible. This is the way it is for effectively all VoIP traffic today. At least Skype is not using G.711. I think you will see all VoIP endpoints converging to something like the codec Skype is using. For example, most recent SIP ATAs support G729 (some support iLBC), which is (IIRC) about the same bandwidth. 2) So the other solution suggested at the time was to do network admission control. No need to go into that one here (I am in the RSVP witness protection program :-)) other than to say that complexity lost out again. Cheaper just to provision more bandwidth. In fact, Jon's later comment points out that this has become true for the backbone. James later made a comment that the main problem is actually at the access link. I agree. But the problem in this case is not with the VoIP traffic, it is with the OTHER traffic. If I am using VoIP and just web browsing on a reasonable link, there is generally no problem. The small number of non-VoIP TCP connections generally leave enough fair share for my frugal voice connection. However, my current day job is to design and implement P2P protocols. Generally such protocols can create large numbers of TCP connections per node. A that point, even with ideal fairness, the proportion of the link left over is less than required for the voice stream. (Obviously, from a practical standpoint, it is much worse.) So although the individual TCP flows may be well behaved, the P2P application as a whole is not. This is kind of like the original Netscape/HTTP1.0 problem, but on steroids. Don From cannara at attglobal.net Fri Mar 4 12:24:34 2005 From: cannara at attglobal.net (Cannara) Date: Fri, 04 Mar 2005 12:24:34 -0800 Subject: [e2e] 10% packet loss stops TCP flow References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> Message-ID: <4228C402.5CCA9E0@attglobal.net> Adding to Reiner's comments -- serendipitously, I just assisted a consulting customer with a 10% packet loss problem. Plain TCP performance dropped by over a factor of 3, simply because of a faulty DSLAM at the local ISP. Riding along on the same link was a similar amount of VPN traffic. It was largely unaffected by the losses, because it's transported in UDP and has its own recovery processes that work faster than normal TCP. The TCP traffic showed all the proper timeout, fast-retransmit, etc. behavior, yet was brought to it knees by the modest loss rate. This, in an environment with RTTs around .1s. Having elsewhere seen less than 1% loss yield a 20% TCP slowdown on even faster links with the same RTT, it's not at all surprising that TCP's behavior is poor when it shouldn't be. The arguments against perfection in lower layers are naive in a few clear respects: a) the RTT values TCP sees have little to do with the delays that links in any path see; b) the recovery/prevention techniques at lower layers can be far quicker and more effective than TCP's; c) historically, TCP's concepts of link management exclude error sensing, thus exposing an Achille's heel no "transport" protocol should; and d) protocol development was stopped, for the Internet, for reasons other than perfection. Point a) refers to how data handling in PSTNs has been well managed for decades (flow control, error correction...). Point b) is related to that and how well even LAN-links handle recovery, as Ethernet does under collision loss by retransmission within microseconds, not seconds. Point c) simply refers to the myopic, rushed design of TCP's 'congestion control' functions, at the wrong layer and without proper distinguishing of loss types; and, that TCP is not the only transport traffic. The satellite and space-probe folks have long done better, because they thought and did more about link and transport problems. -- Alex From cannara at attglobal.net Fri Mar 4 12:36:57 2005 From: cannara at attglobal.net (Cannara) Date: Fri, 04 Mar 2005 12:36:57 -0800 Subject: [e2e] Skype and congestion collapse. References: <11ad0fa8050304053342514f51@mail.gmail.com> Message-ID: <4228C6E9.E6718A3D@attglobal.net> Having consulted with folks doing products for tracking/controlling these kinds of traffic, any P2P system that takes whatever it can isn't really to blame. Even VoIP is being used to transfer data (not just voice) now. Any 'internet' that can't manage its congestion at the network layer isn't an internetwork. So, apart from all the other Internet mistakes, like insecurity, which many of us earn $ from, we've also earned from misdesigned congestion control. The difference between old-fashioned PSTNs and the Internet are making the latter look more silly and wasteful day by day. Despite the $, I hope some awakening occurs, but we, the taxpayers, will again have to pay for any eventual, engineered and real internetwork. Alex "Alexandre L. Grojsgold" wrote: > > > IMHO, I think that applications like Skype should be responsible for > > managing the congestion they could potentially cause. This brings me > > to my question. If more and more applications start to behave like > > Skype and selfishly worry more about their business model than about > > the health of the global Internet, > > I guess that what you mean is that Skipe does not use TCP-like bandwidth > reduction, so it selfishly does not give up sending 10Kbps even in case of > congestion. > > Well, one must have in mind that at the end of a skype voice connection > ther is as human being that, in case of congestion and excessive packet > loss will simply hang up the call - or even be so unhappy that he will > never try calling thru Skype again. > > Probably the "selfish" behavior if skipe is due to the fact that it is > unable to make voice go thru using less than 10k - lessening the bandwidth > would be useless, so in case of congestion, it will simply hang up - or > wait till the user gives up. > > -- Alexandre. From don at dhoffman.net Fri Mar 4 05:50:07 2005 From: don at dhoffman.net (Donald Hoffman) Date: Fri, 4 Mar 2005 13:50:07 +0000 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: <4228C402.5CCA9E0@attglobal.net> References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> <4228C402.5CCA9E0@attglobal.net> Message-ID: <200503041350.07625.don@dhoffman.net> On Fri March 4 2005 8:24 pm, Cannara wrote: > Riding along on the same link was a similar amount of VPN > traffic. It was largely unaffected by the losses, because it's transported > in UDP and has its own recovery processes that work faster than normal TCP. This may be a stupid question as I have not worked on commercial VPNs for many years, but what recovery mechanism would the VPN tunnel be using. Most VPN's I was aware of just encapsulate the traffic in a tunnel and provided no additional error recovery services. Is this a common feature? Don From swb at employees.org Fri Mar 4 12:51:59 2005 From: swb at employees.org (Scott W Brim) Date: Fri, 4 Mar 2005 15:51:59 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: <11ad0fa8050304053342514f51@mail.gmail.com> Message-ID: <20050304205159.GF5440@sbrim-w2k02> On Fri, Mar 04, 2005 04:22:36PM -0300, Alexandre L. Grojsgold allegedly wrote: > Well, one must have in mind that at the end of a skype voice connection > ther is as human being that, in case of congestion and excessive packet > loss will simply hang up the call - or even be so unhappy that he will > never try calling thru Skype again. When I was playing with low bandwidth video we backed off the transmit rate only so far -- below a certain point it wasn't worthwhile, so we stayed at our minimum and accepted whatever happened. From michael.welzl at uibk.ac.at Fri Mar 4 13:12:34 2005 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Fri, 4 Mar 2005 22:12:34 +0100 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <4228B273.80102@reed.com> Message-ID: > Why would Skype be worse than RealVideo, which continuously sends at > hundreds of kb/sec, or internet radio, which does no silence You're doing the Real folks wrong: in our tests, RealVideo _DID_ react to congestion. The way it did so was a little strange, but what the heck, eventually it reduced its rate. Having tested a number of other applications, I'd say that this is more than you could hope for :-) > Congestion collapse is a well-defined term. It's not the plural of I disagree: ftp://ftp.rfc-editor.org/in-notes/rfc896.txt versus http://www.cse.ohio-state.edu/~jain/papers/cr1.htm versus http://www.icir.org/floyd/end2end-paper.html ... three entirely different reasons for a similar effect. So how is it defined? I think we all share the general idea that the "collapse" is when the network just becomes unusable, but I'm not sure whether we have a really concise definition that is generally agreed upon. Cheers, Michael From cannara at attglobal.net Fri Mar 4 13:52:45 2005 From: cannara at attglobal.net (Cannara) Date: Fri, 04 Mar 2005 13:52:45 -0800 Subject: [e2e] 10% packet loss stops TCP flow References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> <4228C402.5CCA9E0@attglobal.net> <200503041350.07625.don@dhoffman.net> Message-ID: <4228D8AD.71B51E2F@attglobal.net> It does depend on the tunnel options, for some systems, but in the case I mentioned, which is mostly tunnelled Citrix traffic, that tends to take care of itself, independently of the tunnel. Alex Donald Hoffman wrote: > > On Fri March 4 2005 8:24 pm, Cannara wrote: > > Riding along on the same link was a similar amount of VPN > > traffic. It was largely unaffected by the losses, because it's transported > > in UDP and has its own recovery processes that work faster than normal TCP. > > This may be a stupid question as I have not worked on commercial VPNs for many > years, but what recovery mechanism would the VPN tunnel be using. Most VPN's > I was aware of just encapsulate the traffic in a tunnel and provided no > additional error recovery services. Is this a common feature? > > Don From Venkata.Naidu at Marconi.com Fri Mar 4 14:05:11 2005 From: Venkata.Naidu at Marconi.com (Naidu, Venkata) Date: Fri, 4 Mar 2005 17:05:11 -0500 Subject: [e2e] Skype and congestion collapse. Message-ID: <5551AD75D2C0BC459A85A2CEFAE4F80050C744@usvissfp01.win.marconi.com> -> > Why would Skype be worse than RealVideo, which -> continuously sends at -> > hundreds of kb/sec, or internet radio, which does no silence -> -> You're doing the Real folks wrong: in our tests, RealVideo -> _DID_ react to -> congestion. The way it did so was a little strange, but what -> the heck, -> eventually it reduced its rate. Having tested a number of other -> applications, I'd say that this is more than you could hope for :-) So, you agree that an Internet application can use as much bandwidth as it desires. Skype is not doing anything wrong by using 10's of Kbps. The worry is that it is using bandwidth 'constantly' with out reacting to congestion. Then the fix should not be imposed on applications. If we go in that direction, we end up abandoning hundreds of UDP applications. Simple way is to migrate them to congestion aware transport protocols. But, may be it is too late now. May be David Reed can enlighten us here - when pioneers were designing UDP protocol, they might have expected that all UDP applications would obey some Internet commandments. Unfortunately, that expectation turned into a loophole now. Venkata. From gaylord at dirtcheapemail.com Fri Mar 4 14:37:44 2005 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Fri, 04 Mar 2005 17:37:44 -0500 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: <200503041350.07625.don@dhoffman.net> References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> <4228C402.5CCA9E0@attglobal.net> <200503041350.07625.don@dhoffman.net> Message-ID: <4228E338.7050401@dirtcheapemail.com> Donald Hoffman wrote: >On Fri March 4 2005 8:24 pm, Cannara wrote: > > >>Riding along on the same link was a similar amount of VPN >>traffic. It was largely unaffected by the losses, because it's transported >>in UDP and has its own recovery processes that work faster than normal TCP. >> >> > >This may be a stupid question as I have not worked on commercial VPNs for many >years, but what recovery mechanism would the VPN tunnel be using. Most VPN's >I was aware of just encapsulate the traffic in a tunnel and provided no >additional error recovery services. Is this a common feature? > > But they don't tunnel with TCP and they can have their own buffer/retransmission methods. That's not to say that VPNs aren't susceptible to packet loss, but they can add a layer of resiliency to an otherwise broken link layer. --ckg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050304/be3e9e91/attachment-0001.html From gaylord at dirtcheapemail.com Fri Mar 4 14:47:49 2005 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Fri, 04 Mar 2005 17:47:49 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <200503041318.37290.don@dhoffman.net> References: <11ad0fa8050304053342514f51@mail.gmail.com> <200503041318.37290.don@dhoffman.net> Message-ID: <4228E595.9030407@dirtcheapemail.com> Donald Hoffman wrote: >But the problem in this case is not with the VoIP traffic, it is with the >OTHER traffic. If I am using VoIP and just web browsing on a reasonable >link, there is generally no problem. The small number of non-VoIP TCP >connections generally leave enough fair share for my frugal voice connection. >However, my current day job is to design and implement P2P protocols. >Generally such protocols can create large numbers of TCP connections per >node. A that point, even with ideal fairness, the proportion of the link >left over is less than required for the voice stream. (Obviously, from a >practical standpoint, it is much worse.) So although the individual TCP >flows may be well behaved, the P2P application as a whole is not. This is > > This is why we really do need some notion of QoS other than The Fat Pipe. It doesn't have to be as elaborate as RSVP-disciplined CAC, but you need to be able to prioritize traffic that matters and limit the amount of traffic that gets prioritized. It doesn't have to be more complex than that, but it has to do at least that. [Ergo ... left as an exercise to the reader.] Another limiter that would be cool is on the number of flows, but that isn't there yet. --ckg From gaylord at dirtcheapemail.com Fri Mar 4 14:54:22 2005 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Fri, 04 Mar 2005 17:54:22 -0500 Subject: [e2e] 10% packet loss stops TCP flow In-Reply-To: <4228C402.5CCA9E0@attglobal.net> References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> <4228C402.5CCA9E0@attglobal.net> Message-ID: <4228E71E.2060900@dirtcheapemail.com> Cannara wrote: >Point a) refers to how data handling in PSTNs has been well managed for >decades (flow control, error correction...). Point b) is related to that and > > Yeah, I was just noticing how much X.25 my local provider sells ... I'm gonna have to get me some of that. --ckg From marc.herbert at free.fr Fri Mar 4 15:38:31 2005 From: marc.herbert at free.fr (Marc Herbert) Date: Sat, 5 Mar 2005 00:38:31 +0100 (CET) Subject: [e2e] Skype and congestion collapse. In-Reply-To: <4228B273.80102@reed.com> References: <11ad0fa8050304053342514f51@mail.gmail.com> <4228B273.80102@reed.com> Message-ID: On Fri, 4 Mar 2005, David P. Reed wrote: > I was going to give a technical response, but it might be better to > think whether the question is at all meaningful. > > Why would Skype be worse than RealVideo, which continuously sends at > hundreds of kb/sec, or internet radio, which does no silence > suppression, and listeners listen to continuously longer than I > typically converse on the phone? These are in heavy use today. > > Or bittorrent, which when I use it generates bits at me at about 500 KB/sec? I am a basic consumer and I subscribed to this cheap DSL line. I use Bittorrent and emule, as well as Skype and some real-time video games. I don't really understand your discussion because it seems to me that Skype and gaming are the victims and not the issue. I tell you why: I can't play or phone and download at the same time. Actually I can, but then the phoning or gaming experience is randomly (but then severly!) disturbed: the phone communication seems to suddenly go through some satellite, and the games become totally unresponsive, unplayable. At first I did not understand why but then some gamers told me "you're lagging, don't download while you play, stop downloading!". This seemed so evident to them, they instantly knew I was a newbie. Well recently some network wizard friend of mine tried to explain to me that I actually can do everything simultaneously thanks to very tricky computations and the use of some weird tweaks like "--max_upload_rate" in bittorrent or bizarre settings in emule ("max bandwith", "max connections", "max connections per 5s", etc.) After a lot of hair-pulling (and a lot of crappy calls and games) I was pleased we finally figured out a more or less stable "network configuration" (that's how my friend calls it). But the other day I was using Skype with my brother and he told me "check the movie I sent to you", so I opened my mailbox and it went wrong again! I could not talk to him until the movie was downloaded. When I told that to my friend, he laughed at me and said : "Great! You learned about parallelism through time-sharing". This did not help me much. I am a bit disappointed, especially since I learned that my ISP will soon "upgrade my line capacity": I guess I will have to go through all these difficult computations again. Another thing worries me: my wife wants to buy an iBook and share the DSL line with me. I think we will go back to the point where we use the network only one application at a time. This is surely some kind of waste but at least this is simple and we are sure it works fine. Glad our house is not so big, so we can shout to the other when the internet line is free. > What about H.323 video conferencing, also very common in networks that > have moderate capacity? > > Congestion collapse is a well-defined term. It's not the plural of > "heavy user". Sorry if my terms are not well-defined. I hope you nevertheless understand my issue. Cheers, Marc. -- So einfach wie m?glich. Aber nicht einfacher -- Albert Einstein From rja at extremenetworks.com Fri Mar 4 16:42:15 2005 From: rja at extremenetworks.com (RJ Atkinson) Date: Fri, 4 Mar 2005 19:42:15 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <4228E595.9030407@dirtcheapemail.com> References: <11ad0fa8050304053342514f51@mail.gmail.com> <200503041318.37290.don@dhoffman.net> <4228E595.9030407@dirtcheapemail.com> Message-ID: <9531abdc241f450e15fa92b84fe74310@extremenetworks.com> On Mar 4, 2005, at 17:47, Clark Gaylord wrote: > This is why we really do need some notion of QoS other than The Fat > Pipe. It doesn't have to be as elaborate as RSVP-disciplined CAC, but > you need to be able to prioritize traffic that matters and limit the > amount of traffic that gets prioritized. It doesn't have to be more > complex than that, but it has to do at least that. [Ergo ... left as > an exercise to the reader.] I don't know that the "network" needs to have a more sophisticated notion of QoS than best effort. It can sometimes be useful for the network device connected directly to a congested link (e.g. access link between a site and its upstream provider) to have some internal-to-the-box QoS configuration. It is not uncommon these days for the access router at the customer premise to have some ACL ruleset that prefers some traffic over other traffic or rate-limits certain kinds of traffic -- and equivalent configuration of the aggregation router on the ISP side of the same link is also not uncommon these days. That said, most congestion today occurs either on an access link such as that or on some sort of wireless link (e.g. SATCOM to SW Asia). ISP core backbones tend to be over-provisioned. Most campus (wired/fibred) networks are similarly over-provisioned. Ran From huitema at windows.microsoft.com Sat Mar 5 00:12:19 2005 From: huitema at windows.microsoft.com (Christian Huitema) Date: Sat, 5 Mar 2005 00:12:19 -0800 Subject: [e2e] Skype and congestion collapse. Message-ID: > So, you agree that an Internet application can use as much bandwidth > as it desires. Skype is not doing anything wrong by using 10's of Kbps. Basically, yes. The Internet should remain stable in the presence of selfish user. In fact, a well designed control algorithm should assume that all users are behaving selfishly. A good place to start may be: S. Shenker, "Making Greed Work in Networks: A Game-Theoretic Analysis of Switch Service Disciplines," in SIGCOMM Symposium on Communications Architectures and Protocols, (London, UK), pp. 47-57, Sept. 1994. -- Christian Huitema From Jon.Crowcroft at cl.cam.ac.uk Sat Mar 5 02:32:37 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 05 Mar 2005 10:32:37 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from "James Kempf" of "Fri, 04 Mar 2005 09:17:54 PST." <099601c520de$1f4cc2c0$016115ac@dcml.docomolabsusa.com> Message-ID: In missive <099601c520de$1f4cc2c0$016115ac at dcml.docomolabsusa.com>, "James Kempf" typed: >>Maybe for the backbone, but what about the access networks? Capacity there >>is usually a lot less. contention ratios in broadband access are an issue, but becoming less so with time. bottom libe though is that an ISP that cannot cope with 10kbps (note one 1500 byte MSS TCP packet per second is 12kbps) is in big trouble in the edge net/bottlneck, as with the 10% tcp packet loss problem discussion, the point is not about fancy steady state fluid flow approximations, but about the "corner case" discrete beheaviour of protocols at low rates - so i see skype (and most voip tools) as occupying a convenient niche - i do NOT subscribe to the argument that we could do any application at any fixed rate - if we all took 576kbps DSL lines and sent 24*7 MPEG2, we would (today) cause trouble - but in a few years time, who's to say what the minimum entry point is? >>See RFC 3714 for some musings Sally Floyd and I went through on this topic. sure by the way, Professor Angela Sasse and some PhD students at UCL did some of the definitive work on user acceptance of variable quality video and audio (see links from http://www.cs.ucl.ac.uk/staff/a.sasse/ unlike prior work, they used objective measures (e.g. using questionnaires and mean opinion stuff that goes back to bell labs work 40+ years ago on audio capacity and acceptable latency for interactive work), the experiments (with ethics committee approval) used lie etector type stress measurement (heatbeat, skin conductivity/temperature) while subjects carried out real tasks (e.g. interviewing student applicants to university) over a video link with control groups etc etc - the audio and video qualities were varied under controlled conditions to see if users were more or less stressed - you know what: users do NOT like variable quality -if you aregoing to support a given rate, dont go ABOVE it if you are later going to have to go back down to that rate 0 if you have a lower rate, only support that. this is critical for audio (but less so for video) - so all the work on fancy codecs and user/channel/codec adaption we all did 2 decades back for 10 years - you know, was all misguided. whats more, VERY few codecs actually lend themselves to smooth adaption anyhow - mostly they can only adapt in a fine grain way (the way say a "tcp-friendly" multimedia flow over dccp or other is "supposed to"), at the higher rates - at lower rates, most DCT based video codecs only vary coarse grain (e.g. frame rate or resulution in large steps and audio codec by actually chaning codec altogether) - This only makes matters WORSE from a usability perspective. and not a lot from a network perspective. so if you look at the Book we wrote on all this stuff (Internetworking Multimedia, Handley/Crowcroft/Wakeman - morgan kauffman pubs), we were wrong (though all the stuff on rtp and sip and realtime on IP and multicast there is is still pretty up-to-date:) cheers >>----- Original Message ----- >>From: "Jon Crowcroft" >>To: "Emmanuel Papirakis" >>Cc: ; >>Sent: Friday, March 04, 2005 6:30 AM >>Subject: Re: [e2e] Skype and congestion collapse. >> >> >>> well so a back of the envelope calculation on skype would tell you that >>> even if everyone ran it, 24*7, >>> there must be enough capacity in the world for it - >>> >>> 1/ the PSTN has virtually zero call blocking probability in most europe >>> and north america- so the underlying network has enough for 64kbps, and >>> skype is using 6 times less than that >>> >>> 2/ the internet is no longer an overlay on the core PSTN -= the core >>> internet has its own capacity - in the UK, just one ISP for example, the >>> UK academic net, has a 10Gbps backbone - there are several that big in >>> the UK and many european countries are similar >>> >>> 10Gbps is enough for 10M skype calls - thats 1/5 of the UK population >>> talking simulataneously assuming there is NO locality of calls... >>> if there's any locality at all (and there usually is, even ifd just >>> becuase of timezone differences (ok i know there's not much timezone in >>> the uK - ok, language differences, work, lunch breaks etc) then its no >>> problem... >>> >>> it would not be hard to upgrade the natl net to 40Gbps - >>> >>> in th next few years it ought to be easy to go another order of >>> magnitude without layering any more core fiber (just more lambdas) >>> >>> if there is a bandwidth crunch, imho, the solution is to do >>probe/measurement >>> based end user call admission control. There is not a lot of room for >>> congestion control _below_ 10kbps >>> >>> oh, skype isnt truly p2p afaik, it has servers- they will get >>> congested LONG before the net does. If they don't, it will be because >>> they have to raise revenue to scale them up - to do that, they will have >>> to charge people - if they generate more than a modest amount of traffic >>> they will have to co-lo in POPs which means they'll have to rent rack >>> space and other facilities - this will quicky mean they rate limit >>> themselves at the aggregate level >>> >>> why use skype anyhow when you can use ichat, marratech and other fine >>> tools that allow video, shared whiteboards and have really really nice >>> interfaces? >>> >>> oh, ok, i admit it - skype is pretty cool:) >>> >>> >>> (I am tempted to say that the internet is in fact a shared illusion >>> caused by a deficit of information, and that in reality, all those >>> pixels lighting up on the screen in front of You<---->Right Now, >>> are just fragements of a dream.) >>> >>> (p.s. I am even more tempted after recent food scares in the UK to say: >>> >>> - Additive Increase: just say no. >>> - Multiplicative Decrease: its too too devisive. >>> - On or off, that should be good enough for the law of large numbers... >>> just given a big enough dice. >>> >>> this is the voice of the mysterons... ... ... >>> >>> In missive <11ad0fa8050304053342514f51 at mail.gmail.com>, Emmanuel Papirakis >>typed: >>> >>> >>Hello, >>> >> >>> >>a VoIP application called Skype is gaining more and more popularity. I >>> >>did a basic capture using Ethereal. It seems that it continuously >>> >>sends data at a rate of 10 KB/sec. >>> >> >>> >>Obviously, it does not use a sliding window mechanism nor does it >>> >>consider the rate at which the receiver is able to receive data. >>> >>Furthermore, it does not attempt to detect periods of silence and >>> >>during those, it continues to send data at its 10KB/sec constant bit >>> >>rate. >>> >> >>> >>A colleague of mine is very enthousiastic about Skype as it saves him >>> >>a lot of money on his long distance bills. According to his vision of >>> >>Skype, one day, everybody is going to use Skype.... >>> >> >>> >>This scares me. Intuitively, this looks like the perfect recipe for a >>> >>congestion collapse. But, he argues that this could not be the case as >>> >>there are miles and miles of unused copper and fiber opticts out there >>> >>and that more bandwidth is widely available across the world... >>> >> >>> >>IMHO, I think that applications like Skype should be responsible for >>> >>managing the congestion they could potentially cause. This brings me >>> >>to my question. If more and more applications start to behave like >>> >>Skype and selfishly worry more about their business model than about >>> >>the health of the global Internet, is there still a possibility of a >>> >>congestion collapse today ? Or, are those worries well behind because >>> >>the problem can be compensated by introducing more bandwidth into the >>> >>network ? >>> >> >>> >>Thank you >>> >> >>> >>Emmanuel >>> >> >>> >>-- >>> >>UNIX IS very user friendly. It is just selective about its friends... >>> >>> cheers >>> >>> jon >>> >>> >> >> cheers jon From sudeepg at cse.iitb.ac.in Sat Mar 5 05:12:27 2005 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Sat, 5 Mar 2005 18:42:27 +0530 (IST) Subject: [e2e] Application Traffic Characteristics measurement. In-Reply-To: <9531abdc241f450e15fa92b84fe74310@extremenetworks.com> References: <11ad0fa8050304053342514f51@mail.gmail.com> <200503041318.37290.don@dhoffman.net> <4228E595.9030407@dirtcheapemail.com> <9531abdc241f450e15fa92b84fe74310@extremenetworks.com> Message-ID: Hi All, I have to measure traffic QoS characteristic of different applications like FTP, Video, VoIP. Can you please suggest me ways to do that? I have been looking into TGs and sniffers. But they donot help me know the traffic characteristcs. I understand that there are no straight ways to do it. But, any possible attempts around would help me a lot. I need this to create QoS traffic profiles which can be used by different applications for QoS specifications. Thanks and regards, Sudeep From Jon.Crowcroft at cl.cam.ac.uk Sat Mar 5 08:05:19 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 05 Mar 2005 16:05:19 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from Scott W Brim of "Fri, 04 Mar 2005 15:51:59 EST." <20050304205159.GF5440@sbrim-w2k02> Message-ID: one of the big differences between audio and video is that people can leave video running and often pointing out the window at "interesting" scenary (e.g. a road:) but with audio, you tend to want to engage in a conversation with someone at the other end, and if the quality aint good enough, you get voluntary congestion avoidance - users "hang up" (as "Alexandre L. Grojsgold" just pointed out) so the point is that with lots of voice calls, the aggregate set of flows will end up looking something like a big fat TCP, varying slowly a people join and leave (when they've said their piece) of course, one nice thing with the mbone/multicast was that if the _receivers_ all left, the traffic stopped flowing ,so if someone was just plain boring, then you could stop receiving their traffic and congestioning your inbound link - this is something that some of the anti-multicat lobby "failed to get" about the value of the multicast model....someone could send, but if there were no receivers, the traffic didnt go beyond the first router (at least once we got past the earlier multicast flood/prune) anyhow, the statistcs in countries with very cheap (or free local) phone calls are people spend around 300 minutes a month talking... so you can workout that thats some kind of social limit to the traffic naively if you spend more than 50% of your waking life asleep^H^H^H on the phone, then you start to have no life to speak of:) (mind you that doesnt stop some people spending more than 100% of their lives sending email...oh well, meaning is such a scarce commodity anyhow...unlike hydrogen or stupidity (one for lloyd wood to spot there)). cheers j. btw, last time this came up for me, I accused an ISP that blocked UDP of being _underprovisions_ and they set the lawyers on me -this would be back >10 years ago - nowadays we know what provisioning IP means, but back then I was right - provisioning was something phone companies did for voice, and saying someone was underprovisioned meand "underprovisioned for voice" - most phone companies are overprovisioned for voice, just like most ISPs now are overprovisioned for TCP/web (though perhaps not P2P) - for me, this means that they have enough that an average interactive web session does not exceed around 1 second per web page - thats a 1970s result on human interaction with form entry systems - a modest web page is somewhere around 12kbytes these days, so you are looking at 72kbps so if they can't hack 10kbps skype, they are pretty much out of order w.r.t just about any useful internet usage whether its "TCP friendly" or "selfish" or "inelastic" btw, TCP friendliness _is_ selfish - its in your own interest to do as you would be done by. and inelastic is not necessarily selfish - just constant sending even when the packets are not gettng through that is stupid... thought: one solution to DOS would be for us to get rid of unicast and only use multicast groups of 1, then a dos attack would be immediately removed by leaving the group:) (oh, i know, the attacks would just move onto the PIM RPs or onto the address allocation servers yeah...) In missive <20050304205159.GF5440 at sbrim-w2k02>, Scott W Brim typed: >>On Fri, Mar 04, 2005 04:22:36PM -0300, Alexandre L. Grojsgold allegedly wrote: >>> Well, one must have in mind that at the end of a skype voice connection >>> ther is as human being that, in case of congestion and excessive packet >>> loss will simply hang up the call - or even be so unhappy that he will >>> never try calling thru Skype again. >> >>When I was playing with low bandwidth video we backed off the transmit >>rate only so far -- below a certain point it wasn't worthwhile, so we >>stayed at our minimum and accepted whatever happened. cheers jon From rja at extremenetworks.com Sat Mar 5 08:16:03 2005 From: rja at extremenetworks.com (RJ Atkinson) Date: Sat, 5 Mar 2005 11:16:03 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: Message-ID: On Mar 5, 2005, at 05:32, Jon Crowcroft wrote: > if we all took 576kbps DSL lines and sent 24*7 MPEG2, we would (today) > cause trouble - but in a few years time, who's to say what the minimum > entry point is? Datum: With DOCSIS cable modems, which are pretty widely used today throughout Europe, North America, Australia, Japan, and other parts of Asia, a given cable modem subscriber has a single upstream frequency available. On that shared upstream frequency, the standard permits either QPSK or QAM modulation. In practice, European cable plant will permit QAM to work yielding rather more usable bandwidth. Outside Europe, cable plant rarely supports QAM (from an RF S/N perspective), so one is stuck with QPSK. This means that the shared upstream can typically get (outside Europe) about 1.5 Mbps. It is unlikely that the cable plant would be reworked to support QPSK, because that is relatively expensive. It is practical, however, to space (georgraphically) division multiplex upstreams so that fewer customers are sharing a given upstream. Even so, I would not be optimistic that a cable modem end user would ever really be able to use 512 Kbps (or more) of upstream capacity (except in the much smaller geographic area, nearly all fibre, cable plant in selected parts of Europe where QAM could be used upstream). [Typically, the DOCSIS upstream is operating in the lower "roll off" region of the RF spectrum (e.g. ~27 MHz), where the CATV RF transmission gear is becoming marginal. This is done because there is (today) more revenue from carrying an additional TV channel than from giving that same bandwidth to upstream cable modem use. The economics could change at some point, though right now that seems unlikely.] With DOCSIS, the shared downstream is significantly less of an issue, because RF S/N ratio is much better downstream and because the cable operator normally allocates one TV channel (not in the roll off region) for that purpose. > you know what: users do NOT like variable quality -if you aregoing to > support a given rate, dont go ABOVE it if you are later going to have > to go back down > to that rate 0 if you have a lower rate, only support that. this is > critical > for audio (but less so for video) - so all the work on fancy codecs > and user/channel/codec adaption we all did 2 decades back for 10 years > - you know, > was all misguided. Very interesting result, IMHO. Thanks for describing both test regime and results. Is there a suggested bibliographic citation or two to read ? > so if you look at the Book we wrote on all this stuff (Internetworking > Multimedia, Handley/Crowcroft/Wakeman - > morgan kauffman pubs), we were wrong (though all the stuff on rtp and > sip and realtime on IP and multicast there is > is still pretty up-to-date:) Sounds like time for a 2nd Edition. :-) Cheers, Ran rja at extremenetworks.com From dpreed at reed.com Sat Mar 5 08:33:51 2005 From: dpreed at reed.com (David P. Reed) Date: Sat, 05 Mar 2005 11:33:51 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: Message-ID: <4229DF6F.60205@reed.com> Michael Welzl wrote: > >You're doing the Real folks wrong: in our tests, RealVideo _DID_ react to >congestion. The way it did so was a little strange, but what the heck, >eventually it reduced its rate. Having tested a number of other >applications, I'd say that this is more than you could hope for :- > > And exactly what evidence are we considering that Skype, which uses the TCP stack in the OS, does not reduce its packet flow when congestion occurs? My mention of other streaming services was to point out that they present a heavy load, more than Skype does. So if the Skype load is going to cause "congestion collapse" (see below), we would already be there. There is a limit to Skype's load - each phone call requies two (2) humans at the endpoints, who probably are not doing other things (like making PSTN calls or watching streaming videos or listening to iTunes). Hardly a recipe for unbounded demand.... I wasn't actually referring to whether Skype responds to congestion. As a user I see no evidence that it tampers with TCP, but I plan to dig further. Actually, transmitting continuous 10KB/s is a nice, simple strategy for avoiding stupid interactions between "silence detection" and TCP's flow control algorithm, which is really only tested for bulk async delivery traffic (that's why I get red and angry every time the Internet Drag Racers focus on how fast their latest tweak on TCP runs over fiber - if even one graduate student were to look closely at the larger class of apps that run over TCP, such as HTTP 1.1, POP3, SMTP, ... they would stop focusing on how fast one can travel over a standing quarter mile flat track and figure out how to improve the performance of real cars in real cities. > > > >>Congestion collapse is a well-defined term. It's not the plural of >> >> > >I disagree: >ftp://ftp.rfc-editor.org/in-notes/rfc896.txt >versus >http://www.cse.ohio-state.edu/~jain/papers/cr1.htm >versus >http://www.icir.org/floyd/end2end-paper.html > > > I said the term *congestion collapse* as a resulting effect was defined - and it is - a sustained reduction of throughput that persists after a period of overload. If there is an alternate definition in paper 2 and 3, I certainly can't find it in the words there. Perhaps you missed the word "collapse" in my point, which matches with the word collapse in paper 1? The other papers refer to congestion - a much less precise term than "congestion collapse" I agree. I made no reference to the number of causes that might lead to "congestion collapse". I referred in an ironic way "c.c. is not the plural of heavy load" to refer to the fact that heavy loads on the Internet do not necessarily cause collapse. There are any number of reasons - one is that TCP backs off, one is that humans back off, etc. And of course the length of the control loop involved in the backoff is crucial - if the backoff happens early and persists long enough, sustained reduction in performance doesn't happen. In other words, the difference between congestion and congestion collapse does lie in the control loop. Unlike video or audio streaming, phone calls have, necessarily, a very tight feedback loop - users find zero value in throughput without tightly bounded latency in phone calls. They hang up if their calls get even the slightest bit unreliable, and they hang up if the end-to-end delay gets over about 100 msec. This does not happen in audio or video streaming. Those are therefore a much likelier contributor to "congestion collapse". Mere congestion is usually a spur to investment, by the way. Businesses whose parking lots are full attract investors to build parking lots, *even when there is no charge for parking*. Why? Because its clear that the businesses are popular. In the same way, if Skype actually caused congestion at a substantial level, I have no doubt that its users would find a way to pay to improve their highly desirable service. Funny thing - the Internet got built out because so many companies found that users really wanted to conduct business with them on websites. There is no denying that "congestion collapse" reflects a brittle response that is to be avoided, but preventing congestion may actually backfire, because it removes one of the economic signals that cause the investment that reduces the congestion. From Jon.Crowcroft at cl.cam.ac.uk Sat Mar 5 08:43:10 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 05 Mar 2005 16:43:10 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from RJ Atkinson of "Sat, 05 Mar 2005 11:16:03 EST." Message-ID: You're dead right about cable modem nets - i hadnt thought of them partly because i am a parochial brit and we haev a lot more dsl than cable...and tv has gone a different way for digital than i expected the project i was citing was called Higherview - funded by BT at UCL - http://www.cs.ucl.ac.uk/research/higherview/publications.htm anna watson's PhD was i think the key work...the link to that there seems to work...though some of the others havnt aged so well.. In missive , RJ Atkinson typed: >> >>On Mar 5, 2005, at 05:32, Jon Crowcroft wrote: >>> if we all took 576kbps DSL lines and sent 24*7 MPEG2, we would (today) >>> cause trouble - but in a few years time, who's to say what the minimum >>> entry point is? >> >>Datum: >> With DOCSIS cable modems, which are pretty widely used today throughout >>Europe, North America, Australia, Japan, and other parts of Asia, a >>given >>cable modem subscriber has a single upstream frequency available. On >>that >>shared upstream frequency, the standard permits either QPSK or QAM >>modulation. >>In practice, European cable plant will permit QAM to work yielding >>rather >>more usable bandwidth. Outside Europe, cable plant rarely supports QAM >>(from an RF S/N perspective), so one is stuck with QPSK. This means >>that >>the shared upstream can typically get (outside Europe) about 1.5 Mbps. >>It is unlikely that the cable plant would be reworked to support QPSK, >>because that is relatively expensive. It is practical, however, to >>space >>(georgraphically) division multiplex upstreams so that fewer customers >>are sharing a given upstream. >> >> Even so, I would not be optimistic that a cable modem end user would >>ever >>really be able to use 512 Kbps (or more) of upstream capacity (except in >>the much smaller geographic area, nearly all fibre, cable plant in >>selected >>parts of Europe where QAM could be used upstream). >> >>[Typically, the DOCSIS upstream is operating in the lower "roll off" >>region >>of the RF spectrum (e.g. ~27 MHz), where the CATV RF transmission gear >>is >>becoming marginal. This is done because there is (today) more revenue >>from >>carrying an additional TV channel than from giving that same bandwidth >>to >>upstream cable modem use. The economics could change at some point, >>though right now that seems unlikely.] >> >>With DOCSIS, the shared downstream is significantly less of an issue, >>because RF S/N ratio is much better downstream and because the cable >>operator normally allocates one TV channel (not in the roll off region) >>for that purpose. >> >> >>> you know what: users do NOT like variable quality -if you aregoing to >>> support a given rate, dont go ABOVE it if you are later going to have >>> to go back down >>> to that rate 0 if you have a lower rate, only support that. this is >>> critical >>> for audio (but less so for video) - so all the work on fancy codecs >>> and user/channel/codec adaption we all did 2 decades back for 10 years >>> - you know, >>> was all misguided. >> >>Very interesting result, IMHO. Thanks for describing both test regime >>and results. Is there a suggested bibliographic citation or two to >>read ? >> >>> so if you look at the Book we wrote on all this stuff (Internetworking >>> Multimedia, Handley/Crowcroft/Wakeman - >>> morgan kauffman pubs), we were wrong (though all the stuff on rtp and >>> sip and realtime on IP and multicast there is >>> is still pretty up-to-date:) >> >>Sounds like time for a 2nd Edition. :-) >> >>Cheers, >> >>Ran >>rja at extremenetworks.com >> cheers jon From michael.welzl at uibk.ac.at Sat Mar 5 10:01:02 2005 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Sat, 5 Mar 2005 19:01:02 +0100 Subject: [e2e] Skype and congestion collapse. References: <4229DF6F.60205@reed.com> Message-ID: <001f01c521ad$4ba8ce20$0200a8c0@fun> > >You're doing the Real folks wrong: in our tests, RealVideo _DID_ react to > >congestion. The way it did so was a little strange, but what the heck, > >eventually it reduced its rate. Having tested a number of other > >applications, I'd say that this is more than you could hope for :- > > > > > And exactly what evidence are we considering that Skype, which uses the > TCP stack in the OS, does not reduce its packet flow when congestion > occurs? My mention of other streaming services was to point out that This is not an in-depth study, but some of my students did simple measurements in a local testbed, and found that the payload was UDP and it did not react to congestion (strangely, though, it did make packets smaller plus increase the packet rate - thereby maintaining the same bitrate - during long speech pauses). This, of course, may depend on many things - the version, settings etc; the results are really preliminary. Still, they at least indicate that Skype doesn't react to congestion. > they present a heavy load, more than Skype does. So if the Skype load > is going to cause "congestion collapse" (see below), we would already be > there. There is a limit to Skype's load - each phone call requies two > (2) humans at the endpoints, who probably are not doing other things > (like making PSTN calls or watching streaming videos or listening to > iTunes). Hardly a recipe for unbounded demand.... I agree, and I also tend to agree with Jon that it's just "occupying a convenient niche". On the other Marc Herbert did also have a point when he explained his experiences with an access link yesterday, didn't he? I also don't believe in a global congestion collapse from Skype, but it's still an interesting application with interesting applications. For one, PSTN and the Internet are two different beasts. I have a dedicated cable going out of my house for each of the two, but the Internet cable is the one I'd like to use for several things at the same time. > I wasn't actually referring to whether Skype responds to congestion. As > a user I see no evidence that it tampers with TCP, but I plan to dig > further. Actually, transmitting continuous 10KB/s is a nice, simple Do you mean that it uses TCP? I never even personally used it, so perhaps I should just shut up here - who knows, maybe my students just set "PROTOCOL = UDP" somewhere in its options... > strategy for avoiding stupid interactions between "silence detection" > and TCP's flow control algorithm, which is really only tested for bulk > async delivery traffic (that's why I get red and angry every time the > Internet Drag Racers focus on how fast their latest tweak on TCP runs > over fiber - if even one graduate student were to look closely at the > larger class of apps that run over TCP, such as HTTP 1.1, POP3, SMTP, > ... they would stop focusing on how fast one can travel over a standing > quarter mile flat track and figure out how to improve the performance of > real cars in real cities. I agree that this is an interesting topic. > >>Congestion collapse is a well-defined term. It's not the plural of > >> > >> > > > >I disagree: > >ftp://ftp.rfc-editor.org/in-notes/rfc896.txt > >versus > >http://www.cse.ohio-state.edu/~jain/papers/cr1.htm > >versus > >http://www.icir.org/floyd/end2end-paper.html > > > > > > > I said the term *congestion collapse* as a resulting effect was defined > - and it is - a sustained reduction of throughput that persists after a > period of overload. If there is an alternate definition in paper 2 and > 3, I certainly can't find it in the words there. Perhaps you missed You didn't give that definition in your email, you just said that it's well defined. What you state above seems to me to be a reasonable definition, though; this definition may be in people's minds, but I don't know of a paper or RFC out there somewhere that is generally accepted as being the one which gives the definition. I'm not trying to be picky here - note that I myself said: > So how is it defined? I think we all share the general idea that the > "collapse" is when the network just becomes unusable, but I'm > not sure whether we have a really concise definition that is generally > agreed upon. I didn't like my own definition, couldn't think of a better one and wondered if we had one somewhere out there. > the word "collapse" in my point, which matches with the word collapse in > paper 1? The other papers refer to congestion - a much less precise > term than "congestion collapse" I agree. I made no reference to the all three of them really do use the term "congestion collapse", so I was confused about how it really is defined. Again, I like your definition above, but I never saw it before. > Unlike video or audio streaming, phone calls have, necessarily, a very > tight feedback loop - users find zero value in throughput without > tightly bounded latency in phone calls. They hang up if their calls > get even the slightest bit unreliable, and they hang up if the > end-to-end delay gets over about 100 msec. > > This does not happen in audio or video streaming. Those are therefore > a much likelier contributor to "congestion collapse". Ah, I see your point; interesting. On the other hand, VoIP is peer-to-peer whereas streaming video is often client-server. In the latter case, the applications should (and indeed appear to) react for their own sake because not responding to congestion limits the number of clients that can be served at the same time. It's a matter of incentives - in a VoIP scenario, nobody has an incentive to react to congestion - I could only hurt other flows, not my own. But VoIP may be a bad example because of the little traffic that it generates. I believe that a similar application that causes more traffic could be more harmful than such client-server applications; perhaps a video telephone, but nobody ever wanted them, and nobody ever will IMO :-) > Because its clear that the businesses are popular. In the same way, if > Skype actually caused congestion at a substantial level, I have no doubt > that its users would find a way to pay to improve their highly desirable > service. Funny thing - the Internet got built out because so many > companies found that users really wanted to conduct business with them > on websites. > > There is no denying that "congestion collapse" reflects a brittle > response that is to be avoided, but preventing congestion may actually > backfire, because it removes one of the economic signals that cause the > investment that reduces the congestion. Hm ... in any case, these are interesting thoughts! Cheers, Michael From michael.welzl at uibk.ac.at Sat Mar 5 10:17:05 2005 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Sat, 5 Mar 2005 19:17:05 +0100 Subject: [e2e] Skype and congestion collapse. References: Message-ID: <003701c521af$89a6f1a0$0200a8c0@fun> > one of the big differences between audio and video > is that people can leave video running and often pointing out the window at > "interesting" scenary (e.g. a road:) > but with audio, you tend to want to engage in a conversation with someone at the other end, and if the quality aint > good enough, you get voluntary congestion avoidance - users "hang up" I have a problem with that point of view. Let's ignore the other reasons why Skype will not cause congestion collapse for a second: * just not enough traffic * if congested, users will pay, revenue will in turn increase capacities (if i got david right) So we have the only reason above: users tend to hang up. Let's say we have an application (SoIP, where S = "singing") that requires quite a bit of bandwidth. What would stop users from filling all the capacity? Okay, the ones who can't get in simply hang up - and you could come up with an interesting pricing strategy etc etc But: what about my ftp download? It's supposed to be a multi service network, after all... > btw, TCP friendliness _is_ selfish - its in your own interest to do as you would be done by. that seems strange to me. can you elaborate? cheers, Michael From hgs at cs.columbia.edu Sat Mar 5 10:46:58 2005 From: hgs at cs.columbia.edu (Henning Schulzrinne) Date: Sat, 05 Mar 2005 13:46:58 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <4229F948.1090802@cs.columbia.edu> References: <4229DF6F.60205@reed.com> <001f01c521ad$4ba8ce20$0200a8c0@fun> <4229F948.1090802@cs.columbia.edu> Message-ID: <4229FEA2.10602@cs.columbia.edu> See http://www1.cs.columbia.edu/~library/2004.html for a preliminary protocol analysis. Skype generally only uses TCP if NATs or firewalls prevent the use of UDP, as far as we were able to discern. From dpreed at reed.com Sat Mar 5 13:30:59 2005 From: dpreed at reed.com (David P. Reed) Date: Sat, 05 Mar 2005 16:30:59 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: Message-ID: <422A2513.1040807@reed.com> The "512 kb limit" upstream on cable plants seems a bit bogus to me, as I just ran a test and got sustained 741 kb/s upstream to Los Angeles. A small correction about cable modem nets (Ran knows a fair bit so he may correct me). Cable modems sit on networks with an architecture called HFC, Hybrid Fiber Coax, which is designed so the number of homes passed is dependent on where in the cable distribution tree the plant turns from fiber to coax. In advanced operators (Comcast and RCN out here) the fiber goes out very close to the users, and has moved closer as the upstream demand has increased. I happen to have a fair amount of contact with Comcast execs, and their plan is to move fiber even closer to the users, reducing the number of homes per coax segment. In recent conversations with CableLabs execs (my namesake, David P. Reed, and Richard Green) regarding the DOCSIS capabilities indicate that they are quite aware of the need for more upstream bandwidth, because they see the asymmetry going down as more and more bittorrent, etc. is deployed. So while YMMV depending on how sluggish your operator is, HFC is generally pursuing a strategic direction to go well beyond the current upstream limits. Thus, the upstream link share level seems likely to go down. Ran may have other data that contradicts this, and I have to admit today I've *only* got 784 Kb/s upstream and 7 Mb/s downstream on RCN, so it might be a year or so before I get past a megabit upstream for my $50 per month. [happening to live in a place where RCN and Comcast compete head-to-head has strong benefits... especially since Verizon DSL has so far refused to be competitive anywhere in Massachusetts]. From rja at extremenetworks.com Sat Mar 5 13:53:16 2005 From: rja at extremenetworks.com (RJ Atkinson) Date: Sat, 5 Mar 2005 16:53:16 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <422A2513.1040807@reed.com> References: <422A2513.1040807@reed.com> Message-ID: On Mar 5, 2005, at 16:30, David P. Reed wrote: > The "512 kb limit" upstream on cable plants seems a bit bogus to me, > as I just ran a test and got sustained 741 kb/s upstream to Los > Angeles. It does not seem bogus to me, since often more than 100 active users are sharing a 1.5 Mbps upstream channel; reasonable people might have a range of differing views on this topic. > A small correction about cable modem nets (Ran knows a fair bit so he > may correct me). Cable modems sit on networks with an architecture > called HFC, Hybrid Fiber Coax, which is designed so the number of > homes passed is dependent on where in the cable distribution tree the > plant turns from fiber to coax. In advanced operators (Comcast and > RCN out here) the fiber goes > out very close to the users, and has moved closer as the upstream > demand > has increased. This varies widely market-by-market. The Boston area is very unusual because RCN "over-built" Comcast. Many households in the Boston area can choose from either RCN or Comcast for wired cable-TV. Boston has more fibre and fibre much closer to the house than is typical for most markets in North America because of the competition -- so it is more like Europe in that respect. A "good" fibre node might encompass 500 homes/addresses. Typical fibre nodes might run to 1500 homes/addresses. Fibre nodes with up to 3000 homes/addresses are not yet unusual. Some markets are still all copper or worse. > I happen to have a fair amount of contact with Comcast execs, and their > plan is to move fiber even closer to the users, reducing the number of > homes per coax segment. This is true of most cable operators that I'm familiar with, but the rate of increased fibre deployment varies widely with the economics of the particular market. > In recent conversations with CableLabs execs (my namesake, David P. > Reed, > and Richard Green) regarding the DOCSIS capabilities indicate that > they are > quite aware of the need for more upstream bandwidth, because they see > the > asymmetry going down as more and more bittorrent, etc. is deployed. > So > while YMMV depending on how sluggish your operator is, HFC is generally > pursuing a strategic direction to go well beyond the current upstream > limits. > Thus, the upstream link share level seems likely to go down. All that is true, but the situation varies widely from one market to another. In a previous life we tried to get QAM to work upstream on several different HFC deployments, but QAM really didn't work anyplace other than Europe because of upstream noise implosion (at that time). > Ran may have other data that contradicts this, and I have to admit > today I've *only* got 784 Kb/s upstream and 7 Mb/s downstream on RCN, > so it might be a year or so before I get past a megabit upstream for > my $50 per month. [happening to live in a place where RCN and Comcast > compete head-to-head has strong benefits... especially since Verizon > DSL has so far refused to be competitive anywhere in Massachusetts]. I don't think anything I have contradicts your data, but maybe it suggests that your market is not typical of most markets around the globe. Cheers, Ran From randy at psg.com Sat Mar 5 14:47:38 2005 From: randy at psg.com (Randy Bush) Date: Sat, 5 Mar 2005 12:47:38 -1000 Subject: [e2e] Skype and congestion collapse. References: <422A2513.1040807@reed.com> Message-ID: <16938.14090.197120.733118@roam.psg.com> > It does not seem bogus to me, since often more than 100 active > users are sharing a 1.5 Mbps upstream channel; reasonable people > might have a range of differing views on this topic. indeed. from japan, where unrestricted 100mb to the home or office is U$D20-40 per month, things look a bit differently. though end-users are still inbound biased, there is a variety of services being offered from the edge, and the domestic distribution is geographically wide. cho et alia have a good measurement paper in press which offers a serious look at the results from the view of the networks of the significant isps. randy From sommerfeld at sun.com Sat Mar 5 14:49:25 2005 From: sommerfeld at sun.com (Bill Sommerfeld) Date: Sat, 05 Mar 2005 16:49:25 -0600 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: <422A2513.1040807@reed.com> Message-ID: <1110062964.77748.5.camel@unknown.hamachi.org> On Sat, 2005-03-05 at 15:53, RJ Atkinson wrote: > This varies widely market-by-market. The Boston area is very unusual > because RCN "over-built" Comcast. Many households in the Boston area > can choose from either RCN or Comcast for wired cable-TV. Not only that, but, perhaps pressed by the appearance of RCN, in my town, mediaone/AT&T broadband/comcast/... (too many name changes!) built a new cable plant and moved subscribers one by one to the new backbone (complete with new cable box, channel lineup, etc.,) - Bill From salman at cs.columbia.edu Sat Mar 5 15:25:45 2005 From: salman at cs.columbia.edu (Salman Abdul Baset) Date: Sat, 5 Mar 2005 18:25:45 -0500 (EST) Subject: [e2e] end2end-interest Digest, Vol 13, Issue 10 In-Reply-To: Message-ID: I have collected different Skype papers/reports. They cover various aspects of Skype operations. http://www1.cs.columbia.edu/~salman/skype/index.html -salman From cannara at attglobal.net Sat Mar 5 21:31:01 2005 From: cannara at attglobal.net (Cannara) Date: Sat, 05 Mar 2005 21:31:01 -0800 Subject: [e2e] 10% packet loss stops TCP flow References: <6.1.1.1.1.20050303122934.02a79c08@imap.eed.ericsson.se> <6.1.1.1.1.20050304041307.02a0a090@imap.eed.ericsson.se> <4228C402.5CCA9E0@attglobal.net> <4228E71E.2060900@dirtcheapemail.com> Message-ID: <422A9595.4A7C4DD7@attglobal.net> Now, now Clark, your traffic undoubtedly crossed a metro link or two, with ADMs and other Sonet gear doing a fine job of link & path management. If you're thinking x.25 = PSTNs, then get up to date man. :] -- Alex From cannara at attglobal.net Sat Mar 5 21:43:00 2005 From: cannara at attglobal.net (Cannara) Date: Sat, 05 Mar 2005 21:43:00 -0800 Subject: [e2e] Skype and congestion collapse. References: <11ad0fa8050304053342514f51@mail.gmail.com> <200503041318.37290.don@dhoffman.net> <4228E595.9030407@dirtcheapemail.com> <9531abdc241f450e15fa92b84fe74310@extremenetworks.com> Message-ID: <422A9864.E4D68063@attglobal.net> On where congestion is occurring today in the Inet, it would be useful to ask Les Cottrell at SLAC how things have been going with their continued "ping-around-the-world" testing. It had been true that busy peering points in the East & West of the US commonly lost 30%. Alex RJ Atkinson wrote: > > On Mar 4, 2005, at 17:47, Clark Gaylord wrote: > > This is why we really do need some notion of QoS other than The Fat > > Pipe. It doesn't have to be as elaborate as RSVP-disciplined CAC, but > > you need to be able to prioritize traffic that matters and limit the > > amount of traffic that gets prioritized. It doesn't have to be more > > complex than that, but it has to do at least that. [Ergo ... left as > > an exercise to the reader.] > > I don't know that the "network" needs to have a more sophisticated > notion > of QoS than best effort. It can sometimes be useful for the network > device > connected directly to a congested link (e.g. access link between a site > and > its upstream provider) to have some internal-to-the-box QoS > configuration. > > It is not uncommon these days for the access router at the customer > premise > to have some ACL ruleset that prefers some traffic over other traffic or > rate-limits certain kinds of traffic -- and equivalent configuration of > the aggregation router on the ISP side of the same link is also not > uncommon these days. > > That said, most congestion today occurs either on an access link such as > that or on some sort of wireless link (e.g. SATCOM to SW Asia). ISP > core > backbones tend to be over-provisioned. Most campus (wired/fibred) > networks > are similarly over-provisioned. > > Ran From xie at ict.ac.cn Sun Mar 6 00:14:41 2005 From: xie at ict.ac.cn (Xie) Date: Sun, 6 Mar 2005 16:14:41 +0800 Subject: [e2e] Application Traffic Characteristics measurement. References: <11ad0fa8050304053342514f51@mail.gmail.com><200503041318.37290.don@dhoffman.net><4228E595.9030407@dirtcheapemail.com><9531abdc241f450e15fa92b84fe74310@extremenetworks.com> Message-ID: <005501c52224$8c481b30$4d27e29f@ictxie> Hi Dear Sudeep, Which metrics will be included in your "traffic QoS characteristic"? Some end to end performance metrics at application level or traffic ratio for every application or other metrics else? We have developed a network measurement system named NetTurbo which can provide the first two kinds metrics. Cheers, Xie ----- Original Message ----- From: "Sudeep Goyal" To: "End-2-End list" Sent: Saturday, March 05, 2005 9:12 PM Subject: [e2e] Application Traffic Characteristics measurement. > Hi All, > > I have to measure traffic QoS characteristic of different applications > like FTP, Video, VoIP. > > Can you please suggest me ways to do that? I have been looking into TGs > and sniffers. But they donot help me know the traffic characteristcs. I > understand that there are no straight ways to do it. But, any > possible attempts around would help me a lot. > > I need this to create QoS traffic profiles which can be used by > different applications for QoS specifications. > > Thanks and regards, > Sudeep > > > From Jon.Crowcroft at cl.cam.ac.uk Sun Mar 6 02:01:05 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 06 Mar 2005 10:01:05 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from "Michael Welzl" of "Sat, 05 Mar 2005 19:17:05 +0100." <003701c521af$89a6f1a0$0200a8c0@fun> Message-ID: In missive <003701c521af$89a6f1a0$0200a8c0 at fun>, "Michael Welzl" typed: >>But: what about my ftp download? >>It's supposed to be a multi service network, after all... not yet it isnt:) - its a best effort service network (read the fine print in your ISP contract:) >>> btw, TCP friendliness _is_ selfish - its in your own interest to do as you >>would be done by. >>that seems strange to me. can you elaborate? read the selfish gene (latest edition) for example, or the hostdter work on the iterated prisoners dilemma - cooperative behaviour can (and does) evolve _out of_ purely selfish strategies - its basd on the notion investigated in social situations by axelrod where you _evolve_ your strategies over a number of encounters - this gets over any explicit cooperation, but allows the system of individuals to exchange experience effectively but implicitly so think of it like this: Anyone can think of "cheating on" tcp friendliness. The fact that _anyone_ can think this, means that more than 1 person will. If they stop for more than a moment, they'll realiase that a TCP unfriendly "meme" will propagate very rapidly. It only takes a small percentage of cheaters to cause the Internet to revert to the congestion collapse pre 1988. Then all that so called selfish advantage in fact turns quite explicitly to disadvantage (as with the oft over-cited commons tragedy). i.e. 1 cheater leads many to cheat which means no-one whether good or bad gets even a fair share, let alone more than a fair share. So the vast majority of people selfishly, ironically, paradoxically, cooperate. Of course, there are always a very few stealthy cheaters. The system can tolerate those. There's some nice simulations of this in several other areas where the idea has become important, such as peer-to-peer systems, and ad hoc mobile nets and mesh wireless nets, where we depend on other nodes - (hm, one for lloyd wood here: I have always depended on the kindness of strangers:) (in manet, this is battery as well as radio capacity, and in p2p its cache storage as well as uplink v. downlink capacity). In MANETs and P2P, the "presence" or lifetime of a node, coupled with a lot of mechanism for anonimty has led to the possibility that stealthy cheating pays off because the cheater leaves the system before the system acquires to many bad behaving users or detects them - As a result of this, researchers have devised lots of schemes to enforce cooperation (at least statistically) - viz bittorrent has tokens you need to download, which you acquire for upload, and systems like CORE and CONFIDANT (from eurecom and epfl) for MANET... but in the internet, while noone knows if you are a dog, they do know where you live and what you did last summer:) cheers jon From rmg at it.uu.se Sun Mar 6 03:33:03 2005 From: rmg at it.uu.se (Richard Gold) Date: Sun, 06 Mar 2005 12:33:03 +0100 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: Message-ID: <422AEA6F.2030208@it.uu.se> > >>> btw, TCP friendliness _is_ selfish - its in your own interest to do as you > >>would be done by. > >>that seems strange to me. can you elaborate? > > read the selfish gene (latest edition) for example, or the > hostdter work on the iterated prisoners dilemma - cooperative behaviour > can (and does) evolve _out of_ purely selfish strategies - its basd on the > notion investigated in social situations by axelrod where you _evolve_ your > strategies over a number of encounters - this gets over any explicit cooperation, but > allows the system of individuals to exchange experience effectively but implicitly I think Jon is referring to Douglas Hofstadter (who wrote G?del, Escher, Bach among other things), Prisoner's Dilemma stuff can be found here: http://www.magnolia.net/~leonf/sd/pd-brf.html An example closer to home might be Bit Torrent's Tit-for-Tat algorithm. This algo encourages co-operation by making it in your best interests to co-operate. Altruism is present, however, in the start up phase when a client connects to a seed. The seeds are clients with full copies of the file that behave altruistically. When clients are downloading from other clients (also called leechers) the TfT algo kicks in and you need to upload to clients you are downloading from in order to maximize your own downloading speed (otherwise you become "choked"). Et voil?, 35% of Internet traffic is Bit Torrent! > (as with the oft over-cited commons tragedy). ...and oft over-cited end-to-end principle etc. ;-) Cheers, Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3196 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050306/d7b48f6d/smime-0001.bin From sudeepg at cse.iitb.ac.in Sun Mar 6 06:57:09 2005 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Sun, 6 Mar 2005 20:27:09 +0530 (IST) Subject: [e2e] Application Traffic Characteristics measurement. In-Reply-To: <005501c52224$8c481b30$4d27e29f@ictxie> References: <11ad0fa8050304053342514f51@mail.gmail.com><200503041318.37290.don@dhoffman.net><4228E595.9030407@dirtcheapemail.com><9531abdc241f450e15fa92b84fe74310@extremenetworks.com> <005501c52224$8c481b30$4d27e29f@ictxie> Message-ID: Thanks Xie, I am looking for QoS parameters like delay, jitter, throughput at the application level and traffic/packet level both. I am using tcpdump, tcptrace (and latelty tstat) for passive measurements and Iperf, D-ITG for active measurements. If you can suggest me some link to some synthetic traffic generator (that generates application traffic like VoIP, Video, FTP) which I couldn't find yet, it would be of great help to me and then measures the perforamnce like delay, jitter experienced by the application. D-ITG does this, but only for VoIP and DNS. I tried looking for Netturbo on Google. Could get hands only on few papers. I would be interested in looking at the tool. Can you plz suggest me the link to the same? Thanks for all the help, Regards, Sudeep On Sun, 6 Mar 2005, Xie wrote: > Hi Dear Sudeep, > > Which metrics will be included in your "traffic QoS characteristic"? Some end to end performance metrics at application level or traffic ratio for every application or other metrics else? We have developed a network measurement system named NetTurbo which can provide the first two kinds metrics. > > Cheers, > Xie > ----- Original Message ----- > From: "Sudeep Goyal" > To: "End-2-End list" > Sent: Saturday, March 05, 2005 9:12 PM > Subject: [e2e] Application Traffic Characteristics measurement. >end2end-interest at postel.org > >> Hi All, >> >> I have to measure traffic QoS characteristic of different applications >> like FTP, Video, VoIP. >> >> Can you please suggest me ways to do that? I have been looking into TGs >> and sniffers. But they donot help me know the traffic characteristcs. I >> understand that there are no straight ways to do it. But, any >> possible attempts around would help me a lot. >> >> I need this to create QoS traffic profiles which can be used by >> different applications for QoS specifications. >> >> Thanks and regards, >> Sudeep >> >> >> -- From cottrell at slac.stanford.edu Sun Mar 6 07:20:43 2005 From: cottrell at slac.stanford.edu (Cottrell, Les) Date: Sun, 6 Mar 2005 07:20:43 -0800 Subject: [e2e] Skype and congestion collapse. Message-ID: <35C208A168A04B4EB99D1E13F2A4DB01A0D71B@exch-mail1.win.slac.stanford.edu> Our measurements are using ping mainly between academic and research sites worldwide. The high losses in the US was several years ago. Typical losses between developed regions of the world (Canada, US, Europe, Japan, Korea, Singapore, Australia/NZ) are << 1%. Things have improved a lot. See for example Figs 3 and 4 of http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan05/. There are high losses still in parts of the Internet but they are mainly to developing countries (see for example Figs 9 and 10 of the above report). -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Cannara Sent: Saturday, March 05, 2005 9:43 PM Cc: End-2-End list Subject: Re: [e2e] Skype and congestion collapse. On where congestion is occurring today in the Inet, it would be useful to ask Les Cottrell at SLAC how things have been going with their continued "ping-around-the-world" testing. It had been true that busy peering points in the East & West of the US commonly lost 30%. Alex RJ Atkinson wrote: > > On Mar 4, 2005, at 17:47, Clark Gaylord wrote: > > This is why we really do need some notion of QoS other than The Fat > > Pipe. It doesn't have to be as elaborate as RSVP-disciplined CAC, > > but you need to be able to prioritize traffic that matters and limit > > the amount of traffic that gets prioritized. It doesn't have to be > > more complex than that, but it has to do at least that. [Ergo ... > > left as an exercise to the reader.] > > I don't know that the "network" needs to have a more sophisticated > notion of QoS than best effort. It can sometimes be useful for the > network device connected directly to a congested link (e.g. access > link between a site and its upstream provider) to have some > internal-to-the-box QoS configuration. > > It is not uncommon these days for the access router at the customer > premise to have some ACL ruleset that prefers some traffic over other > traffic or rate-limits certain kinds of traffic -- and equivalent > configuration of the aggregation router on the ISP side of the same > link is also not uncommon these days. > > That said, most congestion today occurs either on an access link such > as that or on some sort of wireless link (e.g. SATCOM to SW Asia). > ISP core backbones tend to be over-provisioned. Most campus > (wired/fibred) networks are similarly over-provisioned. > > Ran From rja at extremenetworks.com Sun Mar 6 08:03:14 2005 From: rja at extremenetworks.com (RJ Atkinson) Date: Sun, 6 Mar 2005 11:03:14 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <16938.14090.197120.733118@roam.psg.com> References: <422A2513.1040807@reed.com> <16938.14090.197120.733118@roam.psg.com> Message-ID: <68523d3870c00defb930a1c82a4d7668@extremenetworks.com> Earlier, Ran said, during a note about cable modem deployments: >> It does not seem bogus to me, since often more than 100 active >> users are sharing a 1.5 Mbps upstream channel; reasonable people >> might have a range of differing views on this topic. On Mar 5, 2005, at 17:47, Randy Bush wrote: > indeed. from japan, where unrestricted 100mb to the home or > office is U$D20-40 per month, things look a bit differently. > though end-users are still inbound biased, there is a variety > of services being offered from the edge, and the domestic > distribution is geographically wide. cho et alia have a good > measurement paper in press which offers a serious look at the > results from the view of the networks of the significant isps. A key difference is that the majority of metro network deployments in Japan (and also Korea or Sweden, for that matter) are built out of Ethernet, which offers symmetric bandwidth and does not have physics problems with the upstream. As near as I can tell, the metro networks in Japan generally are over-provisioned in the core and fully provisioned with capacity to the edge. My comment which Randy quotes above was intended to be narrowly focused on *cable modems*, where there is a physics problem with the shared upstream bandwidth. Even @Home Japan (which still exists) has an upstream rate-limit on their cable-modem offering for this reason. Apologies for being unclear. Ran From Jon.Crowcroft at cl.cam.ac.uk Sun Mar 6 08:12:32 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 06 Mar 2005 16:12:32 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from "Cottrell, Les" of "Sun, 06 Mar 2005 07:20:43 PST." <35C208A168A04B4EB99D1E13F2A4DB01A0D71B@exch-mail1.win.slac.stanford.edu> Message-ID: it would be interesting to compare figures for commercial dialup and broadband ISPs wit hacademic - certainly when planetlab is used to study the net in terms of loss/throughput and connectivity, you can see how unrepresentative it is from The Interdoman Connectivity of PlanetLab Nodes. Suman Banerjee, Timothy G. Griffin, Marcelo Pias. Passive and Active Measurement Workshop (PAM) 2004. (papers accesible via http://www.pam2004.org/ for interest) In missive <35C208A168A04B4EB99D1E13F2A4DB01A0D71B at exch-mail1.win.slac.stanford.edu>, "Cottrell, Les" typed: >>Our measurements are using ping mainly between academic and research sites worldwide. The high losses in the US was several years ago. Typical losses between developed regions of the world (Canada, US, Europe, Japan, Korea, Singapore, Australia/NZ) are << 1%. Things have improved a lot. See for example Figs 3 and 4 of http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan05/. There are high losses still in parts of the Internet but they are mainly to developing countries (see for example Figs 9 and 10 of the above report). >> >>-----Original Message----- >>From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Cannara >>Sent: Saturday, March 05, 2005 9:43 PM >>Cc: End-2-End list >>Subject: Re: [e2e] Skype and congestion collapse. >> >>On where congestion is occurring today in the Inet, it would be useful to ask Les Cottrell at SLAC how things have been going with their continued "ping-around-the-world" testing. It had been true that busy peering points in the East & West of the US commonly lost 30%. >> >>Alex >> >>RJ Atkinson wrote: >>> >>> On Mar 4, 2005, at 17:47, Clark Gaylord wrote: >>> > This is why we really do need some notion of QoS other than The Fat >>> > Pipe. It doesn't have to be as elaborate as RSVP-disciplined CAC, >>> > but you need to be able to prioritize traffic that matters and limit >>> > the amount of traffic that gets prioritized. It doesn't have to be >>> > more complex than that, but it has to do at least that. [Ergo ... >>> > left as an exercise to the reader.] >>> >>> I don't know that the "network" needs to have a more sophisticated >>> notion of QoS than best effort. It can sometimes be useful for the >>> network device connected directly to a congested link (e.g. access >>> link between a site and its upstream provider) to have some >>> internal-to-the-box QoS configuration. >>> >>> It is not uncommon these days for the access router at the customer >>> premise to have some ACL ruleset that prefers some traffic over other >>> traffic or rate-limits certain kinds of traffic -- and equivalent >>> configuration of the aggregation router on the ISP side of the same >>> link is also not uncommon these days. >>> >>> That said, most congestion today occurs either on an access link such >>> as that or on some sort of wireless link (e.g. SATCOM to SW Asia). >>> ISP core backbones tend to be over-provisioned. Most campus >>> (wired/fibred) networks are similarly over-provisioned. >>> >>> Ran cheers jon From cottrell at slac.stanford.edu Sun Mar 6 09:02:47 2005 From: cottrell at slac.stanford.edu (Cottrell, Les) Date: Sun, 6 Mar 2005 09:02:47 -0800 Subject: [e2e] Skype and congestion collapse. Message-ID: <35C208A168A04B4EB99D1E13F2A4DB01A0D71F@exch-mail1.win.slac.stanford.edu> Great question. Though only a small sample, we also have made measurements to about DSL/ISDN/Cable 10 routers (5 ISPs) in homes in the SF Bay Area for several years now. We have data going back to Jan 1988. The median losses have dropped from about 3% to about 0.02%, see http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan05/broadband.jpg -----Original Message----- From: Jon Crowcroft [mailto:Jon.Crowcroft at cl.cam.ac.uk] Sent: Sunday, March 06, 2005 8:13 AM To: Cottrell, Les Cc: cannara at attglobal.net; End-2-End list; Jon.Crowcroft at cl.cam.ac.uk Subject: Re: [e2e] Skype and congestion collapse. it would be interesting to compare figures for commercial dialup and broadband ISPs wit hacademic - certainly when planetlab is used to study the net in terms of loss/throughput and connectivity, you can see how unrepresentative it is from The Interdoman Connectivity of PlanetLab Nodes. Suman Banerjee, Timothy G. Griffin, Marcelo Pias. Passive and Active Measurement Workshop (PAM) 2004. (papers accesible via http://www.pam2004.org/ for interest) In missive <35C208A168A04B4EB99D1E13F2A4DB01A0D71B at exch-mail1.win.slac.stanford.edu>, "Cottrell, Les" typed: >>Our measurements are using ping mainly between academic and research sites worldwide. The high losses in the US was several years ago. Typical losses between developed regions of the world (Canada, US, Europe, Japan, Korea, Singapore, Australia/NZ) are << 1%. Things have improved a lot. See for example Figs 3 and 4 of http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan05/. There are high losses still in parts of the Internet but they are mainly to developing countries (see for example Figs 9 and 10 of the above report). >> >>-----Original Message----- >>From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Cannara >>Sent: Saturday, March 05, 2005 9:43 PM >>Cc: End-2-End list >>Subject: Re: [e2e] Skype and congestion collapse. >> >>On where congestion is occurring today in the Inet, it would be useful to ask Les Cottrell at SLAC how things have been going with their continued "ping-around-the-world" testing. It had been true that busy peering points in the East & West of the US commonly lost 30%. >> >>Alex >> >>RJ Atkinson wrote: >>> >>> On Mar 4, 2005, at 17:47, Clark Gaylord wrote: >>> > This is why we really do need some notion of QoS other than The Fat >>> > Pipe. It doesn't have to be as elaborate as RSVP-disciplined CAC, >>> > but you need to be able to prioritize traffic that matters and limit >>> > the amount of traffic that gets prioritized. It doesn't have to be >>> > more complex than that, but it has to do at least that. [Ergo ... >>> > left as an exercise to the reader.] >>> >>> I don't know that the "network" needs to have a more sophisticated >>> notion of QoS than best effort. It can sometimes be useful for the >>> network device connected directly to a congested link (e.g. access >>> link between a site and its upstream provider) to have some >>> internal-to-the-box QoS configuration. >>> >>> It is not uncommon these days for the access router at the customer >>> premise to have some ACL ruleset that prefers some traffic over other >>> traffic or rate-limits certain kinds of traffic -- and equivalent >>> configuration of the aggregation router on the ISP side of the same >>> link is also not uncommon these days. >>> >>> That said, most congestion today occurs either on an access link such >>> as that or on some sort of wireless link (e.g. SATCOM to SW Asia). >>> ISP core backbones tend to be over-provisioned. Most campus >>> (wired/fibred) networks are similarly over-provisioned. >>> >>> Ran cheers jon From dga+ at cs.cmu.edu Sun Mar 6 12:04:09 2005 From: dga+ at cs.cmu.edu (David Andersen) Date: Sun, 6 Mar 2005 15:04:09 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <35C208A168A04B4EB99D1E13F2A4DB01A0D71F@exch-mail1.win.slac.stanford.edu> References: <35C208A168A04B4EB99D1E13F2A4DB01A0D71F@exch-mail1.win.slac.stanford.edu> Message-ID: On Mar 6, 2005, at 12:02 PM, Cottrell, Les wrote: > Great question. Though only a small sample, we also have made > measurements to about DSL/ISDN/Cable 10 routers (5 ISPs) in homes in > the SF Bay Area for several years now. We have data going back to Jan > 1988. The median losses have dropped from about 3% to about 0.02%, > see > http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan05/ > broadband.jpg We've also seen this kind of reduction on the RON testbed (1/3 academic, with a few cable modems and DSL lines). I haven't peeked at the latest numbers, but we saw the average packet loss rate drop from 0.74% in 2001 to 0.42% in 2003, and my recollection of the more recent numbers is that things had improved a bit more. Our numbers are fairly consistent with what Les's broadband graph shows, though there's noise in all of the measurements. (stats taken from an IMC 2003 paper, "Best-Path vs. Multi-Path Overlay Routing," by Andersen, Snoeren, and Balakrishnan. http://nms.lcs.mit.edu/papers/index.php?detail=126 ) Oh - and in. re: the later note about fairness and games, it strikes me that these days, home users mostly have themselves to hurt by being "unfair," since in the majority of situations, their own link is the bottleneck. That's obviously not always true (overloaded servers, cable plants that depend on TCP fairness, if they do, or just overloaded ISPs), but for the most part, if you hack your TCP, you're just changing the ways your own bandwidth is allocated between your flows. _for home users._ -Dave > -----Original Message----- > From: Jon Crowcroft [mailto:Jon.Crowcroft at cl.cam.ac.uk] > Sent: Sunday, March 06, 2005 8:13 AM > To: Cottrell, Les > Cc: cannara at attglobal.net; End-2-End list; Jon.Crowcroft at cl.cam.ac.uk > Subject: Re: [e2e] Skype and congestion collapse. > > it would be interesting to compare figures for commercial dialup and > broadband ISPs wit hacademic - certainly when planetlab is used to > study the net in terms of loss/throughput and connectivity, you can > see how unrepresentative it is from The Interdoman Connectivity of > PlanetLab Nodes. Suman Banerjee, Timothy G. Griffin, Marcelo Pias. > Passive and Active Measurement Workshop (PAM) 2004. > (papers accesible via > http://www.pam2004.org/ > for interest) > > > > > In missive > <35C208A168A04B4EB99D1E13F2A4DB01A0D71B at exch- > mail1.win.slac.stanford.edu>, "Cottrell, Les" typed: > >>> Our measurements are using ping mainly between academic and research >>> sites worldwide. The high losses in the US was several years ago. >>> Typical losses between developed regions of the world (Canada, US, >>> Europe, Japan, Korea, Singapore, Australia/NZ) are << 1%. Things >>> have improved a lot. See for example Figs 3 and 4 of >>> http://www.slac.stanford.edu/xorg/icfa/icfa-net-paper-jan05/. There >>> are high losses still in parts of the Internet but they are mainly >>> to developing countries (see for example Figs 9 and 10 of the above >>> report). >>> >>> -----Original Message----- >>> From: end2end-interest-bounces at postel.org >>> [mailto:end2end-interest-bounces at postel.org] On Behalf Of Cannara >>> Sent: Saturday, March 05, 2005 9:43 PM >>> Cc: End-2-End list >>> Subject: Re: [e2e] Skype and congestion collapse. >>> >>> On where congestion is occurring today in the Inet, it would be >>> useful to ask Les Cottrell at SLAC how things have been going with >>> their continued "ping-around-the-world" testing. It had been true >>> that busy peering points in the East & West of the US commonly lost >>> 30%. >>> >>> Alex >>> >>> RJ Atkinson wrote: >>>> >>>> On Mar 4, 2005, at 17:47, Clark Gaylord wrote: >>>>> This is why we really do need some notion of QoS other than The Fat >>>>> Pipe. It doesn't have to be as elaborate as RSVP-disciplined CAC, >>>>> but you need to be able to prioritize traffic that matters and >>>>> limit >>>>> the amount of traffic that gets prioritized. It doesn't have to be >>>>> more complex than that, but it has to do at least that. [Ergo ... >>>>> left as an exercise to the reader.] >>>> >>>> I don't know that the "network" needs to have a more sophisticated >>>> notion of QoS than best effort. It can sometimes be useful for the >>>> network device connected directly to a congested link (e.g. access >>>> link between a site and its upstream provider) to have some >>>> internal-to-the-box QoS configuration. >>>> >>>> It is not uncommon these days for the access router at the customer >>>> premise to have some ACL ruleset that prefers some traffic over >>>> other >>>> traffic or rate-limits certain kinds of traffic -- and equivalent >>>> configuration of the aggregation router on the ISP side of the same >>>> link is also not uncommon these days. >>>> >>>> That said, most congestion today occurs either on an access link >>>> such >>>> as that or on some sort of wireless link (e.g. SATCOM to SW Asia). >>>> ISP core backbones tend to be over-provisioned. Most campus >>>> (wired/fibred) networks are similarly over-provisioned. >>>> >>>> Ran > > cheers > > jon > > > From gaylord at dirtcheapemail.com Sun Mar 6 18:22:12 2005 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Sun, 06 Mar 2005 21:22:12 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <4229DF6F.60205@reed.com> References: <4229DF6F.60205@reed.com> Message-ID: <422BBAD4.6010009@dirtcheapemail.com> David P. Reed wrote: > And exactly what evidence are we considering that Skype, which uses > the TCP stack in the OS, does not reduce its packet flow when > congestion occurs? My mention of ... > I wasn't actually referring to whether Skype responds to congestion. > As a user I see no evidence that it tampers with TCP, but I plan to > dig further. Actually, It is very unusual for a VoIP application to use TCP. Normally UDP is used, and with good reason: reliable transport isn't needed. At <100kbps (could even be <30k), the impact is modest for most links. Please post a tcpdump snippet for confirmation. --ckg From xie at ict.ac.cn Sun Mar 6 17:58:24 2005 From: xie at ict.ac.cn (Xie) Date: Mon, 7 Mar 2005 09:58:24 +0800 Subject: [e2e] Application Traffic Characteristics measurement. References: <11ad0fa8050304053342514f51@mail.gmail.com><200503041318.37290.don@dhoffman.net><4228E595.9030407@dirtcheapemail.com><9531abdc241f450e15fa92b84fe74310@extremenetworks.com><005501c52224$8c481b30$4d27e29f@ictxie> Message-ID: <000001c522c0$bb913c90$4d27e29f@ictxie> Hi Dear Sudeep, There are several commercial network test instruments such as Avalanche of Spirent, IPIE of Navtel, and other instrument of Agilent for synthetic traffic generating at application level. NetTurbo is built on ourselves hardware platform with network processor. If you want, we will send these metrics data to you on this April when we will perform measurement experiment on a carrier's network with NetTurbo. Cheers, Xie ----- Original Message ----- From: "Sudeep Goyal" To: "Xie" Cc: Sent: Sunday, March 06, 2005 10:57 PM Subject: Re: [e2e] Application Traffic Characteristics measurement. > Thanks Xie, > > I am looking for QoS parameters like delay, jitter, throughput at the > application level and traffic/packet level both. I am using tcpdump, > tcptrace (and latelty tstat) for passive measurements and Iperf, D-ITG for > active measurements. > > If you can suggest me some link to some synthetic traffic generator > (that generates application traffic like VoIP, Video, FTP) which > I couldn't find yet, it would be of great help to me and then measures the > perforamnce like delay, jitter experienced by the application. D-ITG does > this, but only for VoIP and DNS. > > I tried looking for Netturbo on Google. Could get hands only on few > papers. I would be interested in looking at the tool. Can you plz suggest > me the link to the same? > > Thanks for all the help, > > Regards, > Sudeep > > > > > > On Sun, 6 Mar 2005, Xie wrote: > > > Hi Dear Sudeep, > > > > Which metrics will be included in your "traffic QoS characteristic"? > Some end to end performance metrics at application level or traffic ratio > for every application or other metrics else? We have developed a network > measurement system named NetTurbo which can provide the first two kinds metrics. > > > > Cheers, > > Xie > > ----- Original Message ----- > > From: "Sudeep Goyal" > > To: "End-2-End list" > > Sent: Saturday, March 05, 2005 9:12 PM > > Subject: [e2e] Application Traffic Characteristics measurement. > >end2end-interest at postel.org > > > >> Hi All, > >> > >> I have to measure traffic QoS characteristic of different applications > >> like FTP, Video, VoIP. > >> > >> Can you please suggest me ways to do that? I have been looking into TGs > >> and sniffers. But they donot help me know the traffic characteristcs. I > >> understand that there are no straight ways to do it. But, any > >> possible attempts around would help me a lot. > >> > >> I need this to create QoS traffic profiles which can be used by > >> different applications for QoS specifications. > >> > >> Thanks and regards, > >> Sudeep > >> > >> > >> > > -- > From dina at csail.mit.edu Sat Mar 5 13:18:48 2005 From: dina at csail.mit.edu (Dina Katabi) Date: Sat, 05 Mar 2005 16:18:48 -0500 Subject: [e2e] SRUTI'05: A New Usenix Security Workshop Message-ID: <422A2238.7040202@csail.mit.edu> ----------------- SRUTI's CALL FOR PAPER ------------- *SRUTI 2005* USENIX Workshop on Steps to Reducing Unwanted Traffic on the Internet (July 7-8 ?05, MIT, Cambridge, MA) The Internet is under increasing attacks with unwanted traffic in the form of spam, distributed denial of service, viruses, worms, etc. Unwanted traffic on the Internet has manifested itself as attacks on many protocols (IP, TCP, DNS, BGP, and HTTP) and popular applications (e.g., Email, Web). Recently, attacks combining multiple exploits have become common. Many solutions have been proposed for specific attacks, some of which have had limited success. SRUTI seeks research on the unwanted traffic problem that looks across the protocol stack, examines attack commonalities, and investigates how various solutions interact and whether they can be combined to increase security. Original research, promising ideas, and steps towards practical solutions at all levels are sought. We look for ideas in networking and systems, and insights from other areas such as databases, data mining, and economics. SRUTI aims to bring academic and industrial research communities together with those who face the problems at the operational level. SRUTI 2005 will be a one and a half day event. Each session chair will play the role of a discussant and present a summary of the papers in the session and a state-of-the-art synopsis of the topic. The workshop will be highly interactive, with a substantial time devoted to questions and answers. Submissions must contribute to improving the current understanding of unwanted traffic and/or suggestions to reducing it. The proceedings of the workshop will be published. RELEVANT TOPICS * Architectural solutions to the unwanted traffic problem * Scientific assessment of the spread and danger of the attacks * Practical countermeasures to various aspects of unwanted traffic (Spam, DoS, worms,...) * Cross-layer solutions and solutions to combination attacks * Attacks on emerging technologies (e.g., sensors, VOIP, PDAs) and their countermeasures * Privacy and anonymity * Intrusion avoidance, detection, and response * Viruses, Worms and other malicious code * Analysis of protocols and systems vulnerabilities * Handling errors/misconfigurations that might lead to unwanted traffic * Attacks on specific distributed systems (e.g., P2P) or network technologies (e.g., wireless networks) * Data mining with application to unwanted traffic * New types of solutions: incentive-based, economic, statistical, collaborative, etc. PROGRAM COMMITTEE Paul Barford, University of Wisconsin, Madison Steven M. Bellovin, AT&T Labs?Research Herve Debar, France Telecom R&D Mark Handley University College London Dina Katabi, MIT Bala Krishnamurthy, AT&T Labs?Research Doug Maughan, DHS Chris Morrow, UUNET Vern Paxson, ICIR/ICSI Dawn Song, Carnegie Mellon University Paul Vixie, ISC DEADLINES Submission deadline: March 30, 2005 (11:59 PM EST, HARD) Acceptance notification: May 3, 2005. Final papers due: May 23, 2005. Workshop: July 7-8, 2005. STEERING COMMITTEE Dina Katabi (MIT) and Balachander Krishnamurthy (AT&T Labs?Research) Further Information - Workshop URL Paper format, submission date etc. to be found at http://www.research.att.com/~bala/sruti/ ------------------ END of CFP --------------------- From cannara at attglobal.net Mon Mar 7 09:01:19 2005 From: cannara at attglobal.net (Cannara) Date: Mon, 07 Mar 2005 09:01:19 -0800 Subject: [e2e] Skype and congestion collapse. References: <11ad0fa8050304053342514f51@mail.gmail.com> <4228C6E9.E6718A3D@attglobal.net> Message-ID: <422C88DF.CE2D4588@attglobal.net> The points of interest to people (corporate) wanting to limit P2P, IM and even VoIP, are at least: a) Intellectual property theft/dispersal. b) Liability to copyright suit. c) Hidden file accesses (perhaps for a & b). d) WAN-link capacity reduction. Note that knowing how much of any given traffic is occurring among points within and outside an organization also suggests what might be going on. Just pure phone calling is typically not the concern. Any protocol may be misused by an application designed to masquerade as benign. Traffic stats help uncover such piracy. Also, while there are P2P sources that are limited, many universities have high-rate links to the Inet, so keeping all the students at bay in up/downloading is important in many such places, not just corporations. A couple of friends who manage parts of Stanford's net explained what happened one day when a Packeteer box failed and a dorm or two were no longer limited to 100Mb/s into the 1Gb/s path. :] Alex "DJamel H. Sadok" wrote: > > IMHO, it does not anymore make a lot of sense to penalyze "low" bandwidth > applications such as skype/voip/.. by applying TCP-like congestion control > or access control schemes. Such mechanisms are better used on heavy > hitters such as P2P multimedia transfers. Even when many instances of > voice sessions for example are made at the access network/loop. If this is > not going to be a problem at thi side of the network, it can hardly cause > problems within overprovisioned backbones. > > Most P2P heavy applications are end-to-end (generated by residential > users) and therefore would not be capable of occupying high bandwidth > (Mbps! any numbers to counter this!!) network share although they often > transfer large amounts of data. > > We need traffic to justify giga-networks hopefully all the way to the > local loop. There has been a great deal of work on protocol adaptation and > congestion control with little actual use. > > P2P applications allow a user to specify her uplink and downlink bandwidth > capacities. That is more that is needed in terms of congestion control of > course when using the underlying TCP. > > Djamel > > On Fri, 4 Mar 2005, Cannara wrote: > > > Having consulted with folks doing products for tracking/controlling these > > kinds of traffic, any P2P system that takes whatever it can isn't really to > > blame. Even VoIP is being used to transfer data (not just voice) now. Any > > 'internet' that can't manage its congestion at the network layer isn't an > > internetwork. So, apart from all the other Internet mistakes, like > > insecurity, which many of us earn $ from, we've also earned from misdesigned > > congestion control. The difference between old-fashioned PSTNs and the > > Internet are making the latter look more silly and wasteful day by day. > > Despite the $, I hope some awakening occurs, but we, the taxpayers, will again > > have to pay for any eventual, engineered and real internetwork. > > > > Alex > > > > "Alexandre L. Grojsgold" wrote: > >> > >>> IMHO, I think that applications like Skype should be responsible for > >>> managing the congestion they could potentially cause. This brings me > >>> to my question. If more and more applications start to behave like > >>> Skype and selfishly worry more about their business model than about > >>> the health of the global Internet, > >> > >> I guess that what you mean is that Skipe does not use TCP-like bandwidth > >> reduction, so it selfishly does not give up sending 10Kbps even in case of > >> congestion. > >> > >> Well, one must have in mind that at the end of a skype voice connection > >> ther is as human being that, in case of congestion and excessive packet > >> loss will simply hang up the call - or even be so unhappy that he will > >> never try calling thru Skype again. > >> > >> Probably the "selfish" behavior if skipe is due to the fact that it is > >> unable to make voice go thru using less than 10k - lessening the bandwidth > >> would be useless, so in case of congestion, it will simply hang up - or > >> wait till the user gives up. > >> > >> -- Alexandre. > > From jamel at cin.ufpe.br Mon Mar 7 09:14:47 2005 From: jamel at cin.ufpe.br (DJamel H. Sadok) Date: Mon, 7 Mar 2005 14:14:47 -0300 (BRT) Subject: [e2e] Skype and congestion collapse. Message-ID: IMHO, it does not anymore make a lot of sense to penalyze "low" bandwidth applications such as skype/voip/.. by applying TCP-like congestion control or access control schemes. Such mechanisms are better used on heavy hitters such as some P2P multimedia transfers. Even when many instances of voice sessions for example are made at the access network/loop. If this is not going to be a problem at this side of the network (fisrt/last mile), it can hardly cause problems within overprovisioned backbones. Most P2P heavy applications are end-to-end (generated by residential users) and therefore would not be capable of occupying high bandwidth (Mbps! any numbers that suggest otherwise!!) network share although they often transfer large amounts of data. We need traffic to justify giga-networks hopefully all the way to the local loop. There has been a great deal of work on protocol adaptation and congestion control with little actual use. P2P applications allow a user to specify her uplink and downlink bandwidth capacities. That is more than is needed in terms of congestion control of course when using the underlying TCP. Djamel From rik at rikwade.com Mon Mar 7 11:54:26 2005 From: rik at rikwade.com (Richard Wade) Date: Tue, 8 Mar 2005 08:54:26 +1300 (NZDT) Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: Message-ID: <46127.202.147.43.67.1110225266.squirrel@www.rikwade.com> "DJamel H. Sadok" wrote: > IMHO, it does not anymore make a lot of sense to penalyze "low" bandwidth > applications such as skype/voip/.. by applying TCP-like congestion control > or access control schemes. Such mechanisms are better used on heavy > hitters such as some P2P multimedia transfers. But how many mice does it take to bring down an elephant? This area has been examined quite extensively. A quick Web search revealed: http://www.ieee-infocom.org/2004/Papers/58_2.PDF "Using Partial Differential Equations to Model TCP Mice and Elephants in Large IP Networks" or for a different view of the problem: http://www.caida.org/outreach/papers/2002/Dragonflies/cnit.pdf "Understanding Internet Traffic Streams: Dragonflies and Tortoises" >From a practical IP networking perspective, the "big hitters" are actually quite easy to deal with. If you've got a flow that's long in duration (minutes, hours, or days) then policy can be applied at the edge of your network to shape or control it. Many people are having to deploy P2P control systems in their networks due to the huge increase in this type of application over the past few years. In the late 1990s, people deployed huge arrays of HTTP proxies in order to save on expensive off-net bandwidth. The effectiveness of this slowly decreased as more and more dynamic content was served up. P2P is just the latest application type that is consuming the majority of off-net transit for service providers. Yes, bandwidth costs are much lower than in the late 1990s, but you still want to minimise the cost, right? You can deploy P2P caches on-net, but some people seem to be shying away from deploying them, citing "legal reasons". I'm not quite sure what the difference is between a P2P cache and a HTTP cache in this respect, however. Alternatively, you can use protocol re-write engines, such as the Packeteer, which can sit in-line and shape the flows down to specified rates. Or you can try to just queue and shape the application's traffic at your edge routers. > We need traffic to justify giga-networks hopefully all the way to the > local loop. There has been a great deal of work on protocol adaptation and > congestion control with little actual use. I would actually argue that we need the applications to justify giga-networks, not just "traffic". What actually _are_ the killer applications for high bandwidth consumer access? VoIP? - low bandwidth; Web? - low bandwidth and non-realtime; etc. So we're currently left with P2P file transfer which, among its many legitimate uses, is generally used to illegally distribute copyright material. Not quite the ideal "killer application". Arguably, many providers are building high bandwidth access (and core) networks to support next-generation services which aren't quite here yet. Before these services can be deployed and the networks can be engineered in to a state that permits more fine-grained traffic control, applications such as Skype will have to deal with this type of situation. -- rik From dpreed at reed.com Mon Mar 7 12:02:12 2005 From: dpreed at reed.com (David P. Reed) Date: Mon, 07 Mar 2005 15:02:12 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <422C88DF.CE2D4588@attglobal.net> References: <11ad0fa8050304053342514f51@mail.gmail.com> <4228C6E9.E6718A3D@attglobal.net> <422C88DF.CE2D4588@attglobal.net> Message-ID: <422CB344.8040808@reed.com> Cannara wrote: >The points of interest to people (corporate) wanting to limit P2P, IM and even >VoIP, are at least: > >a) Intellectual property theft/dispersal. > >b) Liability to copyright suit. > >c) Hidden file accesses (perhaps for a & b). > >d) WAN-link capacity reduction. > > > In other words, the IT department is under the illusion that they should be "in control" and the second illusion that blocking connectivity is always a net benefit to the company, because all communications is "bad". This is just like those who practice chastity who think all sex is bad, and want to legislate the way humanity reproduces itself out of existence. From randy at psg.com Mon Mar 7 13:19:37 2005 From: randy at psg.com (Randy Bush) Date: Mon, 7 Mar 2005 11:19:37 -1000 Subject: [e2e] Skype and congestion collapse. References: <11ad0fa8050304053342514f51@mail.gmail.com> <4228C6E9.E6718A3D@attglobal.net> <422C88DF.CE2D4588@attglobal.net> <422CB344.8040808@reed.com> Message-ID: <16940.50537.388530.399520@roam.psg.com> > In other words, the IT department is under the illusion that they should > be "in control" and the second illusion that blocking connectivity is > always a net benefit to the company, because all communications is "bad". the root of the IT problem is that they are given the goals of and are measured by, minimizing overall costs. this they achieve through control, restriction of function, and homogenization. they are not given the goal of maximizing the users' productivity. randy From Jon.Crowcroft at cl.cam.ac.uk Mon Mar 7 14:49:55 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 07 Mar 2005 22:49:55 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from Randy Bush of "Mon, 07 Mar 2005 11:19:37 -1000." <16940.50537.388530.399520@roam.psg.com> Message-ID: a university in the UK that will remain nameless blocked access to the web in the early days coz they said the use of the net would bankrupt them for no good ends of course the argument about preventing books (e.g. early translations of the bible into a third language like english) getting into just anyone's hands were probably rooted in similar cost/control debates (that are all greek to me) anyhow, to return to the original debate, the skype may be falling but it aint the sky that is falling - and (to address someone else's email) what is more an aggregate of n Mkbps constant bit rate flows is NOT the same as an aggregate of a lot of mice nor would it approximate an elephant - the equations are different and we dont have enough experience of very large numbers of voip calls (whether p2p or just straight unicast point-to-point udp) in the public internet yet to say how a multiplex looks for example, as the loss rate goes up, how do the +set of+ users behave in terms of quality tolerance? the solution to the IT department problem you mention below is simple - explode your organisations IT provisioning - just give each sub-componenet the right to buy internet acces, computers and support from anywhere - there are loads of places way more competetive than most large outfits own IT departments - once they have to compete, they soon stop obstructing the primary business... they just arent that important compared with buildings and food, or power and transport, any more:) In missive <16940.50537.388530.399520 at roam.psg.com>, Randy Bush typed: >>> In other words, the IT department is under the illusion that they should >>> be "in control" and the second illusion that blocking connectivity is >>> always a net benefit to the company, because all communications is "bad". >> >>the root of the IT problem is that they are given the goals of and >>are measured by, minimizing overall costs. this they achieve >>through control, restriction of function, and homogenization. >>they are not given the goal of maximizing the users' productivity. >> >>randy >> cheers jon From cannara at attglobal.net Mon Mar 7 15:04:18 2005 From: cannara at attglobal.net (Cannara) Date: Mon, 07 Mar 2005 15:04:18 -0800 Subject: [e2e] Skype and congestion collapse. References: <11ad0fa8050304053342514f51@mail.gmail.com> <4228C6E9.E6718A3D@attglobal.net> <422C88DF.CE2D4588@attglobal.net> <422CB344.8040808@reed.com> Message-ID: <422CDDF2.D32AB6F@attglobal.net> Now I think folks would read such absolutes as 'all communications is "bad"' into what I listed. Some companies lose millions of $ via their networks too frequently, just in the form of products about to be released via normal channels. Obviously, if your Stanford paycheck got hijacked before making it to your account, you'd be complaining too, David. :] The idea of the "free Internet" never was a good one. It certainly isn't truly free for most of us these days. Alex "David P. Reed" wrote: > > Cannara wrote: > > >The points of interest to people (corporate) wanting to limit P2P, IM and even > >VoIP, are at least: > > > >a) Intellectual property theft/dispersal. > > > >b) Liability to copyright suit. > > > >c) Hidden file accesses (perhaps for a & b). > > > >d) WAN-link capacity reduction. > > > > > In other words, the IT department is under the illusion that they should > be "in control" and the second illusion that blocking connectivity is > always a net benefit to the company, because all communications is "bad". > > This is just like those who practice chastity who think all sex is bad, > and want to legislate the way humanity reproduces itself out of existence. From cannara at attglobal.net Mon Mar 7 15:09:22 2005 From: cannara at attglobal.net (Cannara) Date: Mon, 07 Mar 2005 15:09:22 -0800 Subject: [e2e] Skype and congestion collapse. References: <46127.202.147.43.67.1110225266.squirrel@www.rikwade.com> Message-ID: <422CDF22.85D924EF@attglobal.net> I'll 2nd this and just add that corporate folks do like P2P for their own purposes, such as providing multiple external sources for downloading presentations & docs to field staff & customers quickly, anywhere. It's a wave that's not going to die down. Questioably-legal P2P uses, however, will become more & more monitored & controlled. Alex Richard Wade wrote: > > "DJamel H. Sadok" wrote: > > IMHO, it does not anymore make a lot of sense to penalyze "low" bandwidth > > applications such as skype/voip/.. by applying TCP-like congestion control > > or access control schemes. Such mechanisms are better used on heavy > > hitters such as some P2P multimedia transfers. > > But how many mice does it take to bring down an elephant? > This area has been examined quite extensively. A quick Web search revealed: > > http://www.ieee-infocom.org/2004/Papers/58_2.PDF "Using Partial > Differential Equations to Model TCP Mice and Elephants in Large IP > Networks" > > or for a different view of the problem: > > http://www.caida.org/outreach/papers/2002/Dragonflies/cnit.pdf > "Understanding Internet Traffic Streams: Dragonflies and Tortoises" > > >From a practical IP networking perspective, the "big hitters" are actually > quite easy to deal with. If you've got a flow that's long in duration > (minutes, hours, or days) then policy can be applied at the edge of your > network to shape or control it. Many people are having to deploy P2P > control systems in their networks due to the huge increase in this type of > application over the past few years. > > In the late 1990s, people deployed huge arrays of HTTP proxies in order to > save on expensive off-net bandwidth. The effectiveness of this slowly > decreased as more and more dynamic content was served up. P2P is just the > latest application type that is consuming the majority of off-net transit > for service providers. Yes, bandwidth costs are much lower than in the > late 1990s, but you still want to minimise the cost, right? > > You can deploy P2P caches on-net, but some people seem to be shying away > from deploying them, citing "legal reasons". I'm not quite sure what the > difference is between a P2P cache and a HTTP cache in this respect, > however. Alternatively, you can use protocol re-write engines, such as the > Packeteer, which can sit in-line and shape the flows down to specified > rates. Or you can try to just queue and shape the application's traffic at > your edge routers. > > > We need traffic to justify giga-networks hopefully all the way to the > > local loop. There has been a great deal of work on protocol adaptation and > > congestion control with little actual use. > > I would actually argue that we need the applications to justify > giga-networks, not just "traffic". What actually _are_ the killer > applications for high bandwidth consumer access? VoIP? - low bandwidth; > Web? - low bandwidth and non-realtime; etc. So we're currently left with > P2P file transfer which, among its many legitimate uses, is generally used > to illegally distribute copyright material. Not quite the ideal "killer > application". > > Arguably, many providers are building high bandwidth access (and core) > networks to support next-generation services which aren't quite here yet. > Before these services can be deployed and the networks can be engineered > in to a state that permits more fine-grained traffic control, applications > such as Skype will have to deal with this type of situation. > -- > rik From ggm at apnic.net Mon Mar 7 15:22:06 2005 From: ggm at apnic.net (George Michaelson) Date: Mon, 7 Mar 2005 17:22:06 -0600 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: <16940.50537.388530.399520@roam.psg.com> Message-ID: <20050307172206.1ce23527@garlique> I'm not sure I should be proud of it, but I recall both verbal and some written advice to my masters in the University of Queensland about the implications of this stupid WWW stuff, and how hard it was to fit into a proper, authorized publishing model. Your basic 'another bad idea' message. It was quite clear within a short period of time how badly I (and others in computer centres) had mis-judged what real-users, departments, academics wanted from IT, and how wonderfully liberating the web was for them, precisely because it bypassed all that bureaucratic crap people like me wanted to foist on them. -George From cannara at attglobal.net Mon Mar 7 15:54:26 2005 From: cannara at attglobal.net (Cannara) Date: Mon, 07 Mar 2005 15:54:26 -0800 Subject: [e2e] Skype and congestion collapse. References: <16940.50537.388530.399520@roam.psg.com> <20050307172206.1ce23527@garlique> Message-ID: <422CE9B2.45B8F57F@attglobal.net> You mean the IETF & other bureaucracies didn't invent the most used apps on the Inet?! :] Alex George Michaelson wrote: > > I'm not sure I should be proud of it, but I recall both verbal and some > written advice to my masters in the University of Queensland about the > implications of this stupid WWW stuff, and how hard it was to fit into a > proper, authorized publishing model. Your basic 'another bad idea' message. > > It was quite clear within a short period of time how badly I (and others in > computer centres) had mis-judged what real-users, departments, academics > wanted from IT, and how wonderfully liberating the web was for them, > precisely because it bypassed all that bureaucratic crap people like me > wanted to foist on them. > > -George From gaylord at dirtcheapemail.com Mon Mar 7 20:31:19 2005 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Mon, 07 Mar 2005 23:31:19 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <422CE9B2.45B8F57F@attglobal.net> References: <16940.50537.388530.399520@roam.psg.com> <20050307172206.1ce23527@garlique> <422CE9B2.45B8F57F@attglobal.net> Message-ID: <422D2A97.2050706@dirtcheapemail.com> Cannara wrote: >You mean the IETF & other bureaucracies didn't invent the most used apps on >the Inet?! :] > > They just didn't invent the most used content. :-) --ckg From Jon.Crowcroft at cl.cam.ac.uk Tue Mar 8 00:24:27 2005 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 08 Mar 2005 08:24:27 +0000 Subject: [e2e] Skype and congestion collapse. In-Reply-To: Message from Clark Gaylord of "Mon, 07 Mar 2005 23:31:19 EST." <422D2A97.2050706@dirtcheapemail.com> Message-ID: Alex is right -email and ftp pre-date ip/tcp and the ietf; www was done by some mad english bloke (sir tim berners-lee) with no due respect to all the authorities about how a global hypermedia system should be done; and he didnt predict google afaik. p2p is similar... A nice feature of the internet is the ease with which it _lets_ random people innovate; just before www took off, there was an amazing plethora of tools remember archie or gopher or wais) - Something will crystalize out of p2p (actually is starting to) that will just be how we do stuff - 10 years from now (less) people will think this discussion is weird... justr as george michaelson implied about the turnaround on WWW that lotsa central IT services had to go thru... e.g. if someone can figure out the drm, itunes would work way faster with p2p. no - seriously: if we wanted to propagate virus and worm protection faster than worms, (e.g. security upgrade/patches) and can figure out the code signing etc, we could do worse than looking at p2p; And i really like skype - the kazaa people really _got it_ - voip is not necessarily about free audio, but it is about new features .... (see henning schulzrinne's web pages for some very good debates about what its all readlly for) In missive <422D2A97.2050706 at dirtcheapemail.com>, Clark Gaylord typed: >>Cannara wrote: >> >>>You mean the IETF & other bureaucracies didn't invent the most used apps on >>>the Inet?! :] >>> >>> >>They just didn't invent the most used content. :-) >> >>--ckg >> >> cheers jon From jamel at cin.ufpe.br Tue Mar 8 04:20:22 2005 From: jamel at cin.ufpe.br (DJamel H. Sadok) Date: Tue, 8 Mar 2005 09:20:22 -0300 (BRT) Subject: [e2e] Skype and congestion collapse. In-Reply-To: <422C88DF.CE2D4588@attglobal.net> References: <11ad0fa8050304053342514f51@mail.gmail.com> <4228C6E9.E6718A3D@attglobal.net> <422C88DF.CE2D4588@attglobal.net> Message-ID: I think that it is still worth making a large number of mice happy and maybe one unhappy elephant. The current Internet approach of one size fits all probably cannot be extended to corporate practices. Maybe future Internet architectures should not only consider technology diversity (mobile networks, sensor networks, etc...), naming problems, DNS limitations but also policy differences. We could see a future Internet made from various "what some people called contexts [work from Jon]". One of these could be the corporate context. Djamel On Mon, 7 Mar 2005, Cannara wrote: > The points of interest to people (corporate) wanting to limit P2P, IM and even > VoIP, are at least: > > a) Intellectual property theft/dispersal. > > b) Liability to copyright suit. > > c) Hidden file accesses (perhaps for a & b). > > d) WAN-link capacity reduction. > > Note that knowing how much of any given traffic is occurring among points > within and outside an organization also suggests what might be going on. > Just pure phone calling is typically not the concern. Any protocol may be > misused by an application designed to masquerade as benign. Traffic stats > help uncover such piracy. Also, while there are P2P sources that are limited, > many universities have high-rate links to the Inet, so keeping all the > students at bay in up/downloading is important in many such places, not just > corporations. A couple of friends who manage parts of Stanford's net > explained what happened one day when a Packeteer box failed and a dorm or two > were no longer limited to 100Mb/s into the 1Gb/s path. :] > > Alex > > "DJamel H. Sadok" wrote: >> >> IMHO, it does not anymore make a lot of sense to penalyze "low" bandwidth >> applications such as skype/voip/.. by applying TCP-like congestion control >> or access control schemes. Such mechanisms are better used on heavy >> hitters such as P2P multimedia transfers. Even when many instances of >> voice sessions for example are made at the access network/loop. If this is >> not going to be a problem at thi side of the network, it can hardly cause >> problems within overprovisioned backbones. >> >> Most P2P heavy applications are end-to-end (generated by residential >> users) and therefore would not be capable of occupying high bandwidth >> (Mbps! any numbers to counter this!!) network share although they often >> transfer large amounts of data. >> >> We need traffic to justify giga-networks hopefully all the way to the >> local loop. There has been a great deal of work on protocol adaptation and >> congestion control with little actual use. >> >> P2P applications allow a user to specify her uplink and downlink bandwidth >> capacities. That is more that is needed in terms of congestion control of >> course when using the underlying TCP. >> >> Djamel >> >> On Fri, 4 Mar 2005, Cannara wrote: >> >>> Having consulted with folks doing products for tracking/controlling these >>> kinds of traffic, any P2P system that takes whatever it can isn't really to >>> blame. Even VoIP is being used to transfer data (not just voice) now. Any >>> 'internet' that can't manage its congestion at the network layer isn't an >>> internetwork. So, apart from all the other Internet mistakes, like >>> insecurity, which many of us earn $ from, we've also earned from misdesigned >>> congestion control. The difference between old-fashioned PSTNs and the >>> Internet are making the latter look more silly and wasteful day by day. >>> Despite the $, I hope some awakening occurs, but we, the taxpayers, will again >>> have to pay for any eventual, engineered and real internetwork. >>> >>> Alex >>> >>> "Alexandre L. Grojsgold" wrote: >>>> >>>>> IMHO, I think that applications like Skype should be responsible for >>>>> managing the congestion they could potentially cause. This brings me >>>>> to my question. If more and more applications start to behave like >>>>> Skype and selfishly worry more about their business model than about >>>>> the health of the global Internet, >>>> >>>> I guess that what you mean is that Skipe does not use TCP-like bandwidth >>>> reduction, so it selfishly does not give up sending 10Kbps even in case of >>>> congestion. >>>> >>>> Well, one must have in mind that at the end of a skype voice connection >>>> ther is as human being that, in case of congestion and excessive packet >>>> loss will simply hang up the call - or even be so unhappy that he will >>>> never try calling thru Skype again. >>>> >>>> Probably the "selfish" behavior if skipe is due to the fact that it is >>>> unable to make voice go thru using less than 10k - lessening the bandwidth >>>> would be useless, so in case of congestion, it will simply hang up - or >>>> wait till the user gives up. >>>> >>>> -- Alexandre. >>> > From rony3000us at hotmail.com Wed Mar 9 15:55:45 2005 From: rony3000us at hotmail.com (Syed Faisal Hasan) Date: Wed, 09 Mar 2005 23:55:45 +0000 Subject: [e2e] Skype and congestion collapse. Message-ID: Hello, Perhaps we may focus our discussion on the following lines from Emmanuel's mail: "IMHO, I think that applications like Skype should be responsible for managing the congestion they could potentially cause. This brings me to my question. If more and more applications start to behave like Skype and selfishly worry more about their business model than about the health of the global Internet, is there still a possibility of a congestion collapse today ? Or, are those worries well behind because the problem can be compensated by introducing more bandwidth into the network " I 'ld like to add the following: " If congestion collapse and/or having fair share of bandwidth is not an issue then what 's the purpose of carrying out research on TFRC ? Is there any possibility of global deployment of TFRC based on RTP ? what is the chance of DCCP replacing UDP in some applications? What should be the research direction for people who want to do research in this area?" Faisal _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From cannara at attglobal.net Wed Mar 9 16:16:26 2005 From: cannara at attglobal.net (Alex Cannara) Date: Wed, 09 Mar 2005 16:16:26 -0800 Subject: [e2e] Skype and congestion collapse. In-Reply-To: References: Message-ID: <422F91DA.7080207@attglobal.net> Syed, the misconception is that apps are to manage network resources. That's not how more robust systems, like the established telco and private network systems work. Systems must protect themselves, even a car's gearbox, from external abuse. The Internet is only different in that attention wasn't paid to doing that in its design. Alex Syed Faisal Hasan wrote: > Hello, > > Perhaps we may focus our discussion on the following lines from > Emmanuel's mail: > > > "IMHO, I think that applications like Skype should be responsible for > managing the congestion they could potentially cause. This brings me > to my question. If more and more applications start to behave like > Skype and selfishly worry more about their business model than about > the health of the global Internet, is there still a possibility of a > congestion collapse today ? Or, are those worries well behind because > the problem can be compensated by introducing more bandwidth into the > network " > > I 'ld like to add the following: > > " If congestion collapse and/or having fair share of bandwidth is not an > issue then what 's > the purpose of carrying out research on TFRC ? Is there any possibility > of global deployment > of TFRC based on RTP ? what is the chance of DCCP replacing UDP in some > applications? > What should be the research direction for people who want to do research > in this area?" > > > Faisal > From lars-erik.jonsson at ericsson.com Wed Mar 9 23:32:56 2005 From: lars-erik.jonsson at ericsson.com (Lars-Erik Jonsson (LU/EAB)) Date: Thu, 10 Mar 2005 08:32:56 +0100 Subject: [e2e] Skype and congestion collapse. Message-ID: <026F8EEDAD2C4342A993203088C1FC051C26FD@esealmw109.eemea.ericsson.se> > Syed, the misconception is that apps are to manage network > resources. That's not how more robust systems, like the > established telco and private network systems work. > Systems must protect themselves, even a car's gearbox, > from external abuse. The Internet is only different in > that attention wasn't paid to doing that in its design. And thanks to that, the Internet became conceptually simple, flexible, inexpensive to use, and to the benefits of the users, as opposed to the telco systems. /L-E From fahad.dogar at gmail.com Thu Mar 10 02:14:11 2005 From: fahad.dogar at gmail.com (Fahad Dogar) Date: Thu, 10 Mar 2005 15:14:11 +0500 Subject: [e2e] MPLS TE: Propogation of Aggregate Information Message-ID: Hi, Most of the recent work on MPLS Restoration Routing consider the propogation of aggregate link usage information which includes the bandwidth allocated for active and backup LSPs in addition to the residual bandwidth on a given link. However, the standards on OSPF-TE only consider propogating residual bandwidth of a link for traffic engineering purposes. Can anyone refer to any recent draft/RFC which talks about disseminating aggregate link usage information in the network? Thanks in advance, Fahad From cannara at attglobal.net Thu Mar 10 16:54:20 2005 From: cannara at attglobal.net (Cannara) Date: Thu, 10 Mar 2005 16:54:20 -0800 Subject: [e2e] Skype and congestion collapse. References: <026F8EEDAD2C4342A993203088C1FC051C26FD@esealmw109.eemea.ericsson.se> Message-ID: <4230EC3C.2AEBD85F@attglobal.net> Well, er, yes -- if you mean easy to exploit for functional 'advances' for humanity's benefit, like spam, cons, identity theft, yadda, yadda. Other packet networks, especially corporate, worked just as well, and had access control -- what a concept! And, just think, every Cisco VoIP switch has to have a fixed geographical location and a POTS line, if its users want to have a 911 call bring the rescuers to the right country, state, county, city, street, bldg., floor, etc. (planet is understood, so far :). Alex "Lars-Erik Jonsson (LU/EAB)" wrote: > > > Syed, the misconception is that apps are to manage network > > resources. That's not how more robust systems, like the > > established telco and private network systems work. > > Systems must protect themselves, even a car's gearbox, > > from external abuse. The Internet is only different in > > that attention wasn't paid to doing that in its design. > > And thanks to that, the Internet became conceptually simple, > flexible, inexpensive to use, and to the benefits of the > users, as opposed to the telco systems. > > /L-E From rogerslin at 163.com Thu Mar 10 18:13:36 2005 From: rogerslin at 163.com (rogerslin@163.com) Date: Fri, 11 Mar 2005 10:13:36 +0800 Subject: [e2e] Question about DHT Message-ID: <200503110214.j2B2E9629575@boreas.isi.edu> Hi all, Most of recent research in Distribute Hash Table (DHT) seem just focus on the routing in the application layer. However, two nodes that reside close each other in the application layer may be actually in two continents. I think it isn't effient to locate data in a p2p system with such DHT. Does it possible to integrate the underline routing feature with the upper routing in the DHT? ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡rogerslin ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-03-11 From dga+ at cs.cmu.edu Thu Mar 10 18:52:05 2005 From: dga+ at cs.cmu.edu (David Andersen) Date: Thu, 10 Mar 2005 21:52:05 -0500 Subject: [e2e] Question about DHT In-Reply-To: <200503110214.j2B2E9629575@boreas.isi.edu> References: <200503110214.j2B2E9629575@boreas.isi.edu> Message-ID: See freedman et al.'s sloppy dht stuff that they put into the Coral system. www.coralcdn.org and see the references therein. in general, there's been a lot of work on this, unless I'm misunderstanding your question. -dave On Mar 10, 2005, at 9:13 PM, rogerslin at 163.com wrote: > Hi all, > Most of recent research in Distribute Hash Table (DHT) seem just > focus on the routing in the application layer. However, two nodes that > reside close each other in the application layer may be actually in > two continents. I think it isn't effient to locate data in a p2p > system with such DHT. Does it possible to integrate the underline > routing feature with the upper routing in the DHT? > > ????????rogerslin > ????????2005-03-11 > > From xie at ict.ac.cn Thu Mar 10 19:38:47 2005 From: xie at ict.ac.cn (Xie) Date: Fri, 11 Mar 2005 11:38:47 +0800 Subject: [e2e] Question about DHT References: <200503110214.j2B2E9629575@boreas.isi.edu> Message-ID: <00b601c525eb$d525e560$4d27e29f@ictxie> There are many researchs on mismatch issue. You can get some papers from google. Cheers, Xie ----- Original Message ----- From: To: "end2end-interest" Sent: Friday, March 11, 2005 10:13 AM Subject: [e2e] Question about DHT > Hi all, > Most of recent research in Distribute Hash Table (DHT) seem just focus on the routing in the application layer. However, two nodes that reside close each other in the application layer may be actually in two continents. I think it isn't effient to locate data in a p2p system with such DHT. Does it possible to integrate the underline routing feature with the upper routing in the DHT? > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡rogerslin > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-03-11 > From gaylord at dirtcheapemail.com Thu Mar 10 21:38:15 2005 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Fri, 11 Mar 2005 00:38:15 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <422F91DA.7080207@attglobal.net> References: <422F91DA.7080207@attglobal.net> Message-ID: <42312EC7.9030005@dirtcheapemail.com> Alex Cannara wrote: > Syed, the misconception is that apps are to manage network resources. > That's not how more robust systems, like the established telco and > private network systems work. Systems must protect themselves, even a > car's gearbox, from external abuse. The Internet is only different in > that attention wasn't paid to doing that in its design. But that doesn't mean that we can't pay more attention to it now. Gearboxes didn't protect themselves originally either, but synchromesh and fluid drive have done a lot to address that. The advances in computing are due to algorithms, and in recent years that has been parallel algorithms. That's what TCP is: a distributed, parallel algorithm that does a reasonable job of equitably sharing limited resources. But you are correct that our network systems can do more to enforce fairness and compliance at some level. By protecting TCP traffic from non-TCP-friendly traffic, by ensuring that TCP plays by the rules, by judiciously and scalably employing policing and differential queueing -- we can build a much better system. But what makes the Internet a superior *engineering* solution is that it doesn't try to over-specify everything. "Do just enough" is what makes this work, and it isn't due to laziness: it is due to the inherently superior scalability of this approach. We don't need to debate whether the Internet is a superior solution to the PSTN; reality has already proven that. What is left is for those of us who wistfully harken to when TDM was king and everyone had a 3270 to understand that we need to crack our bell-shaped heads open and get up to date. Poisson and Erlang don't apply anymore, but doesn't mean we can't model (or that we can't extend them in interesting ways, btw). Call admission doesn't apply anymore, but that doesn't mean we have to drop all packets equally. "What do we need to do to make the Internet better?" is the question we need to be asking. --ckg From touch at ISI.EDU Fri Mar 11 07:28:26 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Mar 2005 07:28:26 -0800 Subject: [e2e] Question about DHT In-Reply-To: <200503110214.j2B2E9629575@boreas.isi.edu> References: <200503110214.j2B2E9629575@boreas.isi.edu> Message-ID: <4231B91A.2010902@isi.edu> see www.isi.edu/datarouter rogerslin at 163.com wrote: > Hi all, > Most of recent research in Distribute Hash Table (DHT) seem just focus on the routing in the application layer. However, two nodes that reside close each other in the application layer may be actually in two continents. I think it isn't effient to locate data in a p2p system with such DHT. Does it possible to integrate the underline routing feature with the upper routing in the DHT? > > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡rogerslin > ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-03-11 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050311/bc255704/signature.bin From touch at ISI.EDU Fri Mar 11 07:34:01 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 11 Mar 2005 07:34:01 -0800 Subject: [e2e] Question about DHT In-Reply-To: <4231B91A.2010902@isi.edu> References: <200503110214.j2B2E9629575@boreas.isi.edu> <4231B91A.2010902@isi.edu> Message-ID: <4231BA69.9050202@isi.edu> FWIW, you asked two questions (in a sense): - can things be placed closer to each other in general? - can routing be integrated (that's what datarouter is about) However, integrated routing has nothing to do with proximity per se. Routing can shoot packets far from home, if there are low-hop or high-bandwidth tunnels. Joe Joe Touch wrote: > see www.isi.edu/datarouter > > rogerslin at 163.com wrote: > >>Hi all, >> Most of recent research in Distribute Hash Table (DHT) seem just focus on the routing in the application layer. However, two nodes that reside close each other in the application layer may be actually in two continents. I think it isn't effient to locate data in a p2p system with such DHT. Does it possible to integrate the underline routing feature with the upper routing in the DHT? >> >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡rogerslin >>¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2005-03-11 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050311/5622a467/signature.bin From swapnil at nec-labs.com Fri Mar 11 08:15:21 2005 From: swapnil at nec-labs.com (Swapnil Patil) Date: Fri, 11 Mar 2005 11:15:21 -0500 Subject: [e2e] Question about DHT Message-ID: <951A499AA688EF47A898B45F25BD8EE801212F28@mailer.nec-labs.com> also, check out -- topology aware overlays/DHTs regards -swapnil -----Original Message----- From: end2end-interest-bounces at postel.org on behalf of rogerslin at 163.com Sent: Thu 3/10/2005 9:13 PM To: end2end-interest Cc: Subject: [e2e] Question about DHT Hi all, Most of recent research in Distribute Hash Table (DHT) seem just focus on the routing in the application layer. However, two nodes that reside close each other in the application layer may be actually in two continents. I think it isn't effient to locate data in a p2p system with such DHT. Does it possible to integrate the underline routing feature with the upper routing in the DHT? rogerslin 2005-03-11 From cannara at attglobal.net Fri Mar 11 17:15:08 2005 From: cannara at attglobal.net (Cannara) Date: Fri, 11 Mar 2005 17:15:08 -0800 Subject: [e2e] Skype and congestion collapse. References: <422F91DA.7080207@attglobal.net> <42312EC7.9030005@dirtcheapemail.com> Message-ID: <4232429C.8ABF09EB@attglobal.net> Exactly the right question, Clark. But I'll differ with you on the blanket plaudits to Inet or TCP design. We all know the design of the network layer was inadequate and knew that years in advance of address inadequacy. Doing "just enough" isn't something that can be foreseen either -- how do you know it's "just" enough? On the PSTN, which has such a clean record for access control, sharing, reliability, etc. (and was the physical basis for the Internet) the Inet comes not even close, for the very reason you mention "just enough". So, yes, when will the Inet be properly engineered so kludges like a transport doing what the network should do are gone? Of course, I and other consultants can't complain -- just got paid a couple hundred an hour today to tell someone that NAT boxes don't always let FTP PORT commands through poroperly! Hmmm, now why did we need NAT? Oh yes, "just enough" (for 1980 :). Alex Clark Gaylord wrote: > > Alex Cannara wrote: > > > Syed, the misconception is that apps are to manage network resources. > > That's not how more robust systems, like the established telco and > > private network systems work. Systems must protect themselves, even a > > car's gearbox, from external abuse. The Internet is only different in > > that attention wasn't paid to doing that in its design. > > But that doesn't mean that we can't pay more attention to it now. > Gearboxes didn't protect themselves originally either, but synchromesh > and fluid drive have done a lot to address that. The advances in > computing are due to algorithms, and in recent years that has been > parallel algorithms. That's what TCP is: a distributed, parallel > algorithm that does a reasonable job of equitably sharing limited > resources. But you are correct that our network systems can do more to > enforce fairness and compliance at some level. > > By protecting TCP traffic from non-TCP-friendly traffic, by ensuring > that TCP plays by the rules, by judiciously and scalably employing > policing and differential queueing -- we can build a much better > system. But what makes the Internet a superior *engineering* solution > is that it doesn't try to over-specify everything. "Do just enough" is > what makes this work, and it isn't due to laziness: it is due to the > inherently superior scalability of this approach. We don't need to > debate whether the Internet is a superior solution to the PSTN; reality > has already proven that. What is left is for those of us who wistfully > harken to when TDM was king and everyone had a 3270 to understand that > we need to crack our bell-shaped heads open and get up to date. Poisson > and Erlang don't apply anymore, but doesn't mean we can't model (or that > we can't extend them in interesting ways, btw). Call admission doesn't > apply anymore, but that doesn't mean we have to drop all packets equally. > > "What do we need to do to make the Internet better?" is the question we > need to be asking. > > --ckg From rogerslin at 163.com Sun Mar 13 05:44:56 2005 From: rogerslin at 163.com (=?gb2312?B?0+rB1g==?=) Date: Sun, 13 Mar 2005 21:44:56 +0800 (CST) Subject: [e2e] a question about installing sfs Message-ID: <423443D8.0000F9.13057@m217.163.com> Hello, I'm trying to install mit's SFS and have met some trouble. When I try to compile the sources, I get the error message: sfscrypt.h: In constructor `sfspub::sfspub(sfs_keytype, unsigned char, const str&)': sfscrypt.h:53: error: uninitialized member 'sfspub::eksb_id' with 'const' type 'const int' Does anyone have met this problem? I wonder how to deal with the problem. Thank you! regards, rogerslin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20050313/e152269f/attachment.html From bala at research.att.com Fri Mar 11 11:35:34 2005 From: bala at research.att.com (Balachander Krishnamurthy) Date: Fri, 11 Mar 2005 14:35:34 -0500 Subject: [e2e] CFP: IMC 2005 (Sponsored by Sigcomm in co-operation with USENIX) Message-ID: <200503111935.OAA95727@raptor.research.att.com> Call For Papers: Internet Measurement Conference 2005 October 19-21 2005, New Orleans, Louisiana, USA The 2005 Internet Measurement Conference (IMC 2005) is a two and one-half day event focusing on Internet measurement and analysis, following on the success of four previous IMCs (http://www.imconf.net). We welcome the submission of papers that contribute to our understanding of how to collect or analyze Internet measurements, or give insight into how the Internet behaves. More generally, measurement-based studies of IP-based networks and network technologies are of interest. Examples of relevant topics include measurement-based studies of: * Network structure and topology * Traffic analysis * Traffic engineering * Inter-domain and intra-domain routing * Intra-domain IP-based networks such as enterprise networks and campus networks * Network inference and anomaly detection * Network applications, including Web, multimedia streaming, and gaming * CDN, peer-to-peer, and overlay networks * Wireless LAN and WANs, and sensor networks as they relate to TCP/IP protocols and applications * Network modeling * Network security threats and countermeasures * Data-centric issues, including anonymization, querying, and storage * Software tools and systems in support of network measurement * Reappraisal of previous measurement findings Papers that do not in some fashion rely on measuring properties of IP networks are out of scope. Authors can contact the Program Co-Chairs at imc05chairs at usenix.org for clarification if they are unsure whether their paper is in scope. Submission Guidelines There are two forms of submissions: 1. Full papers (up to 14 two-column pages) describing original research, with succinctness appropriate to the topics and themes they discuss. 2. Short papers (up to 6 two-column pages), conveying, for example, work that is less mature but shows promise. Short papers will be subject to a 6-page limit in the Proceedings. Submissions must be in electronic form, as Postscript or PDF documents. The submission must conform to the page limits stated above, and the main text body must be written in a 10-point (or larger) serif font. All manuscripts must be in English. Submissions that do not comply with these requirements will not be read. Detailed submission instructions will be available in April 2005 at http://www.usenix.org/events/imc05/cfp All full papers and short papers accepted for presentation will be published in the Conference Proceedings produced by USENIX. A few accepted papers may be forwarded for fast-track submission to the IEEE/ACM Transactions on Networking. Sponsored by ACM SIGCOMM in cooperation with USENIX Important Dates Registration of paper title and 250-word abstract due: May 6, 2005 Full papers due: May 13, 2005 (Hard Deadline) Notification of acceptance: July 15, 2005 Camera-ready final papers due: August 10, 2005 Program Co-Chairs: Venkat Padmanabhan, Microsoft Research, USA Darryl Veitch, University of Melbourne, Australia Program Committee: Sharad Agarwal, Microsoft Research, USA Jussara Almeida, Federal University of Minas Gerais, Brazil Chadi Barakat, INRIA, France Paul Barford, University of Wisconsin, USA Supratik Bhattacharyya, Sprint Labs, USA Mark Claypool, Worcester Polytechnic Institute, USA Constantinos Dovrolis, Georgia Institute of Technology, USA Steven Gribble, University of Washington, USA Timothy Griffin, University of Cambridge, UK Jasleen Kaur, University of North Carolina, Chapel Hill, USA Balachander Krishnamurthy, AT&T Labs--Research, USA Craig Labovitz, Arbor Networks, USA Bruce Maggs, Carnegie Mellon University and Akamai, USA David Moore, CAIDA and University of California at San Diego, USA Dina Papagiannaki, Intel Research, UK Rajeev Rastogi, Bell Labs, India Jennifer Rexford, Princeton University, USA Keith Ross, Polytechnic University, USA Matthew Roughan, University of Adelaide, Australia Neil Spring, University of Maryland, USA Carey Williamson, University of Calgary, Canada Walter Willinger, AT&T Labs--Research, USA Lixia Zhang, University of California at Los Angeles, USA Yin Zhang, University of Texas at Austin, USA Local Arrangements Chair: Albert Greenberg, AT&T Labs--Research, USA Steering Committee: Mark Crovella, Boston University, USA Balachander Krishnamurthy, AT&T Labs--Research, USA Bruce Maggs, Carnegie Mellon University and Akamai, USA Nina Taft, Intel Research Berkeley, USA From jag8719 at vip.sina.com Mon Mar 14 02:23:39 2005 From: jag8719 at vip.sina.com (Jason Gao) Date: Mon, 14 Mar 2005 18:23:39 +0800 Subject: [e2e] Introduction to ATP Message-ID: <200503141020.j2EAKA625402@boreas.isi.edu> Here ATP stands for Asymmetric Transport Protocol (somewhat for historical reason), not Appletalk Transaction Protocol. Welcome to http://atp.ebloggy.com/ to add comment. Known problems: Lack of references section; Lack of elliptic curve parameter definition; and much more:) Briefly: ATP aims to provide mobility and multi-home support in transport layer. But why not patching TCP, extending SCTP, or exploiting HIP? The answer is that when taking account of syndicate effect, it is more efficient to use ATP. Patching TCP software to support mobility and multi-home is not difficult. But widely deploying the new TCP implementation may be an enduring work. SCTP supports multi-home, and it is quite easy to extend it to support mobility. But as SCTP is already quite heavy weighted, and its congestion control mechanism arguably suffers same trouble as TCP, it is difficulty to persuade mass users to accept SCTP. HIP decouples identity and locator role of IP address by adding a new layer. It is quite exquisite. But unfortunately to add a new layer is to add a new, non-trivial trouble of reliability. The name of Asymmetric Transport Protocol is somewhat historical. ATP takes advantages of asymmetric cryptography (and asymmetry of communication). It is designed to be an alternate of transport layer protocols, alongside of TCP and UDP [RFC768]. ATP aims to ? Decouple locator and identity role of network layer address by keep it from taking part in transport layer identity and/or address. ? Support mobility ? Support multi-home ? Facilitate high performance parallel communication ? Facilitate high efficiency transactional communication ? Provide transport encryption service ? Provide some QoS service ? Keep simple ATP supports mobility and multi-home by decoupling locator and identity role of network layer address with connection key. There are three connection modes in ATP: fast-mode, normal mode and encrypted transport mode. In the host environment, each ATP connection is uniquely associated with a 64-bit connection key. In the context of each normal mode ATP connection, there is a shared secret. The shared secret is established in Elliptic Curve Diffie-Hellman [ECC] key agreement process when the connection is set up. ATP endpoint seals every ATP packet with Integrity/Identity Check Code (ICC). In normal mode ICC is calculated by applying HMAC-SHA1 [RFC2104] [RFC3174] on the ATP packet header with the shared secret as the key. As far as only the connected peers know both the connection key and the shared secret, integrity of the ATP packet header and identity of the ATP packet source are secured by ICC. In fast mode, ATP endpoints do not establish a shared secret, and agree on the connection key only. The 64-bit connection key solely acts the identity check role. ICC is a CCITT-CRC-16 code [CRC] that weakly protects packet integrity. In encrypted transport mode ATP endpoints use AES-IV-SHA1-80 algorithm to protect privacy of the payload, integrity of the full packet, and identity of the packet source. AES-IV-SHA1-80 algorithm is integration of AES [FIPS-197] and SHA1-80 [RFC3174]. AES encryption key is installed by the upper layer application (ULA), or derived from the shared secret on request of ULA; 64-bit initial vector is the low-order 64-bit part of the result of applying SHA1-80 on the ATP packet header. High-order 16 bits are exploited for preliminary integrity check. Encrypted transport mode is not only a feature of mobility and multi-home but a simple and useful feature of security as well. Mobility support is further reinforced by the feature of re-locating via courier. ATP supports high performance, high efficiency parallel and/or transactional communication with connection clone and auto-reconnect features. ATP also features First-In-First-Deplete traffic class, in addition to traditional best-effort traffic class. ATP DOES NOT provide reliable multicast support, nor does it do full-fledged congestion control. However, ATP does have cooperative congestion control feature. We assume that ? Mobility context is L4-comfortable. That is, frequency of IP address change is limited so that the IP addresses of two endpoints remain stable as long as they are negotiating a connection. ? Ownership of upper layer application over connection key is secure. ? Upper Layer Application is willing and able to defense against man-in-the-middle attack. ? Acceptable information asymmetry. One participant in communication, the responder, is willing to and able to make the other participant, the initiator, know the rendezvous key, but not necessarily vice versa. From lars-erik.jonsson at ericsson.com Mon Mar 14 02:59:56 2005 From: lars-erik.jonsson at ericsson.com (Lars-Erik Jonsson (LU/EAB)) Date: Mon, 14 Mar 2005 11:59:56 +0100 Subject: [e2e] Skype and congestion collapse. Message-ID: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> > And, just think, every Cisco VoIP switch has to have a > fixed geographical location and a POTS line, if its > users want to have a 911 call ... And who said the user wanted his Voice application to be an emergency line, and pay for the cost of that? /L-E From lars.eggert at netlab.nec.de Mon Mar 14 03:54:53 2005 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Mon, 14 Mar 2005 12:54:53 +0100 Subject: [e2e] Introduction to ATP In-Reply-To: <200503141020.j2EAKA625402@boreas.isi.edu> References: <200503141020.j2EAKA625402@boreas.isi.edu> Message-ID: <42357B8D.9020902@netlab.nec.de> Jason Gao wrote: > Here ATP stands for Asymmetric Transport Protocol (somewhat for historical > reason), not Appletalk Transaction Protocol. > > Welcome to http://atp.ebloggy.com/ to add comment. Is there a paper on it? The web page and your email don't have details. -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3360 bytes Desc: S/MIME Cryptographic Signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050314/1f51297e/smime.bin From fla at inescporto.pt Mon Mar 14 05:09:44 2005 From: fla at inescporto.pt (Filipe Abrantes) Date: Mon, 14 Mar 2005 13:09:44 +0000 Subject: [e2e] Introduction to ATP In-Reply-To: <42357B8D.9020902@netlab.nec.de> References: <200503141020.j2EAKA625402@boreas.isi.edu> <42357B8D.9020902@netlab.nec.de> Message-ID: <42358D18.8040108@inescporto.pt> Lars Eggert wrote: > Jason Gao wrote: > >> Here ATP stands for Asymmetric Transport Protocol (somewhat for >> historical >> reason), not Appletalk Transaction Protocol. >> >> Welcome to http://atp.ebloggy.com/ to add comment. > > > Is there a paper on it? The web page and your email don't have details. > Have you tried the "Pages" links (2nd block down on the left on the webpage), however a paper or a draft would be a better reading. Best Regards Filipe A. -- Filipe Lameiro Abrantes INESC Porto Campus da FEUP Rua Dr. Roberto Frias, 378 4200-465 Porto Portugal Phone: +351 22 209 4266 E-mail: fla at inescporto.pt From cannara at attglobal.net Mon Mar 14 13:58:33 2005 From: cannara at attglobal.net (Alex Cannara) Date: Mon, 14 Mar 2005 13:58:33 -0800 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> References: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> Message-ID: <42360909.6090509@attglobal.net> Ok Lars, rely on telepathy when your boss falls down the stairs, or your wife starts delivering while visiting your office, both during a power outage. Yeah, try that! :] Alex Lars-Erik Jonsson (LU/EAB) wrote: >>And, just think, every Cisco VoIP switch has to have a >>fixed geographical location and a POTS line, if its >>users want to have a 911 call ... > > > And who said the user wanted his Voice application to > be an emergency line, and pay for the cost of that? > > /L-E > From jag8719 at vip.sina.com Mon Mar 14 16:41:51 2005 From: jag8719 at vip.sina.com (Jason Gao) Date: Tue, 15 Mar 2005 08:41:51 +0800 Subject: [e2e] Introduction to ATP In-Reply-To: <42357B8D.9020902@netlab.nec.de> Message-ID: <200503150036.j2F0aM622287@boreas.isi.edu> Sorry, there isn't any paper on it yet. I think I should write a paper in a few weeks. Anyway, it is just a paper design with many open issues, such as quantitive comparison with TCP, SCTP and so on. -----ÓʼþÔ­¼þ----- ·¢¼þÈË: Lars Eggert [mailto:lars.eggert at netlab.nec.de] ·¢ËÍʱ¼ä: 2005Äê3ÔÂ14ÈÕ 19:55 ÊÕ¼þÈË: Jason Gao ³­ËÍ: end2end-interest at postel.org; ietf at ietf.org Ö÷Ìâ: Re: [e2e] Introduction to ATP Jason Gao wrote: > Here ATP stands for Asymmetric Transport Protocol (somewhat for > historical reason), not Appletalk Transaction Protocol. > > Welcome to http://atp.ebloggy.com/ to add comment. Is there a paper on it? The web page and your email don't have details. -- Lars Eggert NEC Network Laboratories From lars-erik.jonsson at ericsson.com Tue Mar 15 00:23:50 2005 From: lars-erik.jonsson at ericsson.com (Lars-Erik Jonsson (LU/EAB)) Date: Tue, 15 Mar 2005 11:23:50 +0300 Subject: [e2e] Skype and congestion collapse. Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2715@esealmw109.eemea.ericsson.se> Alex, People love Skype and other IP applications because they do not have to pay for things they did not ask for. VoIP is not POTS, and by using VoIP the user can choose what kind of voice application he wants to use, instead of being forced to pay for a complex solution with "features" he did not ask for. Consider the following text from the Skype end user license agreement: "No Emergency Calls: by entering into this Agreement You acknowledge and agree that the Skype Software does not and does not intend to support or carry emergency calls." To me, this is a very positive thing, as I know how complicated and thus expensive it (by nature) is to promise anything else, and I am not willing to pay for that. To some players on the market, it is of course a threat that people now have the freedom to choose, and that can cause panic in the walled gardens. But personally I think this is good for communications, and also for the communications industry (at least for those who see opportunities instead of threats). Cheers, /L-E > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org]On Behalf Of Alex Cannara > Sent: den 14 mars 2005 22:59 > To: end2end-interest at postel.org > Subject: Re: [e2e] Skype and congestion collapse. > > > Ok Lars, rely on telepathy when your boss falls down the > stairs, or your wife > starts delivering while visiting your office, both during a > power outage. > Yeah, try that! :] > > Alex > > Lars-Erik Jonsson (LU/EAB) wrote: > > >>And, just think, every Cisco VoIP switch has to have a > >>fixed geographical location and a POTS line, if its > >>users want to have a 911 call ... > > > > > > And who said the user wanted his Voice application to > > be an emergency line, and pay for the cost of that? > > > > /L-E > > > > > > > > From hannes.tschofenig at siemens.com Tue Mar 15 02:01:41 2005 From: hannes.tschofenig at siemens.com (Tschofenig Hannes) Date: Tue, 15 Mar 2005 11:01:41 +0100 Subject: [e2e] Skype and congestion collapse. Message-ID: i hope that we will be able to develop building blocks for an emergency solution which will also work in a p2p alike environment. a certain degree of infrastructure support will be required but i am not sure if this is truely the "complex solution" you have in mind. > -----Urspr?ngliche Nachricht----- > Von: Lars-Erik Jonsson (LU/EAB) > [mailto:lars-erik.jonsson at ericsson.com] > Gesendet: Dienstag, 15. M?rz 2005 02:24 > An: Alex Cannara; end2end-interest at postel.org > Betreff: Re: [e2e] Skype and congestion collapse. > > > Alex, > > People love Skype and other IP applications because > they do not have to pay for things they did not ask > for. VoIP is not POTS, and by using VoIP the user > can choose what kind of voice application he wants > to use, instead of being forced to pay for a complex > solution with "features" he did not ask for. > > Consider the following text from the Skype end user > license agreement: > "No Emergency Calls: by entering into this Agreement > You acknowledge and agree that the Skype Software > does not and does not intend to support or carry > emergency calls." > To me, this is a very positive thing, as I know how > complicated and thus expensive it (by nature) is to > promise anything else, and I am not willing to pay > for that. > > To some players on the market, it is of course a > threat that people now have the freedom to choose, > and that can cause panic in the walled gardens. But > personally I think this is good for communications, > and also for the communications industry (at least > for those who see opportunities instead of threats). > > Cheers, > /L-E > > > > -----Original Message----- > > From: end2end-interest-bounces at postel.org > > [mailto:end2end-interest-bounces at postel.org]On Behalf Of > Alex Cannara > > Sent: den 14 mars 2005 22:59 > > To: end2end-interest at postel.org > > Subject: Re: [e2e] Skype and congestion collapse. > > > > > > Ok Lars, rely on telepathy when your boss falls down the > > stairs, or your wife > > starts delivering while visiting your office, both during a > > power outage. > > Yeah, try that! :] > > > > Alex > > > > Lars-Erik Jonsson (LU/EAB) wrote: > > > > >>And, just think, every Cisco VoIP switch has to have a > > >>fixed geographical location and a POTS line, if its > > >>users want to have a 911 call ... > > > > > > > > > And who said the user wanted his Voice application to > > > be an emergency line, and pay for the cost of that? > > > > > > /L-E > > > > > > > > > > > > > > > > From gaylord at dirtcheapemail.com Tue Mar 15 02:24:05 2005 From: gaylord at dirtcheapemail.com (Clark Gaylord) Date: Tue, 15 Mar 2005 05:24:05 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <42360909.6090509@attglobal.net> References: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> <42360909.6090509@attglobal.net> Message-ID: <4236B7C5.1080209@dirtcheapemail.com> Alex Cannara wrote: > Ok Lars, rely on telepathy when your boss falls down the stairs, or > your wife > starts delivering while visiting your office, both during a power > outage. Yeah, try that! :] why? they'll each have their cell phones. as much as i hate to see it happen, the mobile communications device has made 911 hand-wringing of internet telephony largely irrelevant. people are safer with cell phones than land line. period. it has nothing to do with the reliability of cell phones; it has to do with their availability. the stairwell probably doesn't have a phone, but my boss does. Convenience is seldom a factor in emergency location. --ckg From jag8719 at vip.sina.com Tue Mar 15 03:18:34 2005 From: jag8719 at vip.sina.com (Jason Gao) Date: Tue, 15 Mar 2005 19:18:34 +0800 Subject: [e2e] Introduction to ATP In-Reply-To: <02aa01c528f6$81091890$750016ac@ssprunk> Message-ID: <200503151114.j2FBEw608903@boreas.isi.edu> > -----????----- > ???: Stephen Sprunk [mailto:stephen at sprunk.org] > ????: 2005?3?15? 8:30 > ???: Jason Gao; end2end-interest at postel.org > ??: Re: Introduction to ATP > > Thus spake "Jason Gao" > > Patching TCP software to support mobility and multi-home is > not difficult. > > But widely deploying the new TCP implementation may be an > enduring work. > ... > > SCTP supports multi-home, and it is quite easy to extend it > to support > > mobility. But as SCTP is already quite heavy weighted, and its > > congestion control mechanism arguably suffers same trouble > as TCP, it > > is difficulty > to > > persuade mass users to accept SCTP. > ... > > The name of Asymmetric Transport Protocol is somewhat historical. > > ATP takes advantages of asymmetric cryptography (and asymmetry of > > communication). It is designed to be an alternate of > transport layer > > protocols, alongside of TCP and UDP [RFC768]. > > I fail to see how ATP, as a new transport protocol, is any > more likely to be implemented in a critical mass of > end-systems than, say, SCTP or an improved TCP. It's the > same problem. > > > There are three connection modes in ATP: fast-mode, normal mode and > > encrypted transport mode. In the host environment, each ATP > connection > > is uniquely associated with a 64-bit connection key. > > Why 64 bits? If you used 128-256 bits, that gives you enough > entropy to derive an encryption key directly. If you're not > using it for that, then surely a 32-bit connection ID would suffice. > Well, it is a trade-off. 64 bits can be be split into two 32 bits. The two 32 bit words can be embedded in the interface ID fields of the source and destiantion IPv6 address, respectively. > > In the context of each normal mode ATP connection, there is > a shared > > secret. The shared secret is established in Elliptic Curve > > Diffie-Hellman [ECC] key agreement process when the > connection is set up. > > I'm not familiar with ECDH; does it protect against > Man-In-The-Middle attacks? I don't see how you'll get around > that without a PKI or pre-existing shared secrets -- one > doesn't exist yet and the other doesn't scale to real usage. > We assume that ... ? Upper Layer Application is willing and able to defense against man-in-the-middle attack. ... Say, taking use of SRP. > > ATP endpoint seals every ATP packet with Integrity/Identity > Check Code > > (ICC). In normal mode ICC is calculated by applying HMAC-SHA1 > > [RFC2104] [RFC3174] on the ATP packet header with the > shared secret as > > the key. > > Why not on the payload as well? Once you've incurred the > cost (and legal > problems) of requiring crypto, doing the payload too is minor. > Oh thanks! That's a mistake when I wrote the introduction. In section 3.4, ICC and packet legitimacy, I mention that the 80-bit ICC in normal mode is actually split into a 16-bit CRC part and a 64-bit SHA1 part. The CRC part cover the full payload while the SHA1 part cover the header. It's intended to give some possiblity of parallel processing. > > As far as only the connected peers know both the connection key and > > the shared secret, integrity of the ATP packet header and > identity of > > the ATP packet source are secured by ICC. > > Is this meant to imply that if the connection key were > discovered but not the shared secret, the ICC would be > broken? That would mean you really have two secrets to > protect -- why not just one? > I mean if the connection key were discovered - that's easy - but not the shared secret, possibility of undetected modification of the payload or the ATP header is so low that integrity and identity can be considered being secured. > > In fast mode, ATP endpoints do not establish a shared secret, and > > agree on the connection key only. The 64-bit connection key solely > > acts the identity check role. ICC is a CCITT-CRC-16 code [CRC] that > > weakly protects packet integrity. > > So "fast mode" is really "weak mode"? > > How does the connection key factor into the CRC16 algorithm? > How can you prevent the key from being recovered since CRC16 > is easily reversible when the plaintext is available? I'd > hope that "weak mode" is optional for implementations. > That's another trade-off. In very high speed computation situations where multi-home (or multi-path) is welcomed, and the networks are physical secured, say, full-optical networks, unnecessary transport layer security may be unwelcomed. > > In encrypted transport mode ATP endpoints use > AES-IV-SHA1-80 algorithm > > to protect privacy of the payload, integrity of the full > packet, and > > identity of the packet source. AES-IV-SHA1-80 algorithm is > integration > > of AES [FIPS-197] and SHA1-80 [RFC3174]. > > SHA1-80 would seem to be woefully underpowered. Even > SHA1-160 only requires > 2^51 (IIRC) work to find collisions after recent revelations; > SHA1-80 is theoretically breakable with anything more > powerful than a four-function calculator. > > Why not use the NIST-approved Counter Mode, which was > specifically designed for packet switching applications? > Reinventing the wheel is very dangerous in the crypto world. > Trying to combine integrity and encryption into a single > operation is also difficult and fraught with mistakes; take a > look at the proposed OCB mode for one way to do it right. > > > AES encryption key is installed by the upper layer > application (ULA), > > or derived from the shared secret on request of ULA; 64-bit initial > > vector is the low-order 64-bit part of the result of > applying SHA1-80 > > on the ATP packet header. High-order 16 bits are exploited for > > preliminary integrity check. Encrypted transport mode is not only a > > feature of mobility and multi-home but a simple and useful > feature of > > security as well. > > You're using a 64-bit IV for a 128/192/256-bit block cipher? > An ATP endpoint does not really need to know the real identity of the remote endpoint. It just want to be sure that the successive packets come from the same source. In encrypted transport mode AES key is not derived from SHA1-80 of something. It is installed by the upper layer application or derived from the shared secret which is (at least 283 bits [SECT283K1]. As to the initial vector, 64-bit is only the half of the AES block size, but I don't think it break AES if we do padding right. Anyway, it is just a (pseudo-)random salt. Best regards, Jason. From lars-erik.jonsson at ericsson.com Tue Mar 15 05:10:34 2005 From: lars-erik.jonsson at ericsson.com (Lars-Erik Jonsson (LU/EAB)) Date: Tue, 15 Mar 2005 16:10:34 +0300 Subject: [e2e] Skype and congestion collapse. Message-ID: <026F8EEDAD2C4342A993203088C1FC051C2719@esealmw109.eemea.ericsson.se> Sure, of course there are good reasons to have communication means that are more reliable than others. However, it is not at all obvious that an application for conversational voice is a good choice if you want to create an emergency solution, i.e. an "almost always working" solution, as conversational voice is rather demanding in terms of delay. Remember there is no way to ensure something will *always* work, it is just a matter of more and less reliability, and extreme reliability is costly. I party agree with you, but I do not think it is about "an" emergency solution, but rather to enhance the possibilities to increase reliability end2end, and thus create a basis for emergency communications. But main point being, VoIP can be so much, and in most cases I believe it is very different from what POTS has been about. The good thing from a user point of view is that users now have a chance to choose application based on own preferences, and not pay for more than is actually desired. /L-E > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig at siemens.com] > Sent: den 15 mars 2005 11:02 > To: end2end-interest at postel.org; Lars-Erik Jonsson (LU/EAB); > cannara at attglobal.net > Subject: AW: [e2e] Skype and congestion collapse. > > > i hope that we will be able to develop building blocks for > an emergency solution which will also work in a p2p alike > environment. a certain degree of infrastructure support > will be required but i am not sure if this is truely the > "complex solution" you have in mind. From Jim.Gettys at hp.com Tue Mar 15 08:18:06 2005 From: Jim.Gettys at hp.com (Jim Gettys) Date: Tue, 15 Mar 2005 11:18:06 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <4236B7C5.1080209@dirtcheapemail.com> References: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> <42360909.6090509@attglobal.net> <4236B7C5.1080209@dirtcheapemail.com> Message-ID: <1110903486.5338.24.camel@localhost.localdomain> Yup. I wish I'd had my cell phone with me the day I fell down a mountain side and broke my ankle... Instead, I had to drag myself back to my cabin and call a neighbor for help (faster than calling 911 when you are in the boonies to get local help to take you to the hospital). Most of us now have wireless in addition to conventional phone. When I've chatted with my wife about cutting over entirely to VOIP, her concern has been with the baby sitters getting help dispatched. So as soon as my VOIP carrier can report location for me (any time now, according to their web site), my POTS line likely goes bye-bye. POTS only service providers should be afraid, very afraid... - Jim On Tue, 2005-03-15 at 05:24 -0500, Clark Gaylord wrote: > Alex Cannara wrote: > > > Ok Lars, rely on telepathy when your boss falls down the stairs, or > > your wife > > starts delivering while visiting your office, both during a power > > outage. Yeah, try that! :] > > why? they'll each have their cell phones. > > as much as i hate to see it happen, the mobile communications device has > made 911 hand-wringing of internet telephony largely irrelevant. people > are safer with cell phones than land line. period. it has nothing to do > with the reliability of cell phones; it has to do with their > availability. the stairwell probably doesn't have a phone, but my boss does. > > Convenience is seldom a factor in emergency location. > > --ckg From cannara at attglobal.net Tue Mar 15 09:09:07 2005 From: cannara at attglobal.net (Cannara) Date: Tue, 15 Mar 2005 09:09:07 -0800 Subject: [e2e] Skype and congestion collapse. References: Message-ID: <423716B3.37376B5@attglobal.net> I've no quibble with that logic at all. I'm just pointing out that the hype from vendors of VoIP has often covered up very important features of the wired infrastructure that we've had for over 100 years -- 911, independent power, etc. Buffer transfer by packets allows any app to be done over any network, so Skype, or any networked app that's existed for a couple of decades now, already demonstrated the possibilities of cheap packet intercommunication. A local university received the full-court press to go to VoIP from a renowned vendor and fortunately made a better informed, less restrictive choice. We have to remember that things like Skype are effective, cool and cute, but in real environments, limited effectiveness isn't enough and legal issues, in fact, arise on what services must be provided. That's really what I'm raising -- there's nothing much new about Skype, or any other popularly- available networked app, except that now everyone has personal computers, PDAs, iPods, yadda, yadda, most with roaming wireless capability. Heck, I wrote an email program in BTI Basic that ran for a whole year among 10 schools here, in 1977. Not a single msg lost. :] Alex Tschofenig Hannes wrote: > > i hope that we will be able to develop building blocks for an emergency > solution that also work in a p2p alike environment. > > > -----Urspr?ngliche Nachricht----- > > Von: Lars-Erik Jonsson (LU/EAB) > > [mailto:lars-erik.jonsson at ericsson.com] > > Gesendet: Dienstag, 15. M?rz 2005 02:24 > > An: Alex Cannara; end2end-interest at postel.org > > Betreff: Re: [e2e] Skype and congestion collapse. > > > > > > Alex, > > > > People love Skype and other IP applications because > > they do not have to pay for things they did not ask > > for. VoIP is not POTS, and by using VoIP the user > > can choose what kind of voice application he wants > > to use, instead of being forced to pay for a complex > > solution with "features" he did not ask for. > > > > Consider the following text from the Skype end user > > license agreement: > > "No Emergency Calls: by entering into this Agreement > > You acknowledge and agree that the Skype Software > > does not and does not intend to support or carry > > emergency calls." > > To me, this is a very positive thing, as I know how > > complicated and thus expensive it (by nature) is to > > promise anything else, and I am not willing to pay > > for that. > > > > To some players on the market, it is of course a > > threat that people now have the freedom to choose, > > and that can cause panic in the walled gardens. But > > personally I think this is good for communications, > > and also for the communications industry (at least > > for those who see opportunities instead of threats). > > > > Cheers, > > /L-E > > > > > > > -----Original Message----- > > > From: end2end-interest-bounces at postel.org > > > [mailto:end2end-interest-bounces at postel.org]On Behalf Of > > Alex Cannara > > > Sent: den 14 mars 2005 22:59 > > > To: end2end-interest at postel.org > > > Subject: Re: [e2e] Skype and congestion collapse. > > > > > > > > > Ok Lars, rely on telepathy when your boss falls down the > > > stairs, or your wife > > > starts delivering while visiting your office, both during a > > > power outage. > > > Yeah, try that! :] > > > > > > Alex > > > > > > Lars-Erik Jonsson (LU/EAB) wrote: > > > > > > >>And, just think, every Cisco VoIP switch has to have a > > > >>fixed geographical location and a POTS line, if its > > > >>users want to have a 911 call ... > > > > > > > > > > > > And who said the user wanted his Voice application to > > > > be an emergency line, and pay for the cost of that? > > > > > > > > /L-E From cannara at attglobal.net Tue Mar 15 09:16:08 2005 From: cannara at attglobal.net (Cannara) Date: Tue, 15 Mar 2005 09:16:08 -0800 Subject: [e2e] Skype and congestion collapse. References: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> <42360909.6090509@attglobal.net> <4236B7C5.1080209@dirtcheapemail.com> <1110903486.5338.24.camel@localhost.localdomain> Message-ID: <42371858.128722F0@attglobal.net> As I alluded to in another msg, it's not the POTs folks that we're after here. They're doing fine, merging & offering services of all sort now. And, remember how cell towers intercommunicate your 'wireless' call? Of course, that's if your cell battery was charged up and not affected by the distance from a tower and the extreme cold up on Mt. Washington. :] This isn't about cell phones anyway, right gang? Alex Jim Gettys wrote: > > Yup. I wish I'd had my cell phone with me the day I fell down a > mountain side and broke my ankle... Instead, I had to drag myself back > to my cabin and call a neighbor for help (faster than calling 911 when > you are in the boonies to get local help to take you to the hospital). > > Most of us now have wireless in addition to conventional phone. When > I've chatted with my wife about cutting over entirely to VOIP, her > concern has been with the baby sitters getting help dispatched. > > So as soon as my VOIP carrier can report location for me (any time now, > according to their web site), my POTS line likely goes bye-bye. > > POTS only service providers should be afraid, very afraid... > - Jim > > On Tue, 2005-03-15 at 05:24 -0500, Clark Gaylord wrote: > > Alex Cannara wrote: > > > > > Ok Lars, rely on telepathy when your boss falls down the stairs, or > > > your wife > > > starts delivering while visiting your office, both during a power > > > outage. Yeah, try that! :] > > > > why? they'll each have their cell phones. > > > > as much as i hate to see it happen, the mobile communications device has > > made 911 hand-wringing of internet telephony largely irrelevant. people > > are safer with cell phones than land line. period. it has nothing to do > > with the reliability of cell phones; it has to do with their > > availability. the stairwell probably doesn't have a phone, but my boss does. > > > > Convenience is seldom a factor in emergency location. > > > > --ckg From algold at rnp.br Tue Mar 15 10:28:06 2005 From: algold at rnp.br (Alexandre L. Grojsgold) Date: Tue, 15 Mar 2005 15:28:06 -0300 (E. South America Standard Time) Subject: [e2e] Skype and congestion collapse. In-Reply-To: <42371858.128722F0@attglobal.net> References: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> <42360909.6090509@attglobal.net> <4236B7C5.1080209@dirtcheapemail.com> <1110903486.5338.24.camel@localhost.localdomain> <42371858.128722F0@attglobal.net> Message-ID: Hi, Since this thread came a discussion about VoIP, in general, I will dare asking people of the list if you have a good paper/article on ENUM. Sure, Google points me to a lot of quite insipid articles, that don?t give me the opinion I am looking for. Thanks, Alexandre. From touch at ISI.EDU Fri Mar 18 13:10:41 2005 From: touch at ISI.EDU (Joe Touch) Date: Fri, 18 Mar 2005 13:10:41 -0800 Subject: [e2e] Introduction to ATP In-Reply-To: <200503150036.j2F0aM622287@boreas.isi.edu> References: <200503150036.j2F0aM622287@boreas.isi.edu> Message-ID: <423B43D1.8010700@isi.edu> Jason Gao wrote: > Sorry, there isn't any paper on it yet. I think I should write a paper in a > few weeks. > Anyway, it is just a paper design with many open issues, such as quantitive > comparison with TCP, SCTP and so on. What is a "paper design" without even a paper? What is it that is being announced or introduced? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20050318/3e13cef8/signature.bin From cannara at attglobal.net Tue Mar 22 16:07:08 2005 From: cannara at attglobal.net (Cannara) Date: Tue, 22 Mar 2005 16:07:08 -0800 Subject: [e2e] Skype and congestion collapse. References: Message-ID: <4240B32C.E52DB67F@attglobal.net> Just an FYI on some of the next Internet 'just-enough-design'-enabled scams... http://story.news.yahoo.com/news?tmpl=story&cid=581&e=1&u=/nm/20050320/tc_nm/columns_pluggedin_dc Alex From falk at ISI.EDU Tue Mar 22 17:14:51 2005 From: falk at ISI.EDU (Aaron Falk) Date: Tue, 22 Mar 2005 17:14:51 -0800 Subject: [e2e] New Mailing List: IRTF-Announce Message-ID: <20050323011450.GE5304@isi.edu> A new mailing list has been created to inform the Internet community of activities relating to the Internet Research Task Force. This broadcast list will receive notices of IRTF Research Group creation and termination, document publication, invitations for feedback and participation, and other IRTF activities. Subscription to this list is list is open to anyone. Posting to this list is at the discretion of the IRTF Chair. Subscription URL: https://www1.ietf.org/mailman/listinfo/irtf-announce Archive URL: http://www1.ietf.org/mail-archive/web/irtf-announce/current/index.html Please forward this notice to Internet research communities who might find it of interest. --Aaron IRTF Chair From bob at evdo-coverage.com Tue Mar 22 17:43:01 2005 From: bob at evdo-coverage.com (bob evdo hsdpa wimax guy) Date: Tue, 22 Mar 2005 17:43:01 -0800 Subject: [e2e] Skype and congestion collapse on wireless internet References: <4240B32C.E52DB67F@attglobal.net> Message-ID: <000901c52f49$a664f740$6501a8c0@XR10295> Alex... well.. every provider will do the least they can to make the most cash.. nothing surprising about that huh?? :o) X---------------- Robert Kim, Wireless Internet Wifi Hotspot Advisor http://wireless-internet-broadband-service.com https://evdo.sslpowered.com/wifi-hotspot-router.html http://evdo-coverage.com http://hsdpa-coverage.com 2611 S Pacific Coast Highway 101 ste 102 Cardiff by the Sea CA 92007 : 206 984 0880 >>> "Wireless Internet Service Is ONLY Broadband with Broadband Customer Service"(tm) >>> OUR QUEST: To Kill the Cubicle! (SM) ---Shalommmmmmmm-------------------- ---------------------------------;-)---- From cannara at attglobal.net Wed Mar 23 10:31:32 2005 From: cannara at attglobal.net (Cannara) Date: Wed, 23 Mar 2005 10:31:32 -0800 Subject: [e2e] Skype and congestion collapse on wireless internet References: <4240B32C.E52DB67F@attglobal.net> <000901c52f49$a664f740$6501a8c0@XR10295> Message-ID: <4241B604.AD713BD1@attglobal.net> Exactamundo! Prepare for monthly Verisign fees. :] Alex bob evdo hsdpa wimax guy wrote: > > Alex... well.. every provider will do the least they can to make the most > cash.. nothing surprising about that huh?? > > :o) > > X---------------- > Robert Kim, > Wireless Internet Wifi Hotspot Advisor > http://wireless-internet-broadband-service.com > https://evdo.sslpowered.com/wifi-hotspot-router.html > http://evdo-coverage.com http://hsdpa-coverage.com > 2611 S Pacific Coast Highway 101 ste 102 > Cardiff by the Sea CA 92007 : 206 984 0880 > > >>> "Wireless Internet Service Is ONLY Broadband with Broadband Customer > Service"(tm) > >>> OUR QUEST: To Kill the Cubicle! (SM) > ---Shalommmmmmmm-------------------- > ---------------------------------;-)---- From Peter.Sewell at cl.cam.ac.uk Thu Mar 24 10:23:31 2005 From: Peter.Sewell at cl.cam.ac.uk (Peter Sewell) Date: Thu, 24 Mar 2005 18:23:31 +0000 Subject: [e2e] Rigorous specification for TCP, UDP, and Sockets Message-ID: We would like to announce the technical reports TCP, UDP, and Sockets: rigorous and experimentally-validated behavioural specification. Volume 1: Overview UCAM-CL-TR-624 Volume 2: The Specification UCAM-CL-TR-625 and the summary paper Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and Sockets. available from . These give a detailed and precise specification of the behaviour of three common TCP/IP stacks - versions of FreeBSD, Linux, and Windows XP - as seen from socket calls and the wire interface. The specification has been validated through extensive testing (primarily against FreeBSD for the TCP aspects). It models the actual observed behaviour, bugs and all, rather than an idealisation of the RFCs. The specification is annotated for the non-specialist reader, and we hope that it will be useful as an informal reference for stack implementors and for sockets users (supplementing the existing RFCs and books), as well as supporting automated conformance testing. Our techniques may be useful in the development of new protocols and extensions. We would greatly appreciate feedback, on both content and usability. Peter, for the Netsem team: Steve Bishop, Matthew Fairbairn, Michael Norrish, Peter Sewell, Michael Smith, Keith Wansbrough %%%%%%%%%%%%%% Abstract We have developed a mathematically rigorous and experimentally-validated post-hoc specification of the behaviour of TCP, UDP, and the Sockets API. It characterises the API and network-interface interactions of a host, using operational semantics in the higher-order logic of the HOL automated proof assistant. The specification is detailed, covering almost all the information of the real-world communications: it is in terms of individual TCP segments and UDP datagrams, though it abstracts from the internals of IP. It has broad coverage, dealing with arbitrary API call sequences and incoming messages, not just some well-behaved usage. It is also accurate, closely based on the de facto standard of (three of) the widely-deployed implementations. To ensure this we have adopted a novel experimental semantics approach, developing test generation tools and symbolic higher-order-logic model checking techniques that let us validate the specification directly against several thousand traces captured from the implementations. The resulting specification, which is annotated for the non-HOL-specialist reader, may be useful as an informal reference for TCP/IP stack implementors and Sockets API users, supplementing the existing informal standards and texts. It can also provide a basis for high-fidelity automated testing of future implementations, and a basis for design and formal proof of higher-level communication layers. More generally, the work demonstrates that it is feasible to carry out similar rigorous specification work at design-time for new protocols. We discuss how such a design-for-test approach should influence protocol development, leading to protocol specifications that are both unambiguous and clear, and to high-quality implementations that can be tested directly against those specifications. Volume 1 gives an overview of the project, discussing the goals and techniques and giving an introduction to the specification. The specification itself is given in the companion Volume 2, which is automatically typeset from the (extensively annotated) HOL source. As far as possible we have tried to make the work accessible to four groups of intended readers: workers in networking (implementors of TCP/IP stacks, and designers of new protocols); in distributed systems (implementors of software above the Sockets API); in distributed algorithms (for whom this may make it possible to prove properties about executable implementations of those algorithms); and in semantics and automated reasoning. -- Peter Sewell University of Cambridge Computer Laboratory From Farooq.Bari at cingular.com Thu Mar 24 12:03:12 2005 From: Farooq.Bari at cingular.com (Bari, Farooq) Date: Thu, 24 Mar 2005 12:03:12 -0800 Subject: [e2e] UDP impact on TCP traffic Message-ID: Hi, Sorry for the spam. Can someone point me to any studies/papers/website discussing impact of UDP traffic on TCP sessions running in parallel (specially over wireless access ntwks). BR, Farooq From sudeepg at cse.iitb.ac.in Fri Mar 25 03:47:27 2005 From: sudeepg at cse.iitb.ac.in (Sudeep Goyal) Date: Fri, 25 Mar 2005 17:17:27 +0530 (IST) Subject: [e2e] UDP impact on TCP traffic In-Reply-To: References: Message-ID: Look at is webs-site. http://opalsoft.net/qos/Flows.htm Hope this helps. Sudeep On Thu, 24 Mar 2005, Bari, Farooq wrote: > Hi, > > Sorry for the spam. Can someone point me to any studies/papers/website > discussing impact of UDP traffic on TCP sessions running in parallel > (specially over wireless access ntwks). > > BR, > > Farooq > > -- From craig at aland.bbn.com Tue Mar 29 12:38:37 2005 From: craig at aland.bbn.com (Craig Partridge) Date: Tue, 29 Mar 2005 15:38:37 -0500 Subject: [e2e] E2E research visions Message-ID: <20050329203837.1AC9A24D@aland.bbn.com> Hi folks: At the most recent meeting of the End2End Research Group, the group, along with some attendees, had a discussion of possible research visions that could inspire innovative communications research over the next ten years or so. Dave Clark and I, with help from several other participants in the discussion, have written up the ideas from that discussion and a copy is available on my website http://www.ir.bbn.com/~craig/e2e-vision.pdf for anyone who is interested. Craig E-mail: craig at aland.bbn.com or craig at bbn.com From rony3000us at hotmail.com Thu Mar 31 00:17:19 2005 From: rony3000us at hotmail.com (Syed Faisal Hasan) Date: Thu, 31 Mar 2005 08:17:19 +0000 Subject: [e2e] TFRC vs UDP Message-ID: To whom it may concern, TFRC was designed for use by the Continuous Media (CM) applications. But why will a CM application which is performing well using UDP, use TFRC if there is performance gap (more latency, less number of packets transmitted in the same time, high rate fluctuations in the beginning) betwen UDP and TFRC ? May be thats the reason we haven't seen any applicatons using TFRC. On the other hand there is no (I haven't found) research which analyzes the performance difference between UDP and TFRC. It is clear that TFRC will not perform exactly like UDP ( due to TFRC's friendliness with TCP), but how much can we expect from TFRC? Faisal _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From gdc at iki.fi Thu Mar 31 05:03:43 2005 From: gdc at iki.fi (Dado Colussi) Date: Thu, 31 Mar 2005 16:03:43 +0300 Subject: [e2e] TFRC vs UDP In-Reply-To: References: Message-ID: <424BF52F.7090808@iki.fi> Syed Faisal Hasan wrote: > > To whom it may concern, > > TFRC was designed for use by the Continuous Media (CM) applications. But > why will a CM application which is performing well using UDP, use TFRC > if there is performance gap (more latency, less number of packets > transmitted in the same time, high rate fluctuations in the beginning) > betwen UDP and TFRC ? May be thats the reason we haven't seen any > applicatons using TFRC. On the other hand there is no (I haven't found) > research which analyzes the performance difference between UDP and TFRC. > It is clear that TFRC will not perform exactly like UDP ( due to TFRC's > friendliness with TCP), but how much can we expect from TFRC? Hi Syed, the motivation is that although your application would work fine and you (a single person in a society) would have a good welfare using UDP, it is your fellow citizens that would potentially suffer from your actions. The network resource should be distributed fairly - whatever it means. If we all started to disregard other users, the network might stop working properly - equivalent to anarchy in a society. Mechanisms are needed to guarantee fair distribution of the resource. TFRC attempts to provide mechanisms to distribute the bandwidth resource in the same way TCP does. I think performance issues depend more on competing TCP flows and the network than on the TFRC control algorithm. Cheers, Dado From rony3000us at hotmail.com Thu Mar 31 05:37:10 2005 From: rony3000us at hotmail.com (Syed Faisal Hasan) Date: Thu, 31 Mar 2005 13:37:10 +0000 Subject: [e2e] TFRC vs UDP In-Reply-To: <424BF52F.7090808@iki.fi> Message-ID: Hi Dado, >Syed Faisal Hasan wrote: >> >>To whom it may concern, >> >>TFRC was designed for use by the Continuous Media (CM) applications. But >>why will a CM application which is performing well using UDP, use TFRC if >>there is performance gap (more latency, less number of packets transmitted >>in the same time, high rate fluctuations in the beginning) betwen UDP and >>TFRC ? May be thats the reason we haven't seen any applicatons using TFRC. >>On the other hand there is no (I haven't found) research which analyzes >>the performance difference between UDP and TFRC. It is clear that TFRC >>will not perform exactly like UDP ( due to TFRC's friendliness with TCP), >>but how much can we expect from TFRC? > > >Hi Syed, > >the motivation is that although your application would work fine and you (a >single person in a society) would have a good welfare using UDP, it is your >fellow citizens that would potentially suffer from your actions. The >network resource should be distributed fairly - whatever it means. If we >all started to disregard other users, the network might stop working >properly - equivalent to anarchy in a society. Mechanisms are needed to >guarantee fair distribution of the resource. TFRC attempts to provide >mechanisms to distribute the bandwidth resource in the same way TCP does. > >I think performance issues depend more on competing TCP flows and the >network than on the TFRC control algorithm. I understand what you are talking about. But I want to know the performance difference of UDP and TFRC in the same scenario. Is there any published research on this? Faisal _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From fla at inescporto.pt Thu Mar 31 07:44:43 2005 From: fla at inescporto.pt (Filipe Abrantes) Date: Thu, 31 Mar 2005 16:44:43 +0100 Subject: [e2e] TFRC vs UDP In-Reply-To: References: Message-ID: <424C1AEB.1070401@inescporto.pt> Hello Syed Faisal, TFRC, unlike UDP, may restrain the rate of the CM application, which may in a lower rate for that application. However, the TFRC mechanism is able to inform the application about the network state (bandwidth, rtt), which it can use to choose the more appropriate codec and switch codecs during a connection if network conditions change. Estimating network conditions can also be done by the application when using UDP, however using a TFRC-enabled protocol (DCCP) provides an automated unified way of doing this to everyone. Regards, Filipe A. Syed Faisal Hasan wrote: > > To whom it may concern, > > TFRC was designed for use by the Continuous Media (CM) applications. But > why will a CM application which is performing well using UDP, use TFRC > if there is performance gap (more latency, less number of packets > transmitted in the same time, high rate fluctuations in the beginning) > betwen UDP and TFRC ? May be thats the reason we haven't seen any > applicatons using TFRC. On the other hand there is no (I haven't found) > research which analyzes the performance difference between UDP and TFRC. > It is clear that TFRC will not perform exactly like UDP ( due to TFRC's > friendliness with TCP), but how much can we expect from TFRC? > > Faisal > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > -- Filipe Lameiro Abrantes INESC Porto Campus da FEUP Rua Dr. Roberto Frias, 378 4200-465 Porto Portugal Phone: +351 22 209 4266 E-mail: fla at inescporto.pt From dpreed at reed.com Thu Mar 31 08:43:52 2005 From: dpreed at reed.com (David P. Reed) Date: Thu, 31 Mar 2005 11:43:52 -0500 Subject: [e2e] TFRC vs UDP In-Reply-To: References: Message-ID: <424C28C8.70304@reed.com> Lots of continuous media apps use RTP, not raw UDP. Perhaps that's only a clarification to your question, but do note that RTP adds overhead too (if nothing but a packet header). In general, I think, people adopt standards because of two factors: 1) enhanced interoperability ... 2) not having to invent the wheel yet another time, when somebody has done a "good enough" answer, and might even have started a community of people to improve it. Syed Faisal Hasan wrote: > > To whom it may concern, > > TFRC was designed for use by the Continuous Media (CM) applications. > But why will a CM application which is performing well using UDP, use > TFRC if there is performance gap (more latency, less number of packets > transmitted in the same time, high rate fluctuations in the beginning) > betwen UDP and TFRC ? May be thats the reason we haven't seen any > applicatons using TFRC. On the other hand there is no (I haven't > found) research which analyzes the performance difference between UDP > and TFRC. It is clear that TFRC will not perform exactly like UDP ( > due to TFRC's friendliness with TCP), but how much can we expect from > TFRC? > > Faisal > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > From tphelan at sonusnet.com Thu Mar 31 10:03:12 2005 From: tphelan at sonusnet.com (Phelan, Tom) Date: Thu, 31 Mar 2005 13:03:12 -0500 Subject: [e2e] TFRC vs UDP Message-ID: Hi Syed, DCCP includes TFRC as one of its congestion control algorithms, and there has been quite a bit of discussion in the group of the impact of TFRC on streaming media applications. The DCCP User Guide contains an extensive discussion of the issue. Unfortunately, it's timed out of the drafts archive as we work out the future course of the guide, but it's available at http://www.phelan-4.com/dccp/draft-ietf-dccp-user-guide-02.txt. Tom Phelan > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org]On Behalf Of Syed Faisal > Hasan > Sent: Thursday, March 31, 2005 8:37 AM > To: gdc at iki.fi > Cc: end2end-interest at postel.org > Subject: Re: [e2e] TFRC vs UDP > > > Hi Dado, > > > >Syed Faisal Hasan wrote: > >> > >>To whom it may concern, > >> > >>TFRC was designed for use by the Continuous Media (CM) > applications. But > >>why will a CM application which is performing well using > UDP, use TFRC if > >>there is performance gap (more latency, less number of > packets transmitted > >>in the same time, high rate fluctuations in the beginning) > betwen UDP and > >>TFRC ? May be thats the reason we haven't seen any > applicatons using TFRC. > >>On the other hand there is no (I haven't found) research > which analyzes > >>the performance difference between UDP and TFRC. It is > clear that TFRC > >>will not perform exactly like UDP ( due to TFRC's > friendliness with TCP), > >>but how much can we expect from TFRC? > > > > > >Hi Syed, > > > >the motivation is that although your application would work > fine and you (a > >single person in a society) would have a good welfare using > UDP, it is your > >fellow citizens that would potentially suffer from your actions. The > >network resource should be distributed fairly - whatever it > means. If we > >all started to disregard other users, the network might stop working > >properly - equivalent to anarchy in a society. Mechanisms > are needed to > >guarantee fair distribution of the resource. TFRC attempts > to provide > >mechanisms to distribute the bandwidth resource in the same > way TCP does. > > > >I think performance issues depend more on competing TCP > flows and the > >network than on the TFRC control algorithm. > > I understand what you are talking about. But I want to know > the performance > difference of > UDP and TFRC in the same scenario. Is there any published > research on this? > > Faisal > > _________________________________________________________________ > FREE pop-up blocking with the new MSN Toolbar - get it now! > http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ > > From dpreed at reed.com Thu Mar 31 10:12:38 2005 From: dpreed at reed.com (David P. Reed) Date: Thu, 31 Mar 2005 13:12:38 -0500 Subject: [e2e] Skype and congestion collapse. In-Reply-To: <42360909.6090509@attglobal.net> References: <026F8EEDAD2C4342A993203088C1FC051C270E@esealmw109.eemea.ericsson.se> <42360909.6090509@attglobal.net> Message-ID: <424C3D96.3000402@reed.com> Alex - the underlying assumption is that traditional telephony delivers 911 functionality best. Well, the word on the street is that in California, if you call 911 on your basic, non IP cell phone, your exact position is delivered to ... well, no one knows where, but it's a place that has no capability to actually transfer that information to anyone who actually can help you in an emergency. Better to call directory assistance for the phone number of your local police dept. and hope they don't tell you "911", because that will guarantee 30-90 minutes of screwing around. OK, maybe wired phones still do 911 OK, but do PBXes? I doubt it - so the point about bosses may be bogus as well. Here the argument that 911 should be "in the network" fails. I'd much rather have my actual physical telephone be smart enough to figure out how to summon emergency services (perhaps finding the doctor who is in the next cubicle over if the SLP emergency service existed), I think. Dale Hatfield points out that the phone companies have made it *impossible* to deploy a "911-like" service over the WWW, because who can trust that a person would actually tell the truth that they have a life or death situation on their hands. But of course we can ALL trust Verizon Wireless with our lives... yeah right.