From Reiner.Ludwig at ericsson.com Mon May 1 20:45:28 2006 From: Reiner.Ludwig at ericsson.com (Reiner Ludwig) Date: Tue, 02 May 2006 05:45:28 +0200 Subject: [e2e] Persistent congestion with few TCP-compatible sources? Message-ID: <4456D5D8.9050906@ericsson.com> Hi, in a contribution that I'm writting for 3GPP, I would like to make the following statement: "It is well-known that persistent congestion (large average queue sizes and high packet drop rates) ? which is an essential precondition for the occurrence of a series of congestion-related back-to-back losses of [IP packets] ? will not occur as long as only a few (e.g., less than 100) traffic sources share the same queue at the bottleneck link of an end-to-end path, and as long as those traffic sources have implemented a TCP-compatible congestion control scheme." [The full paragraph is copied below] Can anyone, please, point me to some established papers that would backup that statement? ///Reiner -------------- "It is well-known that persistent congestion (large average queue sizes and high packet drop rates) ? which is an essential precondition for the occurrence of a series of congestion-related back-to-back losses of PDCP PDUs ? will not occur as long as only a few (e.g., less than 100) traffic sources share the same queue at the bottleneck link of an end-to-end path, and as long as those traffic sources have implemented a TCP-compatible congestion control scheme. Note that in response to a packet loss TCP halves its send rate. In fact, this rate halving behaviour of TCP is widely acknowledged as the basis for the stability of the Internet. Note also that this discussion is in principle independent of the queue management scheme implemented at the bottleneck link, e.g., whether it is a passive drop-tail queue management scheme, or an active queue management scheme which is tailored to maintaining free buffer space for the purpose of absorbing burst arrivals of packets. It should be noted, however, that active queue management schemes are known to reduce packet drop rates [RFC 2309], and are widely deployed in state-of-the-art IP routers." From Jon.Crowcroft at cl.cam.ac.uk Wed May 3 15:21:14 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 03 May 2006 23:21:14 +0100 Subject: [e2e] new network architecture idea - Message-ID: Its that time of year for a new network architecture - rather than build an overlay on IP I reckon the way to build a DOS proof, multipath, resilient network that can function in low or high bandwidth, fixed or mobile, lossy or reliable, connected or disrupted, topologies is to built the packet protocol over an overlay - so my bif is to rebuild IP on Swarms (initial prototype is IPv6 on bittorrent) packet swarming systems are nice because i) you go download your packet, so noone can dos you ii) topological attacks are hard when you dont know where I am getting the different pieces of the packet from. iii) incentive alignment thru the token system enforces approximate symmetry iv) multipath is for free and tunable v) you still have anonimity if you really want it vi) content addressable (pub/sub/ event/notify) is a first class network function vii) multicast is for free of course IP on bittorrent begs the question of what the bittorrent is on....so that's what the NSF proposal would be about (of course i'm not eligable for nsf money:-) so this is a free donation to the US NSF proposal writers guild:) cheers jon remember, you have 2 days left to register for REALMAN in Florence:- http://www.cl.cam.ac.uk/Research/SRG/netos/realman/ p.s. if the GENI is out of the lamp, who is making the 3 wishes...? From fergdawg at netzero.net Wed May 3 15:57:19 2006 From: fergdawg at netzero.net (Fergie) Date: Wed, 3 May 2006 22:57:19 GMT Subject: [e2e] new network architecture idea - Message-ID: <20060503.155818.14160.1115506@webmail24.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060503/b6e6ac9c/attachment.ksh From dima at krioukov.net Wed May 3 16:21:00 2006 From: dima at krioukov.net (Dmitri Krioukov) Date: Wed, 3 May 2006 16:21:00 -0700 Subject: [e2e] new network architecture idea - In-Reply-To: <20060503.155818.14160.1115506@webmail24.lax.untd.com> Message-ID: <000501c66f08$40a08140$eb776e89@lapa> please don't worry about that: we'll have a special unit called tcp: transmission control police! -- dima. http://www.caida.org/~dima/ > -----Original Message----- > From: end2end-interest-bounces at postel.org > [mailto:end2end-interest-bounces at postel.org] On Behalf Of Fergie > Sent: Wednesday, May 03, 2006 3:57 PM > To: Jon.Crowcroft at cl.cam.ac.uk > Cc: end2end-interest at postel.org > Subject: Re: [e2e] new network architecture idea - > > > At first blush, it sounds like law enforecement will hate it, > due to inability to determine the end-points. :-) > > I need to think about that for a little while... in the meantime, > I'll read the paper. ;-) > > Cheers, > > - ferg > > > > -- Jon Crowcroft wrote: > > Its that time of year for a new network architecture - rather > than build an overlay on IP > I reckon the way to build a DOS proof, multipath, resilient > network that can function in > low or high bandwidth, fixed or mobile, lossy or reliable, > connected or disrupted, topologies > is to built the packet protocol over an overlay - so my bif > is to rebuild > IP on Swarms (initial prototype is IPv6 on bittorrent) > > packet swarming systems are nice because > i) you go download your packet, so noone can dos you > ii) topological attacks are hard when you dont know where I > am getting the different pieces of the packet from. > iii) incentive alignment thru the token system enforces > approximate symmetry > iv) multipath is for free and tunable > v) you still have anonimity if you really want it > vi) content addressable (pub/sub/ event/notify) is a first > class network function > vii) multicast is for free > > of course IP on bittorrent begs the question of what the > bittorrent is on....so > that's what the NSF proposal would be about (of course i'm > not eligable for > nsf money:-) > > so this is a free donation to the US NSF proposal writers guild:) > > > cheers > jon > > remember, you have 2 days left to register for REALMAN in Florence:- > http://www.cl.cam.ac.uk/Research/SRG/netos/realman/ > > p.s. if the GENI is out of the lamp, who is making the 3 wishes...? > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg at netzero.net or fergdawg at sbcglobal.net > ferg's tech blog: http://fergdawg.blogspot.com/ > From Jon.Crowcroft at cl.cam.ac.uk Wed May 3 23:40:27 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 04 May 2006 07:40:27 +0100 Subject: [e2e] new network architecture idea - In-Reply-To: Message from "Fergie" of "Wed, 03 May 2006 22:57:19 GMT." <20060503.155818.14160.1115506@webmail24.lax.untd.com> Message-ID: let me conjecture that any decent future internet architecture that is proof against the current securiy threats of today's internet wil be proof agaoinst intercept, blocking, takedown, and surveillance by _anyone_, whatever their good or bad intentions so by presenting a half-bakde appproach to preventing ddos, I am necessarily going to do nnoy law enforcement of course, i dont see why anyone should enforce _their_ laws on _us_ (or _our_ laws on _them) - its an outmoded local view:) In missive <20060503.155818.14160.1115506 at webmail24.lax.untd.com>, "Fergie" typed: >>At first blush, it sounds like law enforecement will hate it, >>due to inability to determine the end-points. :-) >> >>I need to think about that for a little while... in the meantime, >>I'll read the paper. ;-) >> >>Cheers, >> >>- ferg >> >> >> >>-- Jon Crowcroft wrote: >> >>Its that time of year for a new network architecture - rather than build= >> an overlay on IP >>I reckon the way to build a DOS proof, multipath, resilient network that= >> can function in = >> >>low or high bandwidth, fixed or mobile, lossy or reliable, connected or = >>disrupted, topologies >>is to built the packet protocol over an overlay - so my bif is to rebuil= >>d >>IP on Swarms (initial prototype is IPv6 on bittorrent) >> >>packet swarming systems are nice because >>i) you go download your packet, so noone can dos you >>ii) topological attacks are hard when you dont know where I am getting t= >>he different pieces of the packet from. >>iii) incentive alignment thru the token system enforces approximate symm= >>etry >>iv) multipath is for free and tunable >>v) you still have anonimity if you really want it >>vi) content addressable (pub/sub/ event/notify) is a first class network= >> function >>vii) multicast is for free >> >>of course IP on bittorrent begs the question of what the bittorrent is o= >>n....so = >> >>that's what the NSF proposal would be about (of course i'm not eligable = >>for >>nsf money:-) >> >>so this is a free donation to the US NSF proposal writers guild:) >> >> >>cheers >>jon >> >>remember, you have 2 days left to register for REALMAN in Florence:- >>http://www.cl.cam.ac.uk/Research/SRG/netos/realman/ >> >>p.s. if the GENI is out of the lamp, who is making the 3 wishes...? >> >> >>-- >>"Fergie", a.k.a. Paul Ferguson >> Engineering Architecture for the Internet >> fergdawg at netzero.net or fergdawg at sbcglobal.net >> ferg's tech blog: http://fergdawg.blogspot.com/ >> cheers jon From fergdawg at netzero.net Thu May 4 06:06:03 2006 From: fergdawg at netzero.net (Fergie) Date: Thu, 4 May 2006 13:06:03 GMT Subject: [e2e] new network architecture idea - Message-ID: <20060504.060650.13667.1122895@webmail46.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060504/2a226e7c/attachment.ksh From Jon.Crowcroft at cl.cam.ac.uk Wed May 10 03:19:25 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 10 May 2006 11:19:25 +0100 Subject: [e2e] new network architecture idea - In-Reply-To: Message from Jing Shen of "Wed, 10 May 2006 00:54:22 +0800." <20060509165422.18505.qmail@web15406.mail.cnb.yahoo.com> Message-ID: bittorrent is a specific technology -the _idea_ is that of swarms - file swarming is a general idea that a receiver of information often doesn't really care where the information comes from in terms of topology or sending computer, even at the level of individual bits so one can distribute information by allowing receivers to request components from whereever seems a good contributer - torrent systems can maximise network throughput (especially if they also employ net coding) and can be very robust to outages - the main complexity is integrity checking of content, but there are nice techniques for that torrents could be implemented on +anything+ (e.g. direct on analogue channels) IP is a way to get a packet from A->B, but one could implement it on a torrent or swarm - whether TCP over IP over a swarm would work well is an interesting question, but TCP isnt a very sensible protocol w.r.t most applications in today's internet anyhow, and is even less sensible tomorrow if you are interested in authenticity and provenance of content, that is in any case a higher level problem than knowing the source IP address and transport port number data came from - those provide you with ZERO assurance about "reliability" of content - p2p (like wiki) is no worse that servers (like encyclopedias) inherently - on legacy traffic engineering and p2p: there's some good papers emerging on designing nets for p2p and p2p for nets - T. Karagiannis, P. Rodriguez, and K. Papagiannaki. Should Internet Service Providers Fear Peer-Assisted Content Distribution? In ACM Internet Measurement Conference, New Orleans, LA, October, 2005. is a good read.... can be downoaded from: http://www.cambridge.intel-research.net/~kpapagia/ (what, no torrent for google scholar yet?:) In missive <20060509165422.18505.qmail at web15406.mail.cnb.yahoo.com>, Jing Shen typed: >>What do you mean with "IP on bittorent" ? BT is just >>an application level protocol over IP while protocol >>udner is TCP. >>On the other hand, if any e2e communication is with >>P2P How can I know whether the news is reliable or >>just a manmade one? >>To technical question, I read several paper on p2p >>traffic on WAN. But, it seems paper from france >>differs a little from korean. Some one said upstream >>p2p bw is smaller than downstream, while other says >>the oppsite. Is there demand on network topology? is >>there requirement on routing protocol? Is there way to >>enable interception asked by law? >> >> >>> >>> -- Jon Crowcroft wrote: >>> >>> Its that time of year for a new network architecture >>> - rather than build an overlay on IP >>> I reckon the way to build a DOS proof, multipath, >>> resilient network that can function in >>> low or high bandwidth, fixed or mobile, lossy or >>> reliable, connected or disrupted, topologies >>> is to built the packet protocol over an overlay - so >>> my bif is to rebuild >>> IP on Swarms (initial prototype is IPv6 on >>> bittorrent) >>> >>> packet swarming systems are nice because >>> i) you go download your packet, so noone can dos you >>> ii) topological attacks are hard when you dont know >>> where I am getting the different pieces of the >>> packet from. >>> iii) incentive alignment thru the token system >>> enforces approximate symmetry >>> iv) multipath is for free and tunable >>> v) you still have anonimity if you really want it >>> vi) content addressable (pub/sub/ event/notify) is a >>> first class network function >>> vii) multicast is for free >>> >>> of course IP on bittorrent begs the question of what >>> the bittorrent is on....so >>> that's what the NSF proposal would be about (of >>> course i'm not eligable for >>> nsf money:-) >>> >>> so this is a free donation to the US NSF proposal >>> writers guild:) >>> >>> >>> cheers >>> jon >>> >>> remember, you have 2 days left to register for >>> REALMAN in Florence:- >>> http://www.cl.cam.ac.uk/Research/SRG/netos/realman/ >>> >>> p.s. if the GENI is out of the lamp, who is making >>> the 3 wishes...? >>> >>> >>> -- >>> "Fergie", a.k.a. Paul Ferguson >>> Engineering Architecture for the Internet >>> fergdawg at netzero.net or fergdawg at sbcglobal.net >>> ferg's tech blog: http://fergdawg.blogspot.com/ >>> >>> >> >> >>Jing Shen >> >>Data Communication Center >>HangZhou TeleCom >>HangZhou ZJ 310027 >>P.R.China >> >>' spamcontrol ' >> >> >> >>___________________________________________________________ >>????????????????-3.5G??????20M?????? >>http://cn.mail.yahoo.com cheers jon From Jon.Crowcroft at cl.cam.ac.uk Thu May 11 07:36:21 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 11 May 2006 15:36:21 +0100 Subject: [e2e] tunnels with only one end point specified. Message-ID: so has anyone considered how you might design an ip tunnel system with only having to specify ONE end point of the tunnel motivation: the big problem with tunnels is that you have to nail TWO ends which means you need a lot of prior agreement, and as we know, distributred agreement is NP hard (neocon-politically hard) so how about tunnels where the encapsulating header uses an ANY CAST address for one end (either - nearest, or furthest)? next: underhandover overloy networks - technique that allies mobileip and ron:) cheers jon. on closer examination, the object was nearer than when first observed. From daniel.minder at informatik.uni-stuttgart.de Thu May 11 08:03:12 2006 From: daniel.minder at informatik.uni-stuttgart.de (Daniel Minder) Date: Thu, 11 May 2006 17:03:12 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 Message-ID: <001701c6750c$08c16ff0$10d24581@pcvs7> Hi, can anybody explain why equation (3) in RFC 2581 is ssthresh = max (FlightSize / 2, 2*SMSS) and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used. In some postings, I found that FlightSize is usually equal to min(rwnd, cwnd) - but not always. According to the RFC, flightsize is "the amount of data that has been sent but not yet acknowledged". Let's assume that 10 packets have been sent. If all 10 get lost, flightsize is 10 and ssthresh will be set to 5. But if only the last 4 get lost (and no more packets are to be sent), flightsize is 4 and ssthresh will be set to 2. This seems counterproductive to me since the network is propably more congested in the first case than in the second. Therefore, ssthresh should be set to a lower value if more packets get lost, i.e. when flightsize is larger. For example: ssthresh = max( (min(rwnd, cwnd) - FlightSize) / 2, 2 * SMSS) Or did I miss the point? TIA, Daniel From jshen_cad at yahoo.com.cn Tue May 9 09:54:22 2006 From: jshen_cad at yahoo.com.cn (Jing Shen) Date: Wed, 10 May 2006 00:54:22 +0800 (CST) Subject: [e2e] new network architecture idea - In-Reply-To: <20060503.155818.14160.1115506@webmail24.lax.untd.com> Message-ID: <20060509165422.18505.qmail@web15406.mail.cnb.yahoo.com> What do you mean with "IP on bittorent" ? BT is just an application level protocol over IP while protocol udner is TCP. On the other hand, if any e2e communication is with P2P How can I know whether the news is reliable or just a manmade one? To technical question, I read several paper on p2p traffic on WAN. But, it seems paper from france differs a little from korean. Some one said upstream p2p bw is smaller than downstream, while other says the oppsite. Is there demand on network topology? is there requirement on routing protocol? Is there way to enable interception asked by law? Jing > > -- Jon Crowcroft wrote: > > Its that time of year for a new network architecture > - rather than build an overlay on IP > I reckon the way to build a DOS proof, multipath, > resilient network that can function in > low or high bandwidth, fixed or mobile, lossy or > reliable, connected or disrupted, topologies > is to built the packet protocol over an overlay - so > my bif is to rebuild > IP on Swarms (initial prototype is IPv6 on > bittorrent) > > packet swarming systems are nice because > i) you go download your packet, so noone can dos you > ii) topological attacks are hard when you dont know > where I am getting the different pieces of the > packet from. > iii) incentive alignment thru the token system > enforces approximate symmetry > iv) multipath is for free and tunable > v) you still have anonimity if you really want it > vi) content addressable (pub/sub/ event/notify) is a > first class network function > vii) multicast is for free > > of course IP on bittorrent begs the question of what > the bittorrent is on....so > that's what the NSF proposal would be about (of > course i'm not eligable for > nsf money:-) > > so this is a free donation to the US NSF proposal > writers guild:) > > > cheers > jon > > remember, you have 2 days left to register for > REALMAN in Florence:- > http://www.cl.cam.ac.uk/Research/SRG/netos/realman/ > > p.s. if the GENI is out of the lamp, who is making > the 3 wishes...? > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawg at netzero.net or fergdawg at sbcglobal.net > ferg's tech blog: http://fergdawg.blogspot.com/ > > Jing Shen Data Communication Center HangZhou TeleCom HangZhou ZJ 310027 P.R.China ' spamcontrol ' ___________________________________________________________ ÇÀ×¢ÑÅ»¢Ãâ·ÑÓÊÏä-3.5GÈÝÁ¿£¬20M¸½¼þ£¡ http://cn.mail.yahoo.com From weiye at ISI.EDU Tue May 9 10:06:35 2006 From: weiye at ISI.EDU (Wei Ye) Date: Tue, 09 May 2006 10:06:35 -0700 Subject: [e2e] ACM SenSys'06 call for posters and demos Message-ID: <1147194395.3705.4.camel@localhost.localdomain> Our Apologies if you have received multiple copies. Wei Ye and Cormac J. Sreenan SenSys'06 Publicity Co-Chairs ------------ ACM SenSys 2006: Call for Posters and Demos The 4th ACM Conference on Embedded Networked Sensor Systems Sponsored by ACM SIGCOMM, SIGMOBILE, SIGARCH, SIGOPS, SIGMETRICS and SIGBED; with support from NSF. Boulder, Colorado, USA November 1-3, 2006 http://sensys.acm.org/2006/ CALL FOR POSTERS The poster session will provide a forum for researchers to showcase their work and obtain feedback on ongoing research from knowledgeable conference attendees. Areas of interest are the same as those listed in the technical call for papers. While the poster need not describe completed work, it should report on research for which at least preliminary results are available. We especially encourage submissions by students (that is, for which a student is the first author on the poster). POSTER SUBMISSION INSTRUCTIONS Poster proposals must be submitted as a single PDF file with no more than 3 pages. The first two pages should contain an abstract describing the research content of the poster, along with title, authors, institutional affiliations and contact information. The third page should contain a thumbnail draft of the poster's contents. Please submit your poster proposal as a PDF e-mail attachment to sensys06-poster-chairs at isi.edu with the subject line reading "Sensys Poster Submission" before the deadline. Any questions for the Poster Co-chairs Henry Tirri (Nokia), Robert Szewczyk (Moteiv) may also be directed to this address. IMPORTANT DATES Three-page poster proposal: 11:59pm (EST), July 24, 2006 Notification of acceptance: August 7, 2006 Camera-ready abstract: August 22, 2006 Conference dates: November 1-3, 2006 BASIC INFORMATION ABOUT POSTERS Two-page poster abstracts will appear in the conference proceedings. Authors of accepted poster proposals will have a chance to present the poster to interested attendees during a special poster session at SenSys. Well-crafted posters will tell the story well by themselves, but authors of posters are expected to be available to describe and discuss the work in the poster during the session. The poster dimensions are 30" by 40", with poster contents mounted on rectangular poster board that we will provide. You may choose a layout consisting of individual sheets of paper, or a monolithic large piece of poster paper (which can be printed at document companies). Henry Tirri, Nokia Robert Szewczyk, Moteiv SenSys 2006 Poster Chairs CALL FOR DEMOS Demonstrations showing innovative research and applications are solicited. SenSys'06 is very interested in demonstrations of technology, platforms, and applications of wireless sensor networks. Two-page abstracts of accepted demos will be published in the SenSys conference proceedings. Submissions from both industries and universities are encouraged. Large-scale, outdoor demos can also be accommodated at the conference facility. For the first time, SenSys 2006 will present a best demo award. DEMO SUBMISSION INSTRUCTIONS Please send a two-page description of your demo to sensys06-demo-chairs at isi.edu in PDF format by the dates listed below. An additional one page appendix can be included in the initial submission but will be removed in published proceedings. Be as specific as possible in describing what you will show. IMPORTANT DATES Two-page demo descriptions: 11:59pm (EST), July 24, 2006 Notification of acceptance: August 7, 2006 Camera-ready abstract: August 22, 2006 Conference dates: November 1-3, 2006 Chieh-Yih Wan, Intel Labs Jie Liu, Microsoft Research SenSys 2006 Demo Chairs From touch at ISI.EDU Thu May 11 08:22:47 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 May 2006 08:22:47 -0700 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: References: Message-ID: <446356C7.8050703@isi.edu> Jon Crowcroft wrote: > so has anyone considered how you might design an ip tunnel > system with only having to specify ONE end point of the tunnel > motivation: the > big problem with tunnels is that you have to nail TWO ends > which means you need a lot of prior agreement, and as we know, > distributred agreement is NP hard (neocon-politically hard) The issue is that the other end needs to know the encased header is coming, otherwise it can - and should - treat it transparently. I.e., tunnels work exactly because of the controlled difference between: - those who don't know transparently forward - those who know decapsulate You can setup nodes that decapsulate everything, but that needs to be setup in advance (back where you started). > so how about tunnels where the encapsulating header uses an ANY CAST > address for one end (either - nearest, or furthest)? Sure - please start by showing anycast that provides that capability with a regular packet. Then program it to decapsulate everything. Done ;-) > next: underhandover overloy networks - technique that allies > mobileip and ron:) > > cheers > jon. > > on closer examination, the object was nearer than when first observed. From craig at aland.bbn.com Thu May 11 09:01:32 2006 From: craig at aland.bbn.com (Craig Partridge) Date: Thu, 11 May 2006 12:01:32 -0400 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: Your message of "Thu, 11 May 2006 15:36:21 BST." Message-ID: <20060511160132.0D2136B@aland.bbn.com> Hi Jon: I don't quite get the motivation. How is prior agreement with a peer endpoint harder than negotiating with all the possible ANYCAST recipients? Craig In message , Jon Crowcroft writes: >so has anyone considered how you might design an ip tunnel >system with only having to specify ONE end point of the tunnel >motivation: the >big problem with tunnels is that you have to nail TWO ends >which means you need a lot of prior agreement, and as we know, >distributred agreement is NP hard (neocon-politically hard) > >so how about tunnels where the encapsulating header uses an ANY CAST >address for one end (either - nearest, or furthest)? > >next: underhandover overloy networks - technique that allies >mobileip and ron:) > >cheers >jon. > >on closer examination, the object was nearer than when first observed. From touch at ISI.EDU Thu May 11 10:06:25 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 May 2006 10:06:25 -0700 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <517e86fb0605110959m3b9597f3v2deba466cf44084b@mail.gmail.com> References: <446356C7.8050703@isi.edu> <517e86fb0605110959m3b9597f3v2deba466cf44084b@mail.gmail.com> Message-ID: <44636F11.30108@isi.edu> alessandro salvatori wrote: > On 5/11/06, Joe Touch wrote: >> You can setup nodes that decapsulate everything, but that needs to be >> setup in advance (back where you started). > > i disagree. for the "nearest" case, it would be enough to allocate a > flag that tells "decapsulate me, if you can" For any case such a flag would be useful, but if the flag passes through more than one such node, it'd decapsulate there. Joe From touch at ISI.EDU Thu May 11 10:43:05 2006 From: touch at ISI.EDU (Joe Touch) Date: Thu, 11 May 2006 10:43:05 -0700 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <517e86fb0605111022y75c7ed13g56d5e0e2650eacf9@mail.gmail.com> References: <446356C7.8050703@isi.edu> <517e86fb0605110959m3b9597f3v2deba466cf44084b@mail.gmail.com> <44636F11.30108@isi.edu> <517e86fb0605111022y75c7ed13g56d5e0e2650eacf9@mail.gmail.com> Message-ID: <446377A9.5040403@isi.edu> alessandro salvatori wrote: > On 5/11/06, Joe Touch wrote: >> alessandro salvatori wrote: >> > On 5/11/06, Joe Touch wrote: >> >> You can setup nodes that decapsulate everything, but that needs to be >> >> setup in advance (back where you started). >> > >> > i disagree. for the "nearest" case, it would be enough to allocate a >> > flag that tells "decapsulate me, if you can" >> >> For any case such a flag would be useful, but if the flag passes through >> more than one such node, it'd decapsulate there. > > it wouldn't pass through more than one such node, as the first one > would decapsulate the inner datagram. the flag is in the envelope > header, once the inner datagram is decapsulated the flag is not there > any more. Yes - but the trick is which one? How does the node know it's the nearest, or is the definition of nearest "the first node with this anycast address"? If so, tunneling to the nearest anything seems to defeat the goal of most tunnels... Joe From arthur at gprt.ufpe.br Thu May 11 12:54:43 2006 From: arthur at gprt.ufpe.br (Arthur de Castro Callado) Date: Thu, 11 May 2006 16:54:43 -0300 (BRT) Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <001701c6750c$08c16ff0$10d24581@pcvs7> References: <001701c6750c$08c16ff0$10d24581@pcvs7> Message-ID: Daniel, these variables are in bytes, not packets, and this equation is only used when detecting loss. I suppose it means that when a single loss is detected, then the "ssthresh" is equal to the present "FlightSize", i.e., the congestion control immediately jumps to collision avvoidance mode. Cheers, Arthur Callado. PhD Candidate from the Federal University of Pernambuco, Brazil. On Thu, 11 May 2006, Daniel Minder wrote: > Hi, > > can anybody explain why equation (3) in RFC 2581 is > ssthresh = max (FlightSize / 2, 2*SMSS) > and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used. > > In some postings, I found that FlightSize is usually equal to min(rwnd, > cwnd) - but not always. According to the RFC, flightsize is "the amount of > data that has been sent but not yet acknowledged". > > Let's assume that 10 packets have been sent. If all 10 get lost, flightsize > is 10 and ssthresh will be set to 5. But if only the last 4 get lost (and no > more packets are to be sent), flightsize is 4 and ssthresh will be set to 2. > This seems counterproductive to me since the network is propably more > congested in the first case than in the second. Therefore, ssthresh should > be set to a lower value if more packets get lost, i.e. when flightsize is > larger. For example: > ssthresh = max( (min(rwnd, cwnd) - FlightSize) / 2, 2 * SMSS) > > Or did I miss the point? > > TIA, > Daniel From arjuna.sathiaseelan at gmail.com Thu May 11 13:00:53 2006 From: arjuna.sathiaseelan at gmail.com (Arjuna Sathiaseelan) Date: Thu, 11 May 2006 21:00:53 +0100 Subject: [e2e] end2end-interest Digest, Vol 27, Issue 4 In-Reply-To: References: Message-ID: <1ef225900605111300q767e6441q589d95f6cfc39d4f@mail.gmail.com> Ok so how I see this is in 2 scenarios: Say the no of packets ur sending i.e 10 in ur case could be either a set of 10 packets in the middle of a connection or the last set of packets in a connection. If its in the middle of a connection and if the last 4 packets have been lost as u say, the previous 6 packets would have triggered the sender to send few more packets (depending on whether its in slow start or congestion avoidance), thus the flight size would not be 4 as u claim - but would be more than that. If its the latter case where the set of packets were last in the connection, then if these 4 packets were lost - then they would be recovered only by a retransmission timeout. -Arjuna > > Message: 2 > Date: Thu, 11 May 2006 17:03:12 +0200 > From: "Daniel Minder" > Subject: [e2e] Question on ssthresh setting in RFC 2581 > To: > Message-ID: <001701c6750c$08c16ff0$10d24581 at pcvs7> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > can anybody explain why equation (3) in RFC 2581 is > ssthresh = max (FlightSize / 2, 2*SMSS) > and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used. > > In some postings, I found that FlightSize is usually equal to min(rwnd, > cwnd) - but not always. According to the RFC, flightsize is "the amount of > data that has been sent but not yet acknowledged". > > Let's assume that 10 packets have been sent. If all 10 get lost, > flightsize > is 10 and ssthresh will be set to 5. But if only the last 4 get lost (and > no > more packets are to be sent), flightsize is 4 and ssthresh will be set to > 2. > This seems counterproductive to me since the network is propably more > congested in the first case than in the second. Therefore, ssthresh should > be set to a lower value if more packets get lost, i.e. when flightsize is > larger. For example: > ssthresh = max( (min(rwnd, cwnd) - FlightSize) / 2, 2 * SMSS) > > Or did I miss the point? > > TIA, > Daniel > > > > -- > Regards, > Arjuna > > Postdoctoral Researcher > Engineering Research Lab, > Department of Engineering, > University of Aberdeen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060511/394b4958/attachment.html From randall at lakerest.net Thu May 11 12:52:38 2006 From: randall at lakerest.net (Randall Stewart) Date: Thu, 11 May 2006 15:52:38 -0400 Subject: [e2e] application layer -SCTP!!!! In-Reply-To: References: Message-ID: <44639606.3060306@lakerest.net> Srinivas: Well.. I can't speak for the Linux and u-Space stack's.. so I don't know the details.. but the FreeBSD-SCTP stack does support three different models of partial-reliability. 1) Time based, when you send data you specify howmany milliseconds the data is good for. 2) Buffer bounded, when you send data you specify the maximum buffer size (of your sendbuf) you wish to consume, when you reach that max other sends that were sent buffer bounded may get "skipped" to free up space... 3) Retransmission based, where you specify the maximum number of retransmissions you want made.. so for example if you specify 0, you get one and only one transmission and then the data is skipped (if a retran was required). If you want to get FreeBSD and play with it contact me offline and I can give you pointers on what options you need on the send calls.. R Srinivas Krishnan wrote: > SCTP does seem to provide on the outside a very nice interface > borrowing congestion control from TCP and the concept of various > streams. However, the experiences we had with SCTP are not too good, > especially with the PR-SCTP. We at UNC-CH wanted a protocol that lets > choose on the application layer conditions whether we wanted a fully > reliable protocol or just a best-effort protocol. Unfortunately the 2 > implementations of SCTP: SCTPLIB (a user level package) or the kernel > level implementation in Linux do not fully support partial reliability > or a way of making per packet/object decision of whether we wanted > full reliability, partial etc. > > In the end we rolled out our own protocol based on UDP using TFRC as a > congestion control algorithm (based it on the sender side). The > protocol lets us choose whether we wanted to provide full reliability, > partial reliability based on the application. We even have a module > which does a form of congestion control in the application itself. > This is for a video adaptation and hence based on latency we always do > not need to send the next packet as the time for display on the client > might have passed. > > I will describe some more of our work on video adaptation on a separate post. > > ********************************* > Srinivas Krishnan > > Graduate Student > Dept. Of Computer Science > UNC-Chapel Hill > ++++++++++++++++++++++++++++++++ > Phone: > **Office: (919) 962-1920 > **Cell: (585)295-3359 > Email: krishnan at cs.unc.edu, shrin.krishnan at gmail.com > ++++++++++++++++++++++++ > Web: www.cs.unc.edu/~krishnan > ************************************** > > -- Randall Stewart 803-345-0369 815-342-5222(cell) From sandr8 at gmail.com Thu May 11 09:59:05 2006 From: sandr8 at gmail.com (alessandro salvatori) Date: Thu, 11 May 2006 18:59:05 +0200 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <446356C7.8050703@isi.edu> References: <446356C7.8050703@isi.edu> Message-ID: <517e86fb0605110959m3b9597f3v2deba466cf44084b@mail.gmail.com> On 5/11/06, Joe Touch wrote: > You can setup nodes that decapsulate everything, but that needs to be > setup in advance (back where you started). i disagree. for the "nearest" case, it would be enough to allocate a flag that tells "decapsulate me, if you can" cheers -- alessandro From sandr8 at gmail.com Thu May 11 10:22:32 2006 From: sandr8 at gmail.com (alessandro salvatori) Date: Thu, 11 May 2006 19:22:32 +0200 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <44636F11.30108@isi.edu> References: <446356C7.8050703@isi.edu> <517e86fb0605110959m3b9597f3v2deba466cf44084b@mail.gmail.com> <44636F11.30108@isi.edu> Message-ID: <517e86fb0605111022y75c7ed13g56d5e0e2650eacf9@mail.gmail.com> On 5/11/06, Joe Touch wrote: > alessandro salvatori wrote: > > On 5/11/06, Joe Touch wrote: > >> You can setup nodes that decapsulate everything, but that needs to be > >> setup in advance (back where you started). > > > > i disagree. for the "nearest" case, it would be enough to allocate a > > flag that tells "decapsulate me, if you can" > > For any case such a flag would be useful, but if the flag passes through > more than one such node, it'd decapsulate there. it wouldn't pass through more than one such node, as the first one would decapsulate the inner datagram. the flag is in the envelope header, once the inner datagram is decapsulated the flag is not there any more. -- Alessandro From sandr8 at gmail.com Thu May 11 10:25:16 2006 From: sandr8 at gmail.com (alessandro salvatori) Date: Thu, 11 May 2006 19:25:16 +0200 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <517e86fb0605111024q2a29cbe6ub8e2eb880e60de77@mail.gmail.com> References: <20060511160132.0D2136B@aland.bbn.com> <517e86fb0605111024q2a29cbe6ub8e2eb880e60de77@mail.gmail.com> Message-ID: <517e86fb0605111025h2b87919k38e564b382ffd3f1@mail.gmail.com> On 5/11/06, Craig Partridge wrote: > > Hi Jon: > > I don't quite get the motivation. > > How is prior agreement with a peer endpoint harder than negotiating with > all the possible ANYCAST recipients? The anycast address would be equivalent to a flag that tells "decapsulate me if you are addressable by this anycast address". So, no negotiation would be needed. -- Alessandro From sandr8 at gmail.com Thu May 11 10:52:31 2006 From: sandr8 at gmail.com (alessandro salvatori) Date: Thu, 11 May 2006 19:52:31 +0200 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <446377A9.5040403@isi.edu> References: <446356C7.8050703@isi.edu> <517e86fb0605110959m3b9597f3v2deba466cf44084b@mail.gmail.com> <44636F11.30108@isi.edu> <517e86fb0605111022y75c7ed13g56d5e0e2650eacf9@mail.gmail.com> <446377A9.5040403@isi.edu> Message-ID: <517e86fb0605111052n1c2db028i77c140b7a8034dbd@mail.gmail.com> On 5/11/06, Joe Touch wrote: > Yes - but the trick is which one? How does the node know it's the > nearest, or is the definition of nearest "the first node with this > anycast address"? that's how I intended it and how I interpreted what Jon said, but mileage may vary :) > If so, tunneling to the nearest anything seems to defeat the goal of > most tunnels... the goal of the tunnels I was thinking about is that of circumventing legacy router clouds, as -- for instance -- IPv4 tunnels that carry IPv6 datagrams. -- Alessandro From simon at limmat.switch.ch Fri May 12 03:52:57 2006 From: simon at limmat.switch.ch (Simon Leinen) Date: Fri, 12 May 2006 12:52:57 +0200 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: (Jon Crowcroft's message of "Thu, 11 May 2006 15:36:21 +0100") References: Message-ID: Jon Crowcroft writes: > so how about tunnels where the encapsulating header uses an ANY CAST > address for one end (either - nearest, or furthest)? I think RFC 3068, "An Anycast Prefix for 6to4 Relay Routers" already works this way using a global well-known anycast address for the Internet-side end. There are both globally-visible and ISP-internal instances of that tunnel endpoint. For return traffic, the (well-known) tunnel endpoint extracts the outer (IPv4) destination address from the inner (IPv6) destination address. -- Simon. From puddinghead_wilson007 at yahoo.co.uk Fri May 12 01:25:31 2006 From: puddinghead_wilson007 at yahoo.co.uk (Puddinhead Wilson) Date: Fri, 12 May 2006 09:25:31 +0100 (BST) Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <517e86fb0605111052n1c2db028i77c140b7a8034dbd@mail.gmail.com> Message-ID: <20060512082531.36988.qmail@web25411.mail.ukl.yahoo.com> nothing like postal addresses.... You could always set a way to say "hey if caller id is not there, do not accept calls" or if "no source Identifer, do not accept incoming message stream" --- alessandro salvatori wrote: > On 5/11/06, Joe Touch wrote: > > Yes - but the trick is which one? How does the > node know it's the > > nearest, or is the definition of nearest "the > first node with this > > anycast address"? > > that's how I intended it and how I interpreted what > Jon said, but > mileage may vary :) > > > If so, tunneling to the nearest anything seems to > defeat the goal of > > most tunnels... > > the goal of the tunnels I was thinking about is that > of circumventing > legacy router clouds, as -- for instance -- IPv4 > tunnels that carry > IPv6 datagrams. > -- > Alessandro > Send instant messages to your online friends http://uk.messenger.yahoo.com From detlef.bosau at web.de Fri May 12 09:07:48 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 12 May 2006 18:07:48 +0200 Subject: [e2e] tunnels with only one end point specified. In-Reply-To: <446377A9.5040403@isi.edu> References: <446356C7.8050703@isi.edu> <517e86fb0605110959m3b9597f3v2deba466cf44084b@mail.gmail.com> <44636F11.30108@isi.edu> <517e86fb0605111022y75c7ed13g56d5e0e2650eacf9@mail.gmail.com> <446377A9.5040403@isi.edu> Message-ID: <4464B2D4.2030200@web.de> Joe Touch wrote: >Yes - but the trick is which one? How does the node know it's the > The one who feels concerned with this packet. Please note: JC talked about _anycast_ and not about _broadcast_. Please note the subtle difference. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From detlef.bosau at web.de Fri May 12 13:25:52 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 12 May 2006 22:25:52 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: References: <001701c6750c$08c16ff0$10d24581@pcvs7> Message-ID: <4464EF50.5030704@web.de> Arthur de Castro Callado wrote: > Daniel, > > these variables are in bytes, not packets, and this equation is > only used when detecting loss. I suppose it means that when a single > loss is detected, then the "ssthresh" is equal to the present > "FlightSize", i.e., the congestion control immediately jumps to > collision avvoidance mode. ^^^^^^^^^^^^^^^^^^^^ So the equation might be particularly suitable for CSMA/CA networks ;-) *SCNR* Detlef From lars.eggert at netlab.nec.de Sat May 13 02:28:31 2006 From: lars.eggert at netlab.nec.de (Lars Eggert) Date: Sat, 13 May 2006 11:28:31 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <001701c6750c$08c16ff0$10d24581@pcvs7> References: <001701c6750c$08c16ff0$10d24581@pcvs7> Message-ID: <26C79252-3D79-4943-9956-0A5A914F01CE@netlab.nec.de> On May 11, 2006, at 17:03, Daniel Minder wrote: > can anybody explain why equation (3) in RFC 2581 is > ssthresh = max (FlightSize / 2, 2*SMSS) > and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was > used. You might also want to look at http://tools.ietf.org/html/draft-ietf- tcpm-rfc2581bis-00.txt, which will replace RFC2581. Lars -- Lars Eggert NEC Network Laboratories -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3686 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060513/d1c8e631/smime.bin From detlef.bosau at web.de Sat May 13 06:13:43 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 13 May 2006 15:13:43 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <001701c6750c$08c16ff0$10d24581@pcvs7> References: <001701c6750c$08c16ff0$10d24581@pcvs7> Message-ID: <4465DB87.9010401@web.de> O.k., one day later.... Daniel Minder wrote: >Hi, > >can anybody explain why equation (3) in RFC 2581 is > ssthresh = max (FlightSize / 2, 2*SMSS) >and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used. > > at least one remark is made in rfc2581 itself: > Implementation Note: an easy mistake to make is to simply use cwnd, > rather than FlightSize, which in some implementations may > incidentally increase well beyond rwnd. > Hm. The motivation is clear: The sender must not send more data to the network than the receiver is able / willing to accept. What I?m curious about: Exactly _this_ is the semantics of rwnd. Thus, even if cwnd exceeded rwnd this would be no problem because the min(rwnd,*) would restrict the sender appropriately. In addition, I?m not comfortable with the use of "flightsize" here. Basically, CWND provides an estimate for the path?s capacity. In addition, if more than one flow share a common path CWND provides an estimate for the fair share of the path?s capacity. The purpose of using a common AIMD scheme for all senders is to have the individual CWND values converge to the same sawtooth function. When we use flightsize here, the iteration scheme is not necessarily identical for different senders, and I?m not quite sure whether this could affect the convergence of the individual CWND functions. >In some postings, I found that FlightSize is usually equal to min(rwnd, >cwnd) - but not always. According to the RFC, flightsize is "the amount of >data that has been sent but not yet acknowledged". > > And this may actually exceed the receiver?s window as rwnd may change dynamically. However: It?s the purpose of CWND to estimate the path?s capcaity in oder to provide propoer _congestion_ control. Preventing the sender to exceed the receiver?s capacity is subject to _flow_ control which is ensured by rwnd. >Let's assume that 10 packets have been sent. If all 10 get lost, flightsize >is 10 and ssthresh will be set to 5. But if only the last 4 get lost (and no >more packets are to be sent), flightsize is 4 and ssthresh will be set to 2. > That?s the reason why I?m not comfortable with the use of flightsize here. Even flightsitze is an estimate and thus may be wrong. Particularly in the timeout case, we do not know how many packets have been lost. Whe only know that our current capacity estimate is too large. So, admittedly only one night later, perhaps things appear different to me tomorrow or next week ;-), I?m not totally convinced that RFC 2001 was broken here. Which leads to the question: Why did we fix it? Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From ramu20 at gmail.com Sat May 13 07:10:30 2006 From: ramu20 at gmail.com (ramu yerukala) Date: Sat, 13 May 2006 19:40:30 +0530 Subject: [e2e] end2end-interest Digest, Vol 27, Issue 6 In-Reply-To: References: Message-ID: I need about statistical tool but not others if you have any information about the statistics & econometrics please give me that information other wise i don't want any information thank you. with regards, ramu On 5/13/06, end2end-interest-request at postel.org < end2end-interest-request at postel.org> wrote: > > Send end2end-interest mailing list submissions to > end2end-interest at postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.postel.org/mailman/listinfo/end2end-interest > or, via email, send a message with subject or body 'help' to > end2end-interest-request at postel.org > > You can reach the person managing the list at > end2end-interest-owner at postel.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of end2end-interest digest..." > > > Today's Topics: > > 1. Re: tunnels with only one end point specified. (Detlef Bosau) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 12 May 2006 18:07:48 +0200 > From: Detlef Bosau > Subject: Re: [e2e] tunnels with only one end point specified. > To: Joe Touch > Cc: Jon Crowcroft , > end2end-interest at postel.org, sandr8 at gmail.com > Message-ID: <4464B2D4.2030200 at web.de> > Content-Type: text/plain; charset=us-ascii; format=flowed > > Joe Touch wrote: > > >Yes - but the trick is which one? How does the node know it's the > > > The one who feels concerned with this packet. > > Please note: JC talked about _anycast_ and not about _broadcast_. Please > note the subtle difference. > > Detlef > > -- > Detlef Bosau > Galileistrasse 30 > 70565 Stuttgart > Mail: detlef.bosau at web.de > Web: http://www.detlef-bosau.de > Mobile: +49 172 681 9937 > > > > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://www.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 27, Issue 6 > *********************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060513/6d61fe5e/attachment.html From tim at ivisit.com Sat May 13 09:47:08 2006 From: tim at ivisit.com (Tim Dorcey) Date: Sat, 13 May 2006 09:47:08 -0700 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <4465DB87.9010401@web.de> Message-ID: <004501c676ac$e0513a30$0300a8c0@int.eyematic.com> > However: It?s the purpose of CWND to estimate the path?s capcaity in > oder to provide propoer _congestion_ control. I think the issue is that CWND becomes stale if the sender enters a period where it is not filling the CWND (because the application is not providing enough data). Suppose, CWND were to grow large during a period of heavy transmission, and then the application slows to sending only a single segment per round trip. If a loss then occurs, the implication is that the network may be too congested to send more than a single segment per round trip. FlightSize better measures the actual load being placed on the network at the time a loss occurs. Tim From detlef.bosau at web.de Sat May 13 11:23:37 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 13 May 2006 20:23:37 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <004501c676ac$e0513a30$0300a8c0@int.eyematic.com> References: <004501c676ac$e0513a30$0300a8c0@int.eyematic.com> Message-ID: <44662429.7080805@web.de> Tim Dorcey wrote: >>However: It?s the purpose of CWND to estimate the path?s capcaity in >>oder to provide propoer _congestion_ control. >> >> > >I think the issue is that CWND becomes stale if the sender enters a period >where it is not filling the CWND (because the application is not providing >enough data). Suppose, CWND were to grow large during a period of heavy >transmission, and then the application slows to sending only a single > I see the point. In fact, competing flows may then occupy the path?s unused capacity. >segment per round trip. If a loss then occurs, the implication is that the >network may be too congested to send more than a single segment per round trip. FlightSize better measures the actual load being placed on the network at the time a loss occurs. > > But does the use of flightsize still guarantee fairness then? Of course, my question refers to a "full load scenario" not to an underload scenario. In fact, the notion of "fairness" might be somewhat inappropriate for flows with only sparse traffic. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From ramu20 at gmail.com Sun May 14 00:45:24 2006 From: ramu20 at gmail.com (ramu yerukala) Date: Sun, 14 May 2006 13:15:24 +0530 Subject: [e2e] statistics Message-ID: Dear friends, I need statistical analysis and econometrics material.If you have any information about these topics please provide me. thank you yours, ramu. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060514/1be85b4d/attachment.html From mallman at icir.org Sun May 14 18:22:47 2006 From: mallman at icir.org (Mark Allman) Date: Sun, 14 May 2006 21:22:47 -0400 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <001701c6750c$08c16ff0$10d24581@pcvs7> Message-ID: <20060515012247.9AFC740DA98@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060514/20ead524/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060514/20ead524/attachment.bin From mallman at icir.org Sun May 14 19:52:27 2006 From: mallman at icir.org (Mark Allman) Date: Sun, 14 May 2006 22:52:27 -0400 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <20060515012247.9AFC740DA98@lawyers.icir.org> Message-ID: <20060515025227.7AF9840DBF8@lawyers.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060514/03bc1694/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060514/03bc1694/attachment.bin From detlef.bosau at web.de Mon May 15 08:47:40 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 15 May 2006 17:47:40 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <20060515012247.9AFC740DA98@lawyers.icir.org> References: <20060515012247.9AFC740DA98@lawyers.icir.org> Message-ID: <4468A29C.9080804@web.de> Mark Allman wrote: >>can anybody explain why equation (3) in RFC 2581 is >> ssthresh = max (FlightSize / 2, 2*SMSS) >>and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used. >> >>In some postings, I found that FlightSize is usually equal to >>min(rwnd, cwnd) - but not always. According to the RFC, flightsize is >>"the amount of data that has been sent but not yet acknowledged". >> >> > >One hopes that FlightSize == cwnd. However, we introduced the >FlightSize notion in RFC2581 because this is not always the case. Some >stacks let cwnd be changed regardless of how much of the window is > ^^^^^^^^^ changed or unchanged? ; Are there actually stacks who change, i.e. decrease, cwnd when cwnd is not fully used? >actually used. So, as an example say cwnd grows to 50 segments, but >only 25 segments per RTT are being injected. In this case, upon a loss > I can pretty well imagine this scenario for persistent non FTP connections, e.g. HTTP or IMAP. >>Let's assume that 10 packets have been sent. If all 10 get lost, flightsize >>is 10 and ssthresh will be set to 5. But if only the last 4 get lost (and no >>more packets are to be sent), flightsize is 4 and ssthresh will be set to 2. >> ?? Perhaps, I should have a look at the rfc. But doesn?t flightsize mean the number of packets being actually on the fly? So, flightsize should be 10, regardingless of the number of lost packets? Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From mallman at icir.org Mon May 15 09:38:17 2006 From: mallman at icir.org (Mark Allman) Date: Mon, 15 May 2006 12:38:17 -0400 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <4468A29C.9080804@web.de> Message-ID: <20060515163817.125D877AC74@guns.icir.org> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060515/ee4ca1f9/attachment.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060515/ee4ca1f9/attachment.bin From faber at ISI.EDU Mon May 15 10:55:29 2006 From: faber at ISI.EDU (Ted Faber) Date: Mon, 15 May 2006 10:55:29 -0700 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <4465DB87.9010401@web.de> References: <001701c6750c$08c16ff0$10d24581@pcvs7> <4465DB87.9010401@web.de> Message-ID: <20060515175529.GC1444@hut.isi.edu> On Sat, May 13, 2006 at 03:13:43PM +0200, Detlef Bosau wrote: > O.k., one day later.... > > > Daniel Minder wrote: > > >Hi, > > > >can anybody explain why equation (3) in RFC 2581 is > > ssthresh = max (FlightSize / 2, 2*SMSS) > >and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was used. > > > > > at least one remark is made in rfc2581 itself: > > > Implementation Note: an easy mistake to make is to simply use cwnd, > > rather than FlightSize, which in some implementations may > > incidentally increase well beyond rwnd. > > > Hm. > > The motivation is clear: The sender must not send more data to the > network than the receiver is able / willing to accept. Apparently the motivation, like the function, is not clear. Cwnd increases by roughly 1 MSS per window of data. When calculating the window size to use to determine how many packets a TCP connection can have outstanding, the application usually does something like: cwnd = min(rwnd, cwnd). Few TCP implementations, if any, make the mistake of overunning flow control - sending more than the receiver indicates it's willing to accept. What the Note is describing is a situation in which a TCP implementation increments cwnd without bound and doesn't keep track of flightsize or uses cwnd in its congestion calculations rather than flightsize. Here's a concrete error case. You have a low-loss, nor-particularly-high-capacity network. Let the network have enough capacity that rwnd packets can be in flight. If a single TCP is on that network for a long time without loss - transferring a large file, for example - it will get into a state where the window is bounded by rwnd, cwnd may be an order of magnitude larger than rwnd, but rwnd limits the number of packets actually sent so flightsize and rwnd are the same. That is flightsize == rwin, cwnd >> rwin (where that ">>" is a mathematical ">>" not a C ">>" - much, much greater than). Now one or more other TCP sources show up. Our hero (the long-running TCP) detects a loss and cuts cwnd in half (this is the error described in the note). Because cwnd >> rwnd its sending rate does not change - the limiting factor is rwnd, not cwnd. That's clearly an error; the long-time sender should reduce its measurable sending rate, not some internal variable. Hence 2581 mandates using flightsize instead of cwnd to calculate the new cwnd, which forces a real rate reduction. (We don't just use rwnd because the actual available capacity may be the limiting factor (rwnd > line rate * delay)). We now return to e2e, now in progress. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060515/d4b192a5/attachment.bin From detlef.bosau at web.de Mon May 15 11:41:32 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 15 May 2006 20:41:32 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <20060515163817.125D877AC74@guns.icir.org> References: <20060515163817.125D877AC74@guns.icir.org> Message-ID: <4468CB5C.6080000@web.de> Mark Allman wrote: >"changed" > >There may be some stacks that do CWV and decrease cwnd when it is not > Do someone happen to know stacks which _do_ reduce / not increase CWND in case of "underload situations" and which policies are in use for that? > > >>>>Let's assume that 10 packets have been sent. If all 10 get lost, flightsize >>>>is 10 and ssthresh will be set to 5. But if only the last 4 get lost (and no >>>>more packets are to be sent), flightsize is 4 and ssthresh will be set to 2. >>>> >>>> >>>> >>?? >> >>Perhaps, I should have a look at the rfc. >> >> > >Yes. > > O.k., so I did: > FLIGHT SIZE: The amount of data that has been sent but not yet > acknowledged. > So: Daniel, when 10 Packets are sent and not yet acknowledged, flightsize is 10. Right? When do we know, if, that 10 or 4 packets have been lost and why is flightsize 10 in the first case and 4 in the second? Do you talk about a timeout situation, where 10 packets are left unacknowledged when RTO occurs and 4 in the second? Does the RFC define how "flightsize" is determined, particularly what happens in case of a timeout? IIRC in case of timeout, CWND is set to 1 (2) segments to have the sender do "stop?n wait" for one round thus having the pipe cleaned. In that case, flightsitze would be zero afterwards. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From weixl at caltech.edu Mon May 15 12:34:01 2006 From: weixl at caltech.edu (Xiaoliang (David) Wei) Date: Mon, 15 May 2006 12:34:01 -0700 (PDT) Subject: [e2e] a patch that runs Linux congestion control algorithms in NS2 Message-ID: <3684658159weixl@caltech.edu> I guess this may help some colleagues in e2e who are evaluating the performance of different TCP congestion control algorithms with NS2. The patch incorporates 9 modulized congestion control algorithms in Linux 2.6.16-3. The simulation speed and memory usage are very similar to other standard NS TCPs that we are currently using (such as Sack1) and the usage is almost the same as the current NS TCPs (except adding one command to select congestion control module). The patch can be downloaded from http://www.cs.caltech.edu/~weixl/technical/ns2linux/index.html and the page has more details on the usage, results comparing to Linux+Dummynet experiments, and the designs of the code. If you find any problem, please let me know.:) A little bit more details (See the link above for more details): 1. In the patch, I added a new TCP class which is called LinuxTCPAgent. The class loosely follows the ack processing path in Linux TCP with many simplifications. It calls congestion control modules to change the cwnd and ssthreshold, as Linux does. You can always add your own congestion control algorithms with minor modifications, as long as you get the source codes of their Linux congestion control modules. 2. I also added a new Scoreboard design which can process SACK in a similar way as Linux does, while maintaining the similar simulation speed as scoreboard-rq. 3. Some Limitations: D-SACK, F-RTO and ECN process is yet to be implemented. Also, since the TCPSink in NS2 has some difference from Linux receiver process, the cwnd trajectory from simulation results are not exactly the same as Linux experiments. -David -- Xiaoliang (David) Wei Graduate Student, CS at Caltech http://www.cs.caltech.edu/~weixl *********************************************** From fernando at gont.com.ar Mon May 15 18:03:03 2006 From: fernando at gont.com.ar (Fernando Gont) Date: Mon, 15 May 2006 22:03:03 -0300 Subject: [e2e] Legal fragment sizes Message-ID: <7.0.1.0.0.20060515220045.0625f760@gont.com.ar> Folks, I was going through the IP specs, and there was a point on which there seems to be some ambiguity (or, well, at least it's not that clear to me). I wonder what your interpretation is. Is the maximum "legal" IP payload defined by "Total_Length - IP_Header" (i.e., around 65K), or should it be considered to be the maximum payload that can be encapsulated, by using the "trick" described bellow? (i.e., which would then result in a maximum payload size of around 128K) (The "trick" would be to send a ~65K fragment with the MF bit set, followed by a second 65K fragment with an offset of ~65K) Thanks! -- Fernando Gont e-mail: fernando at gont.com.ar || fgont at acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From faber at ISI.EDU Mon May 15 18:51:44 2006 From: faber at ISI.EDU (Ted Faber) Date: Mon, 15 May 2006 18:51:44 -0700 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <446913F7.70804@web.de> References: <001701c6750c$08c16ff0$10d24581@pcvs7> <4465DB87.9010401@web.de> <20060515175529.GC1444@hut.isi.edu> <446913F7.70804@web.de> Message-ID: <20060516015144.GB64147@hut.isi.edu> On Tue, May 16, 2006 at 01:51:19AM +0200, Detlef Bosau wrote: > >Now one or more other TCP sources show up. Our hero (the long-running > >TCP) detects a loss and cuts cwnd in half (this is the error described > >in the note). Because cwnd >> rwnd its sending rate does not change - > >the limiting factor is rwnd, not cwnd. That's clearly an error; the > > > Why? > > You may argue, that you want the sender to reduce the CWND more quickly. > This is fine. > But the situation as described is not an error. > > First of all, cwnd is not cut in the half. In case of a timeout, cwnd is > reset to 2 segments. ssthresh is defined cwnd/2. > So if ssthresh exceeds the available path capacity, our hero will > encounter a congestion during slow start. Right? > So you want ssthresh to converge more quickly to an appropriate value. > This is perfectly o.k. But neigher cwnd is simply cut in the half, nor > the situation is an "error" that would make TCP fail. > > >long-time sender should reduce its measurable sending rate, not some > >internal variable. Hence 2581 mandates using flightsize instead of cwnd > > > Excuse me, but as you know the sender?s rate is determind by the ACK > rate - not by cwnd. > Why do you want to change a sender?s _rate_? > > NB: TCP is window controled, not rate controled. Let's not split hairs. I can produce a perfectly precise statement of what's going on here, too, but those details are not at issue in why flightsize is used. You can think in terms of rate or packets, whatever makes you happy. A TCP implementation is using network resources proportional to changes in either of them and TCP's use of either needs to be reduced in times of congestion. If a TCP implementation uses cwnd instead of flightsize, it can be unresponsive to congestion in a variety of plausible network conditions. That's just not true of using flightsize. The error is that if cwnd is allowed to grow larger than rwnd or the BDP and a TCP implementation only reduces its cwnd based on the current cwnd rather than basing the reduction on its flightsize (an action that the RFC defines to be a bug) that TCP sender can detect congestion and not react to it in any measurable way. I said it's sending rate doesn't change, but you'd say that the number of packets it releases into the network over an RTT doesn't change. The point is that the sender is a congestion-insenstive source; its use of network resource is constant under congestion and that's a dandy recipe for congestion collapse. OK, strictly speaking the congestion response is probably only delayed by several RTTs, but that's cold comfort if the network's collapsed in the meantime. To split the hair, that implementation is in violation of the criterion in Section 3 RFC 2581: [...] In some situations it may be beneficial for a TCP sender to be more conservative than the algorithms allow, however a TCP MUST NOT be more aggressive than the following algorithms allow (that is, MUST NOT send data when the value of cwnd computed by the following algorithms would not allow the data to be sent). Flightsize is an estimate, but it's only an overestimate in fairly perverse conditions - looping packets, delays where the variance is larger than the RTT, that kind of serious corner case where there's trouble no matter what. The RFC requires flightsize because it is almost always a conservative way to react to congestion. Being conservative is much preferred to being excessively aggressive because it makes congestion collapse much less likely. That's all there is to flightsize. It's a conservative estimate of the real sending window. Notice that all of this is only tangentially related to how much the receiver indicated it's willing to accept - the advertised receive window - which is you mentioned in the mail I first responded to. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060515/14827c73/attachment.bin From detlef.bosau at web.de Mon May 15 16:51:19 2006 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 16 May 2006 01:51:19 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <20060515175529.GC1444@hut.isi.edu> References: <001701c6750c$08c16ff0$10d24581@pcvs7> <4465DB87.9010401@web.de> <20060515175529.GC1444@hut.isi.edu> Message-ID: <446913F7.70804@web.de> Ted Faber wrote: >>> >>> >>Hm. >> >>The motivation is clear: The sender must not send more data to the >>network than the receiver is able / willing to accept. >> >> > >Apparently the motivation, like the function, is not clear. > >Cwnd increases by roughly 1 MSS per window of data. When calculating >the window size to use to determine how many packets a TCP connection >can have outstanding, the application usually does something like: cwnd >= min(rwnd, cwnd). Few TCP implementations, if any, make the mistake of >overunning flow control - sending more than the receiver indicates it's >willing to accept. > > Did I write something different? Admittedly, I misunderstood the motivation of RFC 2851 in the first run. However, what I wrote in part refered by you is nothing else than what you perhaps read in the congavoid paper, said in many lectures and wrote in many papers. What?s wrong then? >What the Note is describing is a situation in which a TCP implementation >increments cwnd without bound and doesn't keep track of flightsize or >uses cwnd in its congestion calculations rather than flightsize. > > I see. That does not change anything on the remark that "flightsize" is an estimator - and thus might be wrong. So, in principle, we have to argume why we prefer flightsize over cwnd. >Here's a concrete error case. You have a low-loss, >nor-particularly-high-capacity network. Let the network have enough >capacity that rwnd packets can be in flight. If a single TCP is on that >network for a long time without loss - transferring a large file, for >example - it will get into a state where the window is bounded by rwnd, > What?s an error with this? >cwnd may be an order of magnitude larger than rwnd, but rwnd limits the >number of packets actually sent so flightsize and rwnd are the same. >That is flightsize == rwin, cwnd >> rwin (where that ">>" is a >mathematical ">>" not a C ">>" - much, much greater than). > > Yes. And what?s the problem? SWND is limited by rwnd. The question is: What happens in case of congestion? >Now one or more other TCP sources show up. Our hero (the long-running >TCP) detects a loss and cuts cwnd in half (this is the error described >in the note). Because cwnd >> rwnd its sending rate does not change - >the limiting factor is rwnd, not cwnd. That's clearly an error; the > Why? You may argue, that you want the sender to reduce the CWND more quickly. This is fine. But the situation as described is not an error. First of all, cwnd is not cut in the half. In case of a timeout, cwnd is reset to 2 segments. ssthresh is defined cwnd/2. So if ssthresh exceeds the available path capacity, our hero will encounter a congestion during slow start. Right? So you want ssthresh to converge more quickly to an appropriate value. This is perfectly o.k. But neigher cwnd is simply cut in the half, nor the situation is an "error" that would make TCP fail. >long-time sender should reduce its measurable sending rate, not some >internal variable. Hence 2581 mandates using flightsize instead of cwnd > Excuse me, but as you know the sender?s rate is determind by the ACK rate - not by cwnd. Why do you want to change a sender?s _rate_? NB: TCP is window controled, not rate controled. >to calculate the new cwnd, which forces a real rate reduction. > > Just again: Why do you want to touch a _rate_ ? And how does CWND affect the sender?s rate? >(We don't just use rwnd because the actual available capacity may be the >limiting factor (rwnd > line rate * delay)). > We should be _extremely_ careful with delay-bandwidth products in packet switched, lossy networks. As long as you deal with a lossfree line you can describe the line?s capacity with something like an LBP. As soon as you have non negligible MAC latencies in the network or even some local recovery layer, the use of an LBP may lead to extremely wrong and misleading results, as we see particularly in the wireless literature much too often. I?ve been wrong when I did not see the scenario given by Tim Dorcey. That?s why I asked. Detlef -- Detlef Bosau Galileistrasse 30 70565 Stuttgart Mail: detlef.bosau at web.de Web: http://www.detlef-bosau.de Mobile: +49 172 681 9937 From weigengyu at hotmail.com Mon May 15 20:13:31 2006 From: weigengyu at hotmail.com (weigengyu) Date: Tue, 16 May 2006 11:13:31 +0800 Subject: [e2e] signaling performance on TCP Message-ID: Hi, Can anyone give an answer to my question? 1. SIP will be the signaling protocol for IMS in 3GPP,and SIP can be over TCP, UDP, or SCTP; 2. For SIP over TCP as signaling transfer, are there any analysis model for the performance evaluation? 3. Somebody told me that there is no problem if you allocate enough bandwidth to signaling channel. (the enough bandwidth in engineering design may be 10% of total transmission line capacity) So, is there any measured data to support the above design. 4. Could you get better performance by SIP over SCTP than SIP over TCP for signaling transfer? Gengyu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060516/ffe402e0/attachment.html From daniel.minder at informatik.uni-stuttgart.de Tue May 16 04:46:04 2006 From: daniel.minder at informatik.uni-stuttgart.de (Daniel Minder) Date: Tue, 16 May 2006 13:46:04 +0200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <20060515012247.9AFC740DA98@lawyers.icir.org> Message-ID: <00f601c678de$52f29420$10d24581@pcvs7> Hi, thank you for all your helpful comments. I think I got it :-) Mark understood my thought experiment, which indeed was carefully constructed... I thought of an application that sends data in bursts and nothing in between. Otherwise, flightsize is approximately min(cwnd, rwnd) all the time and TCP would recognise the loss by DupACKs. Thus, the burst interval must be longer than the RTO interval. Without loss, cwnd is set to RW (Section 4.1 RFC 2581). With loss, cwnd is set to LW _and_ ssthresh is reduced. In both cases, slowstart is performed, but the threshold can differ widely, depending on the position of the first lost packet in the burst. But... > In both > the cases you sketched it was 10 packets per RTT that caused the > congestion. However, in the second case we start from the notion that > there are only 4 segments in the network. This is wrong. That's it! My error was that I thought 4 lost packets is less severe than 10 lost packets. Probably, this conclusion is not right. 10 packets per RTT caused the congestion in both cases, thus the new threshold must be 10 / 2 at most. In the scenario I described, ssthresh is set to a much lower value, which is not optimal but not wrong (like the formula I suggested)... Or as Mark put it: > + This situation is conservative. The flip side (described above) is > aggressive. So, if we're going to err, this is the way to err. And we really don't know how often this situation crops up. And yes, if it were a high performance or high reliability application it would not rely on TCP alone... Thanks again! Time to close this thread :-) Daniel From perfgeek at mac.com Tue May 16 08:30:22 2006 From: perfgeek at mac.com (rick jones) Date: Tue, 16 May 2006 08:30:22 -0700 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <4468A29C.9080804@web.de> References: <20060515012247.9AFC740DA98@lawyers.icir.org> <4468A29C.9080804@web.de> Message-ID: <9e2ffd8d33d1e3549c4d1b4478850848@mac.com> On May 15, 2006, at 8:47 AM, Detlef Bosau wrote: > Mark Allman wrote: > >>> can anybody explain why equation (3) in RFC 2581 is >>> ssthresh = max (FlightSize / 2, 2*SMSS) >>> and why this has changed from RFC 2001 where min(rwnd, cwnd)/2 was >>> used. >>> >>> In some postings, I found that FlightSize is usually equal to >>> min(rwnd, cwnd) - but not always. According to the RFC, flightsize is >>> "the amount of data that has been sent but not yet acknowledged". >>> >> >> One hopes that FlightSize == cwnd. However, we introduced the >> FlightSize notion in RFC2581 because this is not always the case. >> Some >> stacks let cwnd be changed regardless of how much of the window is >> > ^^^^^^^^^ changed or unchanged? ; > > Are there actually stacks who change, i.e. decrease, cwnd when cwnd is > not fully used? If you mean say after idle or whatnot, the Linux stack in "contemporary" 2.6 kernels is doing ABC. It goes so far as to have a packet-based cwnd, only increasing it by one packet for every MSS of data exchanged. rick jones Wisdom teeth are impacted, people are affected by the effects of events From jnc at mercury.lcs.mit.edu Tue May 16 07:17:47 2006 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 16 May 2006 10:17:47 -0400 (EDT) Subject: [e2e] Legal fragment sizes Message-ID: <20060516141747.25B6C86AE8@mercury.lcs.mit.edu> > From: Fernando Gont > I was going through the IP specs, and there was a point on which there > seems to be some ambiguity ... > Is the maximum "legal" IP payload defined by "Total_Length - > IP_Header" (i.e., around 65K), or should it be considered to be the > maximum payload that can be encapsulated, by using the "trick" > described bel[]ow? ... > ... send a ~65K fragment with the MF bit set, followed by a second 65K > fragment with an offset of ~65K) Oh, my, what a clever loophole! I don't think anyone has ever thought of that (at least, I don't recall hearing of it before). My opinion is that even though the mechanism *supports* the larger size, I don't think the spirit of the spec is to allow it. I expect that most people will have also assumed that the maximum legal payload is 64K, and their code probably reflects it - i.e. they may be calculating the payload size in a 16-bit variable, they may have a maximum buffer size of 64K, etc. So many (most?) implementations won't work with a payload of more than 64K. Noel From imcdnzl at gmail.com Mon May 15 13:53:13 2006 From: imcdnzl at gmail.com (Ian McDonald) Date: Tue, 16 May 2006 08:53:13 +1200 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: <4468A29C.9080804@web.de> References: <20060515012247.9AFC740DA98@lawyers.icir.org> <4468A29C.9080804@web.de> Message-ID: > Are there actually stacks who change, i.e. decrease, cwnd when cwnd is > not fully used? > > I believe Packeteer used to do this. Not sure if it still does. -- Ian McDonald Web: http://wand.net.nz/~iam4 Blog: http://imcdnzl.blogspot.com WAND Network Research Group Department of Computer Science University of Waikato New Zealand From fred at cisco.com Tue May 16 04:14:11 2006 From: fred at cisco.com (Fred Baker) Date: Tue, 16 May 2006 07:14:11 -0400 Subject: [e2e] signaling performance on TCP In-Reply-To: References: Message-ID: <069A3058-2A8C-4A80-8EB0-C393CD5BB543@cisco.com> I don't see why SCTP would fare one iota different than TCP. In context, they have essentially equivalent message exchange. SIP on UDP would do it in less RTTs, in that there would be no SYN/SYN-ACK or FIN/FIN-ACK. I think the real difference there is debateable, though. Allocating excess capacity to a signaling channel and putting SIP into it basically allows SIP to bypass queues that form around file transfers. Personally, I think this is a good thing, and RFC 4542 supports it. On May 15, 2006, at 11:13 PM, weigengyu wrote: > Hi, > > Can anyone give an answer to my question? > > 1. SIP will be the signaling protocol for IMS in 3GPP,and SIP can > be over TCP, UDP, or SCTP; > 2. For SIP over TCP as signaling transfer, are there any analysis > model for the performance evaluation? > 3. Somebody told me that there is no problem if you allocate enough > bandwidth to signaling channel. > (the enough bandwidth in engineering design may be 10% of total > transmission line capacity) > So, is there any measured data to support the above design. > > 4. Could you get better performance by SIP over SCTP than SIP over > TCP for signaling transfer? > > Gengyu > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060516/9d00d74e/attachment.html From saikat at cs.cornell.edu Wed May 17 02:18:09 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Wed, 17 May 2006 10:18:09 +0100 Subject: [e2e] signaling performance on TCP In-Reply-To: <069A3058-2A8C-4A80-8EB0-C393CD5BB543@cisco.com> References: <069A3058-2A8C-4A80-8EB0-C393CD5BB543@cisco.com> Message-ID: <1147857489.16055.38.camel@localhost.localdomain> On Tue, 2006-05-16 at 07:14 -0400, Fred Baker wrote: > Allocating excess capacity to a signaling channel and putting SIP into > it basically allows SIP to bypass queues that form around file > transfers. Personally, I think this is a good thing, and RFC 4542 > supports it. Somewhat related to this, and more along the lines of the '0% NAT - checkmating the disconnectors' discussion we had earlier is using SIP to signal all sorts of data. In particular, using off-path signaling (SIP) for all the heavy-lifting in data communications such as discovery, mobility, protocol negotiation, authentication etc., and ultimately negotiating a light-weight data-path. More details in our recent report here [1]. [1] Towards a Secure Internet Architecture Through Signaling http://nutss.net/pub/cucs06-nutss/ The primary benefit, as you mention, is that the off-path signaling can be protected with more ease -- putting it in a separate priority queue, distributing the off-path components near the attacker (thus absorbing a DoS on the signaling path with greater ease). Furthermore with SIP, the "middle" can better understand what is going on at the "ends" and help accordingly to provide better security. Somewhat analogous to what SS7 signaling in phone networks (off-path) buys over DTMF signaling (on-path). Thoughts? -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060517/79ee0e41/attachment.bin From su.jeno at gmail.com Wed May 17 03:01:29 2006 From: su.jeno at gmail.com (Jeno Jeno) Date: Wed, 17 May 2006 15:31:29 +0530 Subject: [e2e] Legal fragment sizes In-Reply-To: <7.0.1.0.0.20060515220045.0625f760@gont.com.ar> References: <7.0.1.0.0.20060515220045.0625f760@gont.com.ar> Message-ID: The fragment-offset field is just 13-bits. So you cannot specify a fragment offset of ~64k. On 5/16/06, Fernando Gont wrote: > > Folks, > > I was going through the IP specs, and there was a point on which > there seems to be some ambiguity (or, well, at least it's not that > clear to me). I wonder what your interpretation is. > > Is the maximum "legal" IP payload defined by "Total_Length - > IP_Header" (i.e., around 65K), or should it be considered to be the > maximum payload that can be encapsulated, by using the "trick" > described bellow? (i.e., which would then result in a maximum payload > size of around 128K) > > (The "trick" would be to send a ~65K fragment with the MF bit set, > followed by a second 65K fragment with an offset of ~65K) > > Thanks! > > -- > Fernando Gont > e-mail: fernando at gont.com.ar || fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060517/29f4fa5e/attachment.html From su.jeno at gmail.com Wed May 17 03:12:25 2006 From: su.jeno at gmail.com (Jeno Jeno) Date: Wed, 17 May 2006 15:42:25 +0530 Subject: [e2e] Legal fragment sizes In-Reply-To: References: <7.0.1.0.0.20060515220045.0625f760@gont.com.ar> Message-ID: Oops, I forgot the units for fragment-offset field and total length. Yes, whatever you have mentioned should be possible. On 5/17/06, Jeno Jeno wrote: > > The fragment-offset field is just 13-bits. So you cannot > specify a fragment offset of ~64k. > > > On 5/16/06, Fernando Gont < fernando at gont.com.ar> wrote: > > > > Folks, > > > > I was going through the IP specs, and there was a point on which > > there seems to be some ambiguity (or, well, at least it's not that > > clear to me). I wonder what your interpretation is. > > > > Is the maximum "legal" IP payload defined by "Total_Length - > > IP_Header" ( i.e., around 65K), or should it be considered to be the > > maximum payload that can be encapsulated, by using the "trick" > > described bellow? (i.e., which would then result in a maximum payload > > size of around 128K) > > > > (The "trick" would be to send a ~65K fragment with the MF bit set, > > followed by a second 65K fragment with an offset of ~65K) > > > > Thanks! > > > > -- > > Fernando Gont > > e-mail: fernando at gont.com.ar || fgont at acm.org > > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.postel.org/pipermail/end2end-interest/attachments/20060517/de5347af/attachment.html From dpreed at reed.com Wed May 17 04:53:01 2006 From: dpreed at reed.com (David P. Reed) Date: Wed, 17 May 2006 07:53:01 -0400 Subject: [e2e] Legal fragment sizes In-Reply-To: References: <7.0.1.0.0.20060515220045.0625f760@gont.com.ar> Message-ID: <446B0E9D.5010708@reed.com> I'd bet there is at least one IP stack that would overwrite kernel memory if you play this trick on it. :-) Somebody who wanted to test this hypothesis could start sending lots of these "extreme" packets out to random addresses, followed by tests to see if the addressed computers crash (ping every second for five seconds). Probably you should consult your lawyer before carrying out this experiment, if you don't work for the security dept. of the organization you are probing. Jeno Jeno wrote: > Oops, I forgot the units for fragment-offset field and total > length. Yes, whatever you have mentioned should be > possible. > > On 5/17/06, *Jeno Jeno* < su.jeno at gmail.com > > wrote: > > The fragment-offset field is just 13-bits. So you cannot > specify a fragment offset of ~64k. > > > On 5/16/06, *Fernando Gont* < fernando at gont.com.ar > > wrote: > > Folks, > > I was going through the IP specs, and there was a point on which > there seems to be some ambiguity (or, well, at least it's not that > clear to me). I wonder what your interpretation is. > > Is the maximum "legal" IP payload defined by "Total_Length - > IP_Header" ( i.e., around 65K), or should it be considered to > be the > maximum payload that can be encapsulated, by using the "trick" > described bellow? (i.e., which would then result in a maximum > payload > size of around 128K) > > (The "trick" would be to send a ~65K fragment with the MF bit set, > followed by a second 65K fragment with an offset of ~65K) > > Thanks! > > -- > Fernando Gont > e-mail: fernando at gont.com.ar || > fgont at acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > > > From fernando at gont.com.ar Wed May 17 05:33:28 2006 From: fernando at gont.com.ar (Fernando Gont) Date: Wed, 17 May 2006 09:33:28 -0300 Subject: [e2e] Legal fragment sizes In-Reply-To: <446B0E9D.5010708@reed.com> References: <7.0.1.0.0.20060515220045.0625f760@gont.com.ar> <446B0E9D.5010708@reed.com> Message-ID: <7.0.1.0.0.20060517093039.02067670@gont.com.ar> At 08:53 17/05/2006, David P. Reed wrote: IIRC, the "Ping of Death" attack that lead to a blue-screen in Windows exploited this idea. There might still be other systems with problems to handle these packets.... Kindest regards, Fernando Gont >I'd bet there is at least one IP stack that would overwrite kernel >memory if you play this trick on it. :-) > >Somebody who wanted to test this hypothesis could start sending lots >of these "extreme" packets out to random addresses, followed by >tests to see if the addressed computers crash (ping every second for >five seconds). > >Probably you should consult your lawyer before carrying out this >experiment, if you don't work for the security dept. of the >organization you are probing. > >Jeno Jeno wrote: >>Oops, I forgot the units for fragment-offset field and total >>length. Yes, whatever you have mentioned should be >>possible. >> >>On 5/17/06, *Jeno Jeno* < su.jeno at gmail.com >>> wrote: >> >> The fragment-offset field is just 13-bits. So you cannot >> specify a fragment offset of ~64k. >> >> >> On 5/16/06, *Fernando Gont* < fernando at gont.com.ar >> > wrote: >> >> Folks, >> >> I was going through the IP specs, and there was a point on which >> there seems to be some ambiguity (or, well, at least it's not that >> clear to me). I wonder what your interpretation is. >> >> Is the maximum "legal" IP payload defined by "Total_Length - >> IP_Header" ( i.e., around 65K), or should it be considered to >> be the >> maximum payload that can be encapsulated, by using the "trick" >> described bellow? (i.e., which would then result in a maximum >> payload >> size of around 128K) >> >> (The "trick" would be to send a ~65K fragment with the MF bit set, >> followed by a second 65K fragment with an offset of ~65K) >> >> Thanks! >> >> -- >> Fernando Gont >> e-mail: fernando at gont.com.ar || >> fgont at acm.org >> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >> >> >> >> >> >> > >-- >Fernando Gont >e-mail: fernando at gont.com.ar || fgont at acm.org >PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From dpreed at reed.com Wed May 17 07:27:25 2006 From: dpreed at reed.com (David P. Reed) Date: Wed, 17 May 2006 10:27:25 -0400 Subject: [e2e] Legal fragment sizes In-Reply-To: References: Message-ID: <446B32CD.5080104@reed.com> In my comment about this proposed "jumbo datagram" trick, I wasn't arguing that it was legal or illegal, of course. Thanks, Michael, for teaching me more about PoD, which I only knew the name of, not the contents. Seems like the Internet immune system is probably well immunized against this risk given prior pandemics, but you never know if new stacks are being born unvaccinated out there among developers who haven't heard of PoD, or find it difficult to interpret the RFC's. From faber at ISI.EDU Wed May 17 10:17:32 2006 From: faber at ISI.EDU (Ted Faber) Date: Wed, 17 May 2006 10:17:32 -0700 Subject: [e2e] Question on ssthresh setting in RFC 2581 In-Reply-To: References: <20060515012247.9AFC740DA98@lawyers.icir.org> <4468A29C.9080804@web.de> Message-ID: <20060517171732.GD11192@hut.isi.edu> On Tue, May 16, 2006 at 08:53:13AM +1200, Ian McDonald wrote: > >Are there actually stacks who change, i.e. decrease, cwnd when cwnd is > >not fully used? > > > > > I believe Packeteer used to do this. Not sure if it still does. I was under the perhaps-mistaken impression that Packeteer rewrote the advertised window field in packets in flight. They caused senders to slow down by limiting rwnd, not cwnd. It seems likely that the designers of the advertised window did not forsee this use of the field, but you never know. I've been told in private e-mail that senders have been encouraged to ignore rwnd in the past. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060517/348054cd/attachment.bin From shane at ee.columbia.edu Wed May 17 19:34:27 2006 From: shane at ee.columbia.edu (Shane B. Eisenman) Date: Wed, 17 May 2006 22:34:27 -0400 (EDT) Subject: [e2e] People-centric urban sensing Message-ID: Hello, Following on from Jon's email: its spring, time for another architecture, we've been working on a strawman architecture - 100% conjecture - for large scale sensing: http://www.cs.dartmouth.edu/~niclane/pubs/metrosense.pdf Any comments are appreciated. Best, Shane ------------------------------------ http://www.comet.columbia.edu/~shane From best at cs.bu.edu Thu May 18 05:29:49 2006 From: best at cs.bu.edu (Azer Bestavros) Date: Thu, 18 May 2006 08:29:49 -0400 Subject: [e2e] CFP: HotWeb -- IEEE Workshop on Hot Topics in Web Systems and Technologies Message-ID: <0511C607B17F804EBE96FFECD1FD9859D85C97@cs-exs2.cs-nt.bu.edu> Call for Papers HotWeb 2006: First IEEE Workshop on Hot Topics in Web Systems and Technologies Boston, Massachusetts, USA November 13-15, 2006 ****** Submission Deadline: June 15, 2006 ****** HotWeb is a forum that brings together researchers and practitioners interested in the design, implementation, and evaluation of Internet systems and applications. The workshop seeks to act as a conduit for the presentation of novel approaches used in support of performance, scalability, and security of Internet applications, including Web searching and indexing, content distribution and delivery networks, Web services, and edge and grid computing. Particular areas of interest include, but are not limited to: * Content delivery architectures * Peer-to-Peer systems * Support for mobile and wireless systems * Web caching and replication * Edge services and dynamic content delivery * Multimedia content distribution * Content placement and request routing * Overlay networks * Measurement studies of deployed systems * Security and privacy * Wide-area upload and content gathering * Novel web-based applications * Web/database integration * Internet telephony * Information retrieval and searching * Electronic commerce Papers describing timely research contributions in HotWeb's areas of interest are solicited. Papers reporting on initial results as well as papers discussing mature research projects or case studies of deployed systems are equally sought out. Submitted papers must be neither previously published nor under review by another workshop, conference or journal. Only electronic submissions in PDF will be accepted. Submitted papers must be written in English, must be no longer than 12 pages, must render without error using standard PDF viewing tools, must print on US-Letter-sized paper, and must conform to standard IEEE conference submission guidelines. To submit a paper to HotWeb 2006, please follow the instructions available at the workshop's web site at: http://www.cs.bu.edu/pub/hotweb06 GENERAL CHAIR: Azer Bestavros, Boston University PROGRAM CHAIRS: Bruce Maggs, Carnegie Mellon & Akamai PROGRAM COMMITTEE * Pei Cao, Stanford * Armando Fox, Stanford * Arun Iyengar, IBM * Leonidas Kontothanassis, Intel * Bruce Maggs, Carnegie Mellon & Akamai * Venkat Padmanabhan, Microsoft * Vivek Pai, Princeton * Pablo Rodriquez Rodriquez, Microsoft * Ramesh Sitaraman, U. Mass & Akamai * Oliver Spatscheck, AT&T * Andrew Tomkins, Yahoo! * Steve Vinoski, IONA Technologies * Tina Wong, Carnegie Mellon STEERING COMMITTEE: * Azer Bestavros, Boston University * Fred Douglis, IBM * Jeff Dean, Google * Arun Iyengar, IBM * Michael Rabinovich, Case Western Reserve * Pablo Rodriguez Rodriguez, Microsoft * Prabhakar Raghavan, Yahoo! IMPORTANT DATES: * Submission Deadline: June 15, 2006 * Notification of Acceptance: July 31, 2006 * Camera Ready Due: September 15, 2006 * Workshop: November 13-15, 2006 HOTWEB 2006 WEB SITE: http://www.cs.bu.edu/pub/hotweb06 From dhc2 at dcrocker.net Sat May 20 07:56:28 2006 From: dhc2 at dcrocker.net (Dave Crocker) Date: Sat, 20 May 2006 07:56:28 -0700 Subject: [e2e] new network architecture idea - In-Reply-To: References: Message-ID: <446F2E1C.9000309@dcrocker.net> Jon Crowcroft wrote: > Its that time of year for a new network architecture - rather than build an overlay on IP > I reckon the way to build a DOS proof, multipath, resilient network that can function in > low or high bandwidth, fixed or mobile, lossy or reliable, connected or disrupted, topologies > is to built the packet protocol over an overlay - so my bif is to rebuild > IP on Swarms (initial prototype is IPv6 on bittorrent) > > packet swarming systems are nice because > i) you go download your packet, so noone can dos you how do you know to go get the packet? Anyhow, for some reason, this proposal reminds me of the brief Datamation article, in the 70's during the debate over structured programming. It proposed an alternative to the GOTO, called COMEFROM. It wasn't until the end of the article that I realized it was a spoof. d/ From Jon.Crowcroft at cl.cam.ac.uk Sat May 20 08:43:00 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 20 May 2006 16:43:00 +0100 Subject: [e2e] new network architecture idea - In-Reply-To: Message from Dave Crocker of "Sat, 20 May 2006 07:56:28 PDT." <446F2E1C.9000309@dcrocker.net> Message-ID: well, an _implementation_ would be to use digital fountain/multicast - you join the right group(s) and packets start to flow... but thats just one _possible_ implementation...another (typcially, not called "multicast" but the exact same idea) is pub/sub with network coding too, it might need somethign a bit different In missive <446F2E1C.9000309 at dcrocker.net>, Dave Crocker typed: >>Jon Crowcroft wrote: >>> Its that time of year for a new network architecture - rather than build an overlay on IP >>> I reckon the way to build a DOS proof, multipath, resilient network that can function in >>> low or high bandwidth, fixed or mobile, lossy or reliable, connected or disrupted, topologies >>> is to built the packet protocol over an overlay - so my bif is to rebuild >>> IP on Swarms (initial prototype is IPv6 on bittorrent) >>> >>> packet swarming systems are nice because >>> i) you go download your packet, so noone can dos you >> >> >>how do you know to go get the packet? >> >> >> >>Anyhow, for some reason, this proposal reminds me of the brief Datamation >>article, in the 70's during the debate over structured programming. It proposed >>an alternative to the GOTO, called COMEFROM. >> >>It wasn't until the end of the article that I realized it was a spoof. >> >>d/ >> cheers jon From fergdawg at netzero.net Sat May 20 09:17:45 2006 From: fergdawg at netzero.net (Fergie) Date: Sat, 20 May 2006 16:17:45 GMT Subject: [e2e] new network architecture idea - Message-ID: <20060520.091808.19753.1274449@webmail29.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060520/7b8d52a2/attachment.ksh From fergdawg at netzero.net Sat May 20 12:16:06 2006 From: fergdawg at netzero.net (Fergie) Date: Sat, 20 May 2006 19:16:06 GMT Subject: [e2e] new network architecture idea - Message-ID: <20060520.121650.11238.1270824@webmail39.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060520/0f6281e7/attachment.ksh From swb at employees.org Sat May 20 16:46:42 2006 From: swb at employees.org (Scott W Brim) Date: Sat, 20 May 2006 19:46:42 -0400 Subject: [e2e] new network architecture idea - In-Reply-To: <20060520.121650.11238.1270824@webmail39.lax.untd.com> References: <20060520.121650.11238.1270824@webmail39.lax.untd.com> Message-ID: <446FAA62.5070001@employees.org> On 05/20/2006 15:16 PM, Fergie allegedly wrote: > This is, I think, a fascinating concept worth persuing. at what layer? Do "service discovery" and web services "ws-eventing" give you what you want? From fergdawg at netzero.net Sat May 20 17:58:07 2006 From: fergdawg at netzero.net (Fergie) Date: Sun, 21 May 2006 00:58:07 GMT Subject: [e2e] new network architecture idea - Message-ID: <20060520.175812.14160.1273564@webmail24.lax.untd.com> An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://www.postel.org/pipermail/end2end-interest/attachments/20060521/bdd6ee55/attachment.ksh From fred at cisco.com Sat May 20 12:11:31 2006 From: fred at cisco.com (Fred Baker) Date: Sat, 20 May 2006 12:11:31 -0700 Subject: [e2e] new network architecture idea - In-Reply-To: <20060520.091808.19753.1274449@webmail29.lax.untd.com> References: <20060520.091808.19753.1274449@webmail29.lax.untd.com> Message-ID: On May 20, 2006, at 4:17 PM, Fergie wrote: > pub/sub how, exactly? I think of pub/sub as an application concept: I have content I am willing to share, and someone else tells me that they are interested. In this context, I should think the receiving node would tell the sending node that it was interested if the other guy wanted to talk. So now I wonder how this works. I walk into a meeting room and open my laptop. It joins a wireless network, and voila! the peers and servers I am interested in all tell me that they are publishing something to which I might subscribe? I think this is going to require some work to describe. At the end of the day, it is never the receiver that knows there is content out there to receive; it is always the one who sends it who has that knowledge. From fred at cisco.com Sat May 20 12:15:11 2006 From: fred at cisco.com (Fred Baker) Date: Sat, 20 May 2006 12:15:11 -0700 Subject: [e2e] new network architecture idea - In-Reply-To: References: Message-ID: that begs the question. When I join a group, I send a message *to* someone (a local router) indicating that I wish to join. It doesn't ask to receive something *from* me. On May 20, 2006, at 8:43 AM, Jon Crowcroft wrote: > well, an _implementation_ would be to use digital fountain/ > multicast - you join the right group(s) > and packets start to flow... From Jon.Crowcroft at cl.cam.ac.uk Sun May 21 15:45:57 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 21 May 2006 23:45:57 +0100 Subject: [e2e] new network architecture idea - In-Reply-To: Message from Fred Baker of "Sat, 20 May 2006 12:11:31 PDT." Message-ID: pub/sub in the original implementation by tibco et al mapped straight onto multicast AND had its own transport (PGM) which was a neat architecture BUT i am not talking about simply pub-/sub - that was for illustration reasons... at the end of th day, the receiver has some stuff they are interstd in - you buy newspaer x, or you tune to tv or radio station y/z OR you subscribe to some belief....all of this is *AND should be* receiver interst based, not sender based even email (I'm not interested in most the spam i get - this is an indication of a major architectual error that the cost of an activity for a pasrticipant doesnt match the need - and the resource expended isnt paid for by the right party) packet swarming is a simple idea - you need to buy into some complete changes of ways of building net s (you dont send to an address - you percolate traffic to a repository cloud which intersted parties may pick packets out of - this works even for 1-1 commnication (if you send an email to e2e but cc: me, i might see it as i probably "subscribe" to messages with some field about me - hey, i am sufficiently egomaniacal to want to see stuff like that:) the technoligy exiwts now to do this at a packet level, not just an application level In missive , Fred Baker typed: >> >>On May 20, 2006, at 4:17 PM, Fergie wrote: >> >>> pub/sub how, exactly? >> >>I think of pub/sub as an application concept: I have content I am >>willing to share, and someone else tells me that they are interested. >>In this context, I should think the receiving node would tell the >>sending node that it was interested if the other guy wanted to talk. >> >>So now I wonder how this works. I walk into a meeting room and open >>my laptop. It joins a wireless network, and voila! the peers and >>servers I am interested in all tell me that they are publishing >>something to which I might subscribe? >> >>I think this is going to require some work to describe. At the end of >>the day, it is never the receiver that knows there is content out >>there to receive; it is always the one who sends it who has that >>knowledge. cheers jon From dpreed at reed.com Sun May 21 20:00:05 2006 From: dpreed at reed.com (David P. Reed) Date: Sun, 21 May 2006 23:00:05 -0400 Subject: [e2e] new network architecture idea - In-Reply-To: References: Message-ID: <44712935.9010509@reed.com> Actually, COMEFROM is the correct analogy, and it makes more sense in this case than it might first appear. Except for blogs, most network communications are driven by the receiver (why would you send to some device that hadn't already indicated interest in reception?) It seems to me that putting the listener firmly at the center of communications activity grounds every workable/working architecture. TCP flows are receiver driven, HTTP is receiver driven, internet multicast is receiver driven, ... one wonders if hidden in this is a principle at the level of the "end to end argument" in its generality and utility. I tend to use it in my designs... When things go wrong (black holes, DDoS, ..., even spam and the blogosphere) is when activities are "sender driven" without regard for the wishes or needs of the receivers. But Jon's idea is too good, I think, to be wasted in the chatter here on the E2E list. I think some folks should take it much more seriously than an April 1 note, which I am sure is the farthest from Jon's intent... Jon Crowcroft wrote: > well, an _implementation_ would be to use digital fountain/multicast - you join the right group(s) > and packets start to flow... > > but thats just one _possible_ implementation...another (typcially, not called "multicast" but the exact same idea) > is pub/sub > > > with network coding too, it might need somethign a bit different > In missive <446F2E1C.9000309 at dcrocker.net>, Dave Crocker typed: > > >>Jon Crowcroft wrote: > >>> Its that time of year for a new network architecture - rather than build an overlay on IP > >>> I reckon the way to build a DOS proof, multipath, resilient network that can function in > >>> low or high bandwidth, fixed or mobile, lossy or reliable, connected or disrupted, topologies > >>> is to built the packet protocol over an overlay - so my bif is to rebuild > >>> IP on Swarms (initial prototype is IPv6 on bittorrent) > >>> > >>> packet swarming systems are nice because > >>> i) you go download your packet, so noone can dos you > >> > >> > >>how do you know to go get the packet? > >> > >> > >> > >>Anyhow, for some reason, this proposal reminds me of the brief Datamation > >>article, in the 70's during the debate over structured programming. It proposed > >>an alternative to the GOTO, called COMEFROM. > >> > >>It wasn't until the end of the article that I realized it was a spoof. > >> > >>d/ > >> > > cheers > > jon > > > > From huitema at windows.microsoft.com Sun May 21 21:20:45 2006 From: huitema at windows.microsoft.com (Christian Huitema) Date: Sun, 21 May 2006 21:20:45 -0700 Subject: [e2e] new network architecture idea - In-Reply-To: <44712935.9010509@reed.com> Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064BA0671@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> > When things go wrong (black holes, DDoS, ..., even spam and the > blogosphere) is when activities are "sender driven" without regard for > the wishes or needs of the receivers. You can definitely accomplish a receiver driven DDOS. Assume a large band of zombies, and instruct them to all receive a large set of large pages from the target server. Pretty soon, the server's sending capacity will be saturated. Voila, receiver driven DDOS. In Jon's proposal, the principle that prevent's DOS is swarming. Swarming allows the data to be served from any valid copy, not just the initial publisher. In my example, if swarming worked, each zombie will become a potential surrogate for the server, and the server's resource would remain available. I suspect however that the zombies may try to not fully cooperate with the swarming... -- Christian Huitema From Jon.Crowcroft at cl.cam.ac.uk Sun May 21 23:36:19 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 22 May 2006 07:36:19 +0100 Subject: [e2e] new network architecture idea - In-Reply-To: Message from "Christian Huitema" of "Sun, 21 May 2006 21:20:45 PDT." <70C6EFCDFC8AAD418EF7063CD132D064BA0671@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: exactly swarming systems also have a variety of mechanisms built into the swarm analogy of a "routing" substrate, that match incentives for download/receiver, versus forwarding which make it hard for a zombie farm to dent the system unless there are a significant fraction of nodes subverted (significant being >33% or 50% typically depending on the algorithm) - frankily,m a system with 1/3 or more nodes subverted is so badly infiltrated that I have no idea what the bad guys are still after in it:) the other thing with swarms is that not only is hard to overload the swarm (as it isn't a _point_ service) but its also hard to do topological attacks packet swarming - an idea whose time has comefrom... In missive <70C6EFCDFC8AAD418EF7063CD132D064BA0671 at WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>, "Christian Huitema" typed: >>> When things go wrong (black holes, DDoS, ..., even spam and the >>> blogosphere) is when activities are "sender driven" without regard for >>> the wishes or needs of the receivers. >> >>You can definitely accomplish a receiver driven DDOS. Assume a large >>band of zombies, and instruct them to all receive a large set of large >>pages from the target server. Pretty soon, the server's sending capacity >>will be saturated. Voila, receiver driven DDOS. >> >>In Jon's proposal, the principle that prevent's DOS is swarming. >>Swarming allows the data to be served from any valid copy, not just the >>initial publisher. In my example, if swarming worked, each zombie will >>become a potential surrogate for the server, and the server's resource >>would remain available. I suspect however that the zombies may try to >>not fully cooperate with the swarming... >> >>-- Christian Huitema cheers jon From huitema at windows.microsoft.com Mon May 22 00:16:24 2006 From: huitema at windows.microsoft.com (Christian Huitema) Date: Mon, 22 May 2006 00:16:24 -0700 Subject: [e2e] new network architecture idea - In-Reply-To: Message-ID: <70C6EFCDFC8AAD418EF7063CD132D064BA06A3@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Well, you trade DDOS for the sibyl attack. The problem is that in most P2P systems there is little "barrier to entry". Each zombie can manifest itself as multiple nodes, virtual nodes if you want. They can potentially have enough virtual nodes to represent 1/3rd of the population. If you don't believe that's possible, consider that 70% of e-mail is spam... > swarming systems also have a variety of mechanisms built into the swarm > analogy > of a "routing" substrate, that match incentives for download/receiver, > versus forwarding > which make it hard for a zombie farm to dent the system unless there are > a significant fraction of nodes subverted (significant being >33% or 50% > typically depending on the algorithm) - frankily,m a system with 1/3 or > more nodes subverted is > so badly infiltrated that I have no idea what the bad guys are still after > in it:) > > the other thing with swarms is that not only is hard to overload the swarm > (as it isn't a _point_ service) > but its also hard to do topological attacks > > packet swarming - an idea whose time has comefrom... > > In missive <70C6EFCDFC8AAD418EF7063CD132D064BA0671 at WIN-MSG- > 21.wingroup.windeploy.ntdev.microsoft.com>, "Christian Huitema" typed: > > >>> When things go wrong (black holes, DDoS, ..., even spam and the > >>> blogosphere) is when activities are "sender driven" without regard > for > >>> the wishes or needs of the receivers. > >> > >>You can definitely accomplish a receiver driven DDOS. Assume a large > >>band of zombies, and instruct them to all receive a large set of large > >>pages from the target server. Pretty soon, the server's sending > capacity > >>will be saturated. Voila, receiver driven DDOS. > >> > >>In Jon's proposal, the principle that prevent's DOS is swarming. > >>Swarming allows the data to be served from any valid copy, not just the > >>initial publisher. In my example, if swarming worked, each zombie will > >>become a potential surrogate for the server, and the server's resource > >>would remain available. I suspect however that the zombies may try to > >>not fully cooperate with the swarming... > >> > >>-- Christian Huitema > > cheers > > jon > From Jon.Crowcroft at cl.cam.ac.uk Mon May 22 01:32:06 2006 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 22 May 2006 09:32:06 +0100 Subject: [e2e] new network architecture idea - In-Reply-To: Message from "Christian Huitema" of "Mon, 22 May 2006 00:16:24 PDT." <70C6EFCDFC8AAD418EF7063CD132D064BA06A3@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> Message-ID: In missive <70C6EFCDFC8AAD418EF7063CD132D064BA06A3 at WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>, "Christian Huitema" typed: >>Well, you trade DDOS for the sibyl attack. The problem is that in most >>P2P systems there is little "barrier to entry". Each zombie can manifest >>itself as multiple nodes, virtual nodes if you want. They can >>potentially have enough virtual nodes to represent 1/3rd of the >>population. If you don't believe that's possible, consider that 70% of >>e-mail is spam... in my conjectured architecture, most nodes collaborate to elimiate sybils by witnessing the source and attesting to its uniqueness and authenticity - since there's no _destination_, the spammer (if your application is unsolicted content) is shouting in a vacuum >> >>> swarming systems also have a variety of mechanisms built into the >>swarm >>> analogy >>> of a "routing" substrate, that match incentives for download/receiver, >>> versus forwarding >>> which make it hard for a zombie farm to dent the system unless there >>are >>> a significant fraction of nodes subverted (significant being >33% or >>50% >>> typically depending on the algorithm) - frankily,m a system with 1/3 >>or >>> more nodes subverted is >>> so badly infiltrated that I have no idea what the bad guys are still >>after >>> in it:) >>>=20 >>> the other thing with swarms is that not only is hard to overload the >>swarm >>> (as it isn't a _point_ service) >>> but its also hard to do topological attacks >>>=20 >>> packet swarming - an idea whose time has comefrom... >>>=20 >>> In missive <70C6EFCDFC8AAD418EF7063CD132D064BA0671 at WIN-MSG- >>> 21.wingroup.windeploy.ntdev.microsoft.com>, "Christian Huitema" typed: >>>=20 >>> >>> When things go wrong (black holes, DDoS, ..., even spam and the >>> >>> blogosphere) is when activities are "sender driven" without >>regard >>> for >>> >>> the wishes or needs of the receivers. >>> >> >>> >>You can definitely accomplish a receiver driven DDOS. Assume a >>large >>> >>band of zombies, and instruct them to all receive a large set of >>large >>> >>pages from the target server. Pretty soon, the server's sending >>> capacity >>> >>will be saturated. Voila, receiver driven DDOS. >>> >> >>> >>In Jon's proposal, the principle that prevent's DOS is swarming. >>> >>Swarming allows the data to be served from any valid copy, not just >>the >>> >>initial publisher. In my example, if swarming worked, each zombie >>will >>> >>become a potential surrogate for the server, and the server's >>resource >>> >>would remain available. I suspect however that the zombies may try >>to >>> >>not fully cooperate with the swarming... >>> >> >>> >>-- Christian Huitema >>>=20 >>> cheers >>>=20 >>> jon >>>=20 >> cheers jon From dpreed at reed.com Mon May 22 02:05:00 2006 From: dpreed at reed.com (David P. Reed) Date: Mon, 22 May 2006 05:05:00 -0400 Subject: [e2e] new network architecture idea - In-Reply-To: References: Message-ID: <44717EBC.7080407@reed.com> "shouting in a vacuum" is probably the wrong metaphor. To make Jon's vision practical, the act of "offering to serve content" needs to impose no costs on others. Thus it cannot include as equivalent actions such as "advertising" - since "advertising" is "sending". The concept of "advertising" is like "shouting". It imposes a cost on others. Jon's vision in its extreme may prove unrealizable. But it's worth thinking through how you would bootstrap such an extreme idea. A simple start would be to say that one could never receive more packets than one authorizes to be sent to oneself. This rule, in and of itself, is not the normal network communications rule, which starts off by allowing any packet to be sent. It does not prevent intermediate nodes from deciding to request packets on a receiver's behalf, before the receiver requests them. But in such a case, it is clear that the intermediate node takes on its own shoulders the burden of holding the packets, and cannot blame the receiver for the imposed cost of anticipating demand. In other words, it is acting like a "retailer" that stocks goods in anticipation of the needs in its neighborhood for certain goods. In return, it gets to charge a profit for the shortened latency in delivering those goods, balanced against the risk that those goods are not requested. In this way, swarms can be built. But the key thing is that costs are not imposed merely by production of packets. The producer assumes the risk, and it can encourage intermediaries to assume risks, but it cannot transfer the cost to unwitting recipients. DNS is constructed in almost this way. It does not "advertise", and it is not the source of "spam", nor is it the recipient of "spam" at the packet level. However, the one way in which DNS does not work this way is that it is obligated to *any* requestor. So to fix spam to work this way, one would have to arrange that DNS servers could not handle requests from any place where they did not have a prior authorization outstanding. In a practical sense, one could arrange this to be the case by representing authorization via an encryption protocol: only those nodes who have prior authorization can construct valid requests to any particular DNS server. Since this is a thought experiment, and a riff on Jon's proposal, I'll stop there.... Jon Crowcroft wrote: > In missive <70C6EFCDFC8AAD418EF7063CD132D064BA06A3 at WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>, "Christian Huitema" typed: > > >>Well, you trade DDOS for the sibyl attack. The problem is that in most > >>P2P systems there is little "barrier to entry". Each zombie can manifest > >>itself as multiple nodes, virtual nodes if you want. They can > >>potentially have enough virtual nodes to represent 1/3rd of the > >>population. If you don't believe that's possible, consider that 70% of > >>e-mail is spam... > > in my conjectured architecture, most nodes collaborate to elimiate sybils by witnessing the source > and attesting to its uniqueness and authenticity - since there's no _destination_, the spammer > (if your application is unsolicted content) > is shouting in a vacuum > >> > >>> swarming systems also have a variety of mechanisms built into the > >>swarm > >>> analogy > >>> of a "routing" substrate, that match incentives for download/receiver, > >>> versus forwarding > >>> which make it hard for a zombie farm to dent the system unless there > >>are > >>> a significant fraction of nodes subverted (significant being >33% or > >>50% > >>> typically depending on the algorithm) - frankily,m a system with 1/3 > >>or > >>> more nodes subverted is > >>> so badly infiltrated that I have no idea what the bad guys are still > >>after > >>> in it:) > >>>=20 > >>> the other thing with swarms is that not only is hard to overload the > >>swarm > >>> (as it isn't a _point_ service) > >>> but its also hard to do topological attacks > >>>=20 > >>> packet swarming - an idea whose time has comefrom... > >>>=20 > >>> In missive <70C6EFCDFC8AAD418EF7063CD132D064BA0671 at WIN-MSG- > >>> 21.wingroup.windeploy.ntdev.microsoft.com>, "Christian Huitema" typed: > >>>=20 > >>> >>> When things go wrong (black holes, DDoS, ..., even spam and the > >>> >>> blogosphere) is when activities are "sender driven" without > >>regard > >>> for > >>> >>> the wishes or needs of the receivers. > >>> >> > >>> >>You can definitely accomplish a receiver driven DDOS. Assume a > >>large > >>> >>band of zombies, and instruct them to all receive a large set of > >>large > >>> >>pages from the target server. Pretty soon, the server's sending > >>> capacity > >>> >>will be saturated. Voila, receiver driven DDOS. > >>> >> > >>> >>In Jon's proposal, the principle that prevent's DOS is swarming. > >>> >>Swarming allows the data to be served from any valid copy, not just > >>the > >>> >>initial publisher. In my example, if swarming worked, each zombie > >>will > >>> >>become a potential surrogate for the server, and the server's > >>resource > >>> >>would remain available. I suspect however that the zombies may try > >>to > >>> >>not fully cooperate with the swarming... > >>> >> > >>> >>-- Christian Huitema > >>>=20 > >>> cheers > >>>=20 > >>> jon > >>>=20 > >> > > cheers > > jon > > > > From jms at central.cis.upenn.edu Mon May 22 07:31:58 2006 From: jms at central.cis.upenn.edu (Jonathan M. Smith) Date: Mon, 22 May 2006 10:31:58 -0400 (EDT) Subject: [e2e] new network architecture idea - In-Reply-To: References: Message-ID: Jon: Isn't this architectural scheme similar in spirit to the Linda distributed system of Gelernter and colleagues? -JMS ------------------------------------------------------------------------- Jonathan M. Smith Olga and Alberico Pompa Professor of Engineering and Applied Science Professor of Computer and Information Science, University of Pennsylvania Levine Hall, 3330 Walnut Street, Philadelphia, PA 19104 On Sun, 21 May 2006, Jon Crowcroft wrote: > pub/sub in the original implementation by tibco et al mapped straight onto multicast > AND had its own transport (PGM) which was a neat architecture > > BUT i am not talking about simply pub-/sub - that was for illustration reasons... > > at the end of th day, the receiver has some stuff they are interstd in - you buy > newspaer x, or you tune to tv or radio station y/z OR you subscribe to some > belief....all of this is *AND should be* receiver interst based, not sender based > > even email (I'm not interested in most the spam i get - this is an indication of a major architectual error > that the cost of an activity for a pasrticipant doesnt match the need - > and the resource expended isnt paid for by the right party) > > packet swarming is a simple idea - you need to buy into some complete changes of > ways of building net s (you dont send to an address - you percolate traffic to a repository > cloud which intersted parties may pick packets out of - this works even for 1-1 commnication > (if you send an email to e2e but cc: me, i might see it as i probably "subscribe" to messages > with some field about me - hey, i am sufficiently egomaniacal to want to see stuff like that:) > > the technoligy exiwts now to do this at a packet level, not just an application level > > In missive , Fred Baker typed: > > >> > >>On May 20, 2006, at 4:17 PM, Fergie wrote: > >> > >>> pub/sub how, exactly? > >> > >>I think of pub/sub as an application concept: I have content I am > >>willing to share, and someone else tells me that they are interested. > >>In this context, I should think the receiving node would tell the > >>sending node that it was interested if the other guy wanted to talk. > >> > >>So now I wonder how this works. I walk into a meeting room and open > >>my laptop. It joins a wireless network, and voila! the peers and > >>servers I am interested in all tell me that they are publishing > >>something to which I might subscribe? > >> > >>I think this is going to require some work to describe. At the end of > >>the day, it is never the receiver that knows there is content out > >>there to receive; it is always the one who sends it who has that > >>knowledge. > > cheers > > jon > From braden at ISI.EDU Mon May 22 10:59:05 2006 From: braden at ISI.EDU (Bob Braden) Date: Mon, 22 May 2006 10:59:05 -0700 (PDT) Subject: [e2e] Legal fragment sizes Message-ID: <200605221759.KAA13619@gra.isi.edu> *> *> Is the maximum "legal" IP payload defined by "Total_Length - *> IP_Header" (i.e., around 65K), or should it be considered to be the *> maximum payload that can be encapsulated, by using the "trick" *> described bellow? (i.e., which would then result in a maximum payload *> size of around 128K) *> I am certain that the intent of IP was to implement a max message size of 65K. However, Jon would have enjoyed your creativity! Bob Braden From braden at ISI.EDU Mon May 22 11:01:38 2006 From: braden at ISI.EDU (Bob Braden) Date: Mon, 22 May 2006 11:01:38 -0700 (PDT) Subject: [e2e] Legal fragment sizes Message-ID: <200605221801.LAA13637@gra.isi.edu> *> *> I expect that most people will have also assumed that the maximum legal *> payload is 64K, and their code probably reflects it - i.e. they may be *> calculating the payload size in a 16-bit variable, they may have a maximum *> buffer size of 64K, etc. So many (most?) implementations won't work with a *> payload of more than 64K. *> *> Noel *> I wonder how many stacks we can crash this way!? Bob Braden From Christian.Tschudin at unibas.ch Tue May 23 01:44:06 2006 From: Christian.Tschudin at unibas.ch (Christian Tschudin) Date: Tue, 23 May 2006 10:44:06 +0200 (MET DST) Subject: [e2e] new network architecture idea - In-Reply-To: References: Message-ID: On Mon, 22 May 2006, Jonathan M. Smith wrote: > Jon: > Isn't this architectural scheme similar in spirit to the Linda > distributed system of Gelernter and colleagues? > -JMS Hi Jonathan, it could well be that running Linda over a swarm is easy because of "architectural similarity", however there remains a considerable crevice between Linda's global + reliable + persistent tuple space and IP on swarms. SUperficially, both do "filtering", but I think that the transient and best effort characteristics of IPoS is the most interesting part, which you both loose when going to Linda. best, ct. --- Christian Tschudin, University of Basel http://cn.cs.unibas.ch/ Computer Science Dept, Bernoullistr. 16, CH - 4056 Basel, Switzerland > > > ------------------------------------------------------------------------- > Jonathan M. Smith > Olga and Alberico Pompa Professor of Engineering and Applied Science > Professor of Computer and Information Science, University of Pennsylvania > Levine Hall, 3330 Walnut Street, Philadelphia, PA 19104 > > On Sun, 21 May 2006, Jon Crowcroft wrote: > > > pub/sub in the original implementation by tibco et al mapped straight onto multicast > > AND had its own transport (PGM) which was a neat architecture > > > > BUT i am not talking about simply pub-/sub - that was for illustration reasons... > > > > at the end of th day, the receiver has some stuff they are interstd in - you buy > > newspaer x, or you tune to tv or radio station y/z OR you subscribe to some > > belief....all of this is *AND should be* receiver interst based, not sender based > > > > even email (I'm not interested in most the spam i get - this is an indication of a major architectual error > > that the cost of an activity for a pasrticipant doesnt match the need - > > and the resource expended isnt paid for by the right party) > > > > packet swarming is a simple idea - you need to buy into some complete changes of > > ways of building net s (you dont send to an address - you percolate traffic to a repository > > cloud which intersted parties may pick packets out of - this works even for 1-1 commnication > > (if you send an email to e2e but cc: me, i might see it as i probably "subscribe" to messages > > with some field about me - hey, i am sufficiently egomaniacal to want to see stuff like that:) > > > > the technoligy exiwts now to do this at a packet level, not just an application level > > > > In missive , Fred Baker typed: > > > > >> > > >>On May 20, 2006, at 4:17 PM, Fergie wrote: > > >> > > >>> pub/sub how, exactly? > > >> > > >>I think of pub/sub as an application concept: I have content I am > > >>willing to share, and someone else tells me that they are interested. > > >>In this context, I should think the receiving node would tell the > > >>sending node that it was interested if the other guy wanted to talk. > > >> > > >>So now I wonder how this works. I walk into a meeting room and open > > >>my laptop. It joins a wireless network, and voila! the peers and > > >>servers I am interested in all tell me that they are publishing > > >>something to which I might subscribe? > > >> > > >>I think this is going to require some work to describe. At the end of > > >>the day, it is never the receiver that knows there is content out > > >>there to receive; it is always the one who sends it who has that > > >>knowledge. > > > > cheers > > > > jon > > > From lij at ustc.edu Thu May 25 21:09:10 2006 From: lij at ustc.edu (Li, Jiang (Leo)) Date: Fri, 26 May 2006 00:09:10 -0400 Subject: [e2e] Postdoc wanted in DTN Message-ID: <44767F66.7030701@ustc.edu> A 2-year postdoc position in computer networking is open at Howard University. The research is on delay tolerant networking. The candidate must obtain his/her Ph.D. degree no later than August 2006 and should have significant publications in prestigious international journals and conferences. Candidates with strong probability and statistics skills and/or network security background will be considered first. The position is expected to start in August. For application, please send me at lij at scs.howard.edu your C.V. and the links to two or three of your best publications. Jiang (Leo) Li Dept. of Systems and Computer Science Howard University Washington, DC 20059 From touch at ISI.EDU Fri May 26 20:14:12 2006 From: touch at ISI.EDU (Joe Touch) Date: Fri, 26 May 2006 20:14:12 -0700 Subject: [e2e] new network architecture idea - In-Reply-To: <44712935.9010509@reed.com> References: <44712935.9010509@reed.com> Message-ID: <4477C404.2090605@isi.edu> David P. Reed wrote: ... > When things go wrong (black holes, DDoS, ..., even spam and the > blogosphere) is when activities are "sender driven" without regard for > the wishes or needs of the receivers. Communication is initiated at the sender by definition; initiating at the receiver just means the receiver becomes the sender ;-) The sender is the one that decides what to put out and labels it according to what receiver it wants to reach (whether directly, via unicast, or indirectly, by group ID, XML tag, etc.) The list of what receivers are reachable must be known in advance. I.e., although it seems like receiver-driven might get us somewhere, how much of it is just relabeling the endpoints? Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060526/f1bd886a/signature.bin From Eric.Anderson at colorado.edu Fri May 26 21:52:15 2006 From: Eric.Anderson at colorado.edu (Eric W. Anderson) Date: Fri, 26 May 2006 22:52:15 -0600 Subject: [e2e] new network architecture idea - In-Reply-To: <4477C404.2090605@isi.edu> References: <44712935.9010509@reed.com> <4477C404.2090605@isi.edu> Message-ID: <20060527045214.GA4401@colorado.edu> I think what it may come down to is this: In receiver-initiated communication, the (former) receiver becomes a sender, but maybe *what* they send can be sufficiently circumscribed that the problems become more manageable. -Eric Thus spake Joe Touch (touch at ISI.EDU): > Communication is initiated at the sender by definition; initiating at > the receiver just means the receiver becomes the sender ;-) > > The sender is the one that decides what to put out and labels it > according to what receiver it wants to reach (whether directly, via > unicast, or indirectly, by group ID, XML tag, etc.) The list of what > receivers are reachable must be known in advance. > > I.e., although it seems like receiver-driven might get us somewhere, how > much of it is just relabeling the endpoints? > > Joe > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.postel.org/pipermail/end2end-interest/attachments/20060526/486da424/attachment.bin