From Jon.Crowcroft at cl.cam.ac.uk Thu Dec 6 06:23:50 2007 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 06 Dec 2007 14:23:50 +0000 Subject: [e2e] end to end arguments in systems design Message-ID: I havnt seen any email on this list for days now, and before that traffic here has been steadily decreasing over the last few years. does this mean that the "arguments" are over? did I miss the conclusion? who won? who lost? meanwhile, life gets more complex... http://people.redhat.com/drepper/cpumemory.pdf ...and yet simpler... http://research.microsoft.com/research/pubs/view.aspx?tr_id=1389 and yet applications burgeon.... just in the internet supported inter-personal communications space, we have... email, IM, sms, facebook, myspace, twitter, wiki, blogs, rss, pub/sub, pstn/cell/phone/voip/skype, pdas, pagers, and PVRs, and others, all of which can alert us in new and wonderful ways - i'd quite like a funnel so I could pipe together all the events and then aggregate them in some semantically rich way...of course, virtually none of them is e2e:) j. From L.Wood at surrey.ac.uk Thu Dec 6 07:17:46 2007 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Thu, 6 Dec 2007 15:17:46 -0000 Subject: [e2e] end to end arguments in systems design References: Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> Jon, I think the prevailing consensus is "who cares?" I've recently noticed that RFCs can get published without any reference to how end-to-to-end reliability is ensured, even when it's extremely relevant to the protocol being described and the design decisions made for that protocol. This is not good - particularly when detailing a new transport protocol or entire architecture. Error detection and reliability can't just be ignored. An 'Implications for end-to-end reliability' section should imo be mandated to sit alongside the security implications section in all RFCs. L. -----Original Message----- From: end2end-interest-bounces at postel.org on behalf of Jon Crowcroft Sent: Thu 2007-12-06 14:23 To: e2e IRTF list Subject: [e2e] end to end arguments in systems design I havnt seen any email on this list for days now, and before that traffic here has been steadily decreasing over the last few years. does this mean that the "arguments" are over? did I miss the conclusion? who won? who lost? meanwhile, life gets more complex... http://people.redhat.com/drepper/cpumemory.pdf ...and yet simpler... http://research.microsoft.com/research/pubs/view.aspx?tr_id=1389 and yet applications burgeon.... just in the internet supported inter-personal communications space, we have... email, IM, sms, facebook, myspace, twitter, wiki, blogs, rss, pub/sub, pstn/cell/phone/voip/skype, pdas, pagers, and PVRs, and others, all of which can alert us in new and wonderful ways - i'd quite like a funnel so I could pipe together all the events and then aggregate them in some semantically rich way...of course, virtually none of them is e2e:) j. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071206/24f76887/attachment.html From dirk.trossen at bt.com Thu Dec 6 08:17:57 2007 From: dirk.trossen at bt.com (Trossen,D,Dirk,CXR9 R) Date: Thu, 6 Dec 2007 16:17:57 +0000 Subject: [e2e] end to end arguments in systems design Message-ID: <218a301c83823$bae650fb$b37cd80a@domain1.systemhost.net> ...so you replace e2e by a concept of aggregating disperse (e2e?) solutions through some uberarchitecture (Haggle++)? Dirk --- original message --- From: "Jon Crowcroft" Subject: [e2e] end to end arguments in systems design Date: 6th December 2007 Time: 3:16:02 pm I havnt seen any email on this list for days now, and before that traffic here has been steadily decreasing over the last few years. does this mean that the "arguments" are over? did I miss the conclusion? who won? who lost? meanwhile, life gets more complex... http://people.redhat.com/drepper/cpumemory.pdf ...and yet simpler... http://research.microsoft.com/research/pubs/view.aspx?tr_id=1389 and yet applications burgeon.... just in the internet supported inter-personal communications space, we have... email, IM, sms, facebook, myspace, twitter, wiki, blogs, rss, pub/sub, pstn/cell/phone/voip/skype, pdas, pagers, and PVRs, and others, all of which can alert us in new and wonderful ways - i'd quite like a funnel so I could pipe together all the events and then aggregate them in some semantically rich way...of course, virtually none of them is e2e:) j. From dpreed at reed.com Thu Dec 6 09:41:04 2007 From: dpreed at reed.com (David P. Reed) Date: Thu, 06 Dec 2007 12:41:04 -0500 Subject: [e2e] [unclassified] Re: end to end arguments in systems design In-Reply-To: <218a301c83823$bae650fb$b37cd80a@domain1.systemhost.net> References: <218a301c83823$bae650fb$b37cd80a@domain1.systemhost.net> Message-ID: <47583430.1040306@reed.com> Re the arguments: I'm tired of arguing for the end-to-end argument. There's an immense literature by now, and, oddly, a collection of "interpretations" of what the end-to-end argument means - nearly a Talmud. I think the distributed computing (systems and apps) community is searching for design principles and patterns that provide new leverage on some of the same problems, at a new level of complexity. The core problem end-to-end addressed was placement of function, given a binary choice of such placement: in the network shared by all, or outside the network, in the non-shared, perhost, peruser, ... space. And it discussed systems reasons for making such a choice - flexibility, futureproofness, optimality at a point in time, ... - and made judgment about how they might trade off. And it used, as an example only, reliable bit-delivery. Now to me, the core design problem has moved from in/out of the network to "where in the entire connected system, as it exists, as it evolves, and as it will exist" to organize functions that need to be placed. The question of "in the network or not" is of interest only to those who see the distributed network (meaning in the broadest sense of a connected collection of technology and people) as those maps of New York or London that show the entire "rest of the world" as a thin strip on the edge of the city. To the person who sees only packets (and thinks that Ellacoya can tell you what a packet means by studying it at wirespeed) the end-to-end argument in its original form is great. To me, it's like studying the first verse of the Bible for the rest of one's life. Or assuming that by understanding macadam's manufacturing, marketing, architecture, and construction, one can be an expert on transportation. From ggm at apnic.net Thu Dec 6 10:31:32 2007 From: ggm at apnic.net (George Michaelson) Date: Thu, 6 Dec 2007 10:31:32 -0800 Subject: [e2e] [unclassified] Re: end to end arguments in systems design In-Reply-To: <47583430.1040306@reed.com> References: <218a301c83823$bae650fb$b37cd80a@domain1.systemhost.net> <47583430.1040306@reed.com> Message-ID: <20071206103132.05fff3a5@asmtp.apnic.net> > To me, it's like studying the first verse of the Bible for the rest of > one's life. Or assuming that by understanding macadam's manufacturing, > marketing, architecture, and construction, one can be an expert on > transportation. Well, there are those who follow their creed so religiously they DO get stuck at the first book of the bible. All too common. reductionism in this area is frightening, one could almost say pervasive. When a US courts system can have a *serious* discussion about the judges desire to put the 10 commandments on the wall of his court, and articulate separation of church and state at the same time... Personally, I thought after 'fiat lux' it went downhill, although that funny bit about breasts like pomegranates got me through many a boring sunday. There are also those who find it all so hard to take, they don't get to the end of the book. There are also those who find the later books vastly inferior (and of course also those who find them superior), and many have fought and died on the issues.. But as to Macadam: we *do* say "...when the rubber hits the road ..." equally, when we get to "can't see the wood for the trees" many of us are looking for the place to put the road, for the rubber. forgetting that the trees might be rubber trees. -G From lars.eggert at nokia.com Thu Dec 6 12:38:46 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu, 6 Dec 2007 12:38:46 -0800 Subject: [e2e] end to end arguments in systems design In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> References: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: Lloyd, On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org wrote: > I've recently noticed that RFCs can get published without any > reference to how end-to-to-end reliability is ensured, even when > it's extremely relevant to the protocol being described and the > design decisions made for that protocol. This is not good - > particularly when detailing a new transport protocol or > entire architecture. Error detection and reliability can't just > be ignored. it sounds like you have a specific protocol/RFC in mind - can I ask which one? Lars From L.Wood at surrey.ac.uk Thu Dec 6 19:14:37 2007 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Fri, 07 Dec 2007 03:14:37 +0000 Subject: [e2e] end to end arguments in systems design In-Reply-To: References: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: <200712070314.DAA02595@cisco.com> At Thursday 06/12/2007 12:38 -0800, Lars Eggert wrote: >Lloyd, > >On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org wrote: >>I've recently noticed that RFCs can get published without any >>reference to how end-to-to-end reliability is ensured, even when >>it's extremely relevant to the protocol being described and the >>design decisions made for that protocol. This is not good - >>particularly when detailing a new transport protocol or >>entire architecture. Error detection and reliability can't just >>be ignored. > >it sounds like you have a specific protocol/RFC in mind - can I ask >which one? Lars, Since you asked: Two examples that spring to mind are in the output of the IRTF Delay Tolerant Networking (DTN) research group - the DTN bundle protocol (now published as RFC5050) and the Licklider transport protocol (pending). Yes, these protocols are being published as IRTF experimental - which deliberately means 'anything goes' with good reason; no IETF review, to prevent limiting new ideas and approaches, nice big warning boilerplate at the top saying as much, caveat lector. (Though that boilerplate doesn't mention reliability as one example review criterion, it should imo, to encourage readers to bear reliability in mind. We take reliability of computers and transmission far too much for granted these days, and we shouldn't. All those IETFers beavering away on MacBooks which don't even have ECC RAM, not thinking about cosmic rays...) Still, one would expect any IRTF group to recognise reliability and error detection and handling as important (nay, fundamental! as is layering!) very early on in its initial design discussions... Once the lack of error detection in these DTN protocols was agreed to be an oversight, late in the design process after much lobbying and discussion, the DTNRG chairs made the call not to disrupt the then-ongoing publication process, rather than alter the protocol designs - having no error detection, or ways to ensure reliability, was seen by them as in retrospect a missing piece that needed to be added, but not considered that important a showstopping oversight or fundamental. [*] (The DTNRG group has been imo overly focused on security above all else, though lacking a threat analysis of any kind to work from, and attempts have since been made to add in reliability checks via reusing complex security mechanisms - which doesn't quite work for the bundle protocol. The interested can see all the caveats we laid out in the approaches in various drafts, including draft-irtf-dtnrg-bundle-checksum-00.txt, particularly in the security considerations at end. Reusing security protocols in this way also happily allows for more time to be spent on security protocol design, which is the raison d'etre of DTNRG. Still, at least the DTN's reliability problem is now under scrutiny, though rather late, and any kludged fix will be far less than ideal within the constraints of the published protocols.) This is just IRTF experimental stuff, likely just an interesting thought exercise worked out on paper, and nobody in their right mind would ever choose to deploy first-cut IRTF experimental protocols in real operational scenarios, right? But, should they do so, discovering errors and discussing what to do about them in the limits of the existing protocol designs and implementations could be grist for paper mills for years to come... who knows, the end-to-end principle and the reasons for it may even be rediscovered. Now, here's the chilling thought that Jon's email prompted: when the IRTF _itself_ clearly doesn't view the implications of the end-to-end principle and how you get stuff from A to B without detecting introduced errors as fundamentally important to bear in mind when doing initial designs in its research groups, and much effort has to be expended into getting reliability considered as an issue and accepted as worth looking at, "who cares?" wins, and we may as well close down the IRTF e2e mailing list as an obviously long-lost cause. Mandating an 'Implications for end-to-end reliability' section in drafts to encourage writers to think about reliability is a last line of defence. (Perhaps we should also have an 'Implications for layering' section, which might act as a useful bozo filter.) In many ways, we've already built the flaky network infrastructure that we so richly deserve, and focusing on security alone as a panacea can't fix that. If you wanted to see arguments about implications of basic end-to-end reliability on design in 2007, http://maillists.intel-research.net/pipermail/dtn-interest/ was where it was at. Anyhow, seasons greetings and a happy new year to all and sundry. L. [*] to put it in perspective, it's rather like leaving checksums out of early UDP and TCP RFCs, and saying you'll fix it later. What could possibly go wrong? And since Jon prompted this and I've just been rereading his Dec '94 posting decrying ATM, which echoes down the years, it's tempting to simply say "J'Accuse, DTN." From dpreed at reed.com Thu Dec 6 21:42:03 2007 From: dpreed at reed.com (David P. Reed) Date: Fri, 07 Dec 2007 00:42:03 -0500 Subject: [e2e] end to end arguments in systems design In-Reply-To: <200712070314.DAA02595@cisco.com> References: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> <200712070314.DAA02595@cisco.com> Message-ID: <4758DD2B.4010603@reed.com> Leaving such ideas as deciding where the reliability function is placed out of contemporary research seems silly - unless there is a really good reason for randomness. One can argue many views, but one must argue a particular view. It ain't obvious. Lloyd Wood wrote: > At Thursday 06/12/2007 12:38 -0800, Lars Eggert wrote: > >> Lloyd, >> >> On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org wrote: >> >>> I've recently noticed that RFCs can get published without any >>> reference to how end-to-to-end reliability is ensured, even when >>> it's extremely relevant to the protocol being described and the >>> design decisions made for that protocol. This is not good - >>> particularly when detailing a new transport protocol or >>> entire architecture. Error detection and reliability can't just >>> be ignored. >>> >> it sounds like you have a specific protocol/RFC in mind - can I ask >> which one? >> > > Lars, > > Since you asked: > > Two examples that spring to mind are in the output of the IRTF Delay Tolerant Networking (DTN) research group - the DTN bundle protocol (now published as RFC5050) and the Licklider transport protocol (pending). > > Yes, these protocols are being published as IRTF experimental - which deliberately means 'anything goes' with good reason; no IETF review, to prevent limiting new ideas and approaches, nice big warning boilerplate at the top saying as much, caveat lector. (Though that boilerplate doesn't mention reliability as one example review criterion, it should imo, to encourage readers to bear reliability in mind. We take reliability of computers and transmission far too much for granted these days, and we shouldn't. All those IETFers beavering away on MacBooks which don't even have ECC RAM, not thinking about cosmic rays...) > > Still, one would expect any IRTF group to recognise reliability and error detection and handling as important (nay, fundamental! as is layering!) very early on in its initial design discussions... > > Once the lack of error detection in these DTN protocols was agreed to be an oversight, late in the design process after much lobbying and discussion, the DTNRG chairs made the call not to disrupt the then-ongoing publication process, rather than alter the protocol designs - having no error detection, or ways to ensure reliability, was seen by them as in retrospect a missing piece that needed to be added, but not considered that important a showstopping oversight or fundamental. [*] > > (The DTNRG group has been imo overly focused on security above all else, though lacking a threat analysis of any kind to work from, and attempts have since been made to add in reliability checks via reusing complex security mechanisms - which doesn't quite work for the bundle protocol. The interested can see all the caveats we laid out in the approaches in various drafts, including draft-irtf-dtnrg-bundle-checksum-00.txt, particularly in the security considerations at end. Reusing security protocols in this way also happily allows for more time to be spent on security protocol design, which is the raison d'etre of DTNRG. Still, at least the DTN's reliability problem is now under scrutiny, though rather late, and any kludged fix will be far less than ideal within the constraints of the published protocols.) > > This is just IRTF experimental stuff, likely just an interesting thought exercise worked out on paper, and nobody in their right mind would ever choose to deploy first-cut IRTF experimental protocols in real operational scenarios, right? But, should they do so, discovering errors and discussing what to do about them in the limits of the existing protocol designs and implementations could be grist for paper mills for years to come... who knows, the end-to-end principle and the reasons for it may even be rediscovered. > > Now, here's the chilling thought that Jon's email prompted: when the IRTF _itself_ clearly doesn't view the implications of the end-to-end principle and how you get stuff from A to B without detecting introduced errors as fundamentally important to bear in mind when doing initial designs in its research groups, and much effort has to be expended into getting reliability considered as an issue and accepted as worth looking at, "who cares?" wins, and we may as well close down the IRTF e2e mailing list as an obviously long-lost cause. > > Mandating an 'Implications for end-to-end reliability' section in drafts to encourage writers to think about reliability is a last line of defence. (Perhaps we should also have an 'Implications for layering' section, which might act as a useful bozo filter.) In many ways, we've already built the flaky network infrastructure that we so richly deserve, and focusing on security alone as a panacea can't fix that. > > If you wanted to see arguments about implications of basic end-to-end reliability on design in 2007, > http://maillists.intel-research.net/pipermail/dtn-interest/ > was where it was at. > > Anyhow, seasons greetings and a happy new year to all and sundry. > > L. > > [*] to put it in perspective, it's rather like leaving checksums out of early UDP and TCP RFCs, and saying you'll fix it later. What could possibly go wrong? > > And since Jon prompted this and I've just been rereading his Dec '94 posting decrying ATM, which echoes down the years, it's tempting to simply say "J'Accuse, DTN." > > > > From lars.eggert at nokia.com Fri Dec 7 11:21:10 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Fri, 7 Dec 2007 11:21:10 -0800 Subject: [e2e] end to end arguments in systems design In-Reply-To: <200712070314.DAA02595@cisco.com> References: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> <200712070314.DAA02595@cisco.com> Message-ID: <103FAD02-401F-4ECB-BB2C-35D509E9372C@nokia.com> On 2007-12-6, at 19:14, ext Lloyd Wood wrote: > Two examples that spring to mind are in the output of the IRTF Delay > Tolerant Networking (DTN) research group - the DTN bundle protocol > (now published as RFC5050) and the Licklider transport protocol > (pending). > > Yes, these protocols are being published as IRTF experimental Thanks for clarifying. I was worried for a minute that you were referring to transport area standards track protocols. (And the rest of your email clarifies that you're concerned about the inner workings of DTNRG and what impact that has on their Experimental RFCs, and not on the workings of IETF WGs in this space. But shouldn't you bring this up on the DTNRG list, rather than that of a the E2E RG?) Lars From L.Wood at surrey.ac.uk Fri Dec 7 12:54:21 2007 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Fri, 7 Dec 2007 20:54:21 -0000 Subject: [e2e] end to end arguments in systems design References: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> <200712070314.DAA02595@cisco.com> <103FAD02-401F-4ECB-BB2C-35D509E9372C@nokia.com> Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316ADD@EVS-EC1-NODE1.surrey.ac.uk> >On 2007-12-6, at 19:14, ext Lloyd Wood wrote: >> Two examples that spring to mind are in the output of the IRTF Delay >> Tolerant Networking (DTN) research group - the DTN bundle protocol >> (now published as RFC5050) and the Licklider transport protocol >> (pending). >> >> Yes, these protocols are being published as IRTF experimental > > Thanks for clarifying. I was worried for a minute that you were > referring to transport area standards track protocols. Consider our moving Saratoga from DTNRG to TSVWG and draft-wood-tsvwg-saratoga-00 (as discussed with you in Chicago) a vote of confidence in the transport area and its processes. > (And the rest of your email clarifies that you're concerned about the > inner workings of DTNRG and what impact that has on their Experimental > RFCs, and not on the workings of IETF WGs in this space. But shouldn't > you bring this up on the DTNRG list, rather than that of a the E2E RG?) My previous email summarised months of bringing this to the DTNRG. L. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071207/81a269c1/attachment.html From lars.eggert at nokia.com Fri Dec 7 17:57:01 2007 From: lars.eggert at nokia.com (Lars Eggert) Date: Fri, 7 Dec 2007 17:57:01 -0800 Subject: [e2e] end to end arguments in systems design In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC20701316ADD@EVS-EC1-NODE1.surrey.ac.uk> References: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> <200712070314.DAA02595@cisco.com> <103FAD02-401F-4ECB-BB2C-35D509E9372C@nokia.com> <603BF90EB2E7EB46BF8C226539DFC20701316ADD@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: <9BBE03B2-439A-4DDB-BF83-C9FA7E00CADC@nokia.com> On 2007-12-7, at 12:54, ext L.Wood at surrey.ac.uk wrote: > Consider our moving Saratoga from DTNRG to TSVWG and > draft-wood-tsvwg-saratoga-00 (as discussed with you in Chicago) > a vote of confidence in the transport area and its processes. Just so we're clear - you do have expressed interest that TSVWG take on Saratoga, but we haven't established consensus on this in the WG. Lars From L.Wood at surrey.ac.uk Sat Dec 8 06:53:26 2007 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Sat, 8 Dec 2007 14:53:26 -0000 Subject: [e2e] end to end arguments in systems design References: <603BF90EB2E7EB46BF8C226539DFC20701316ADA@EVS-EC1-NODE1.surrey.ac.uk> <200712070314.DAA02595@cisco.com> <103FAD02-401F-4ECB-BB2C-35D509E9372C@nokia.com> <603BF90EB2E7EB46BF8C226539DFC20701316ADD@EVS-EC1-NODE1.surrey.ac.uk> <9BBE03B2-439A-4DDB-BF83-C9FA7E00CADC@nokia.com> Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316ADF@EVS-EC1-NODE1.surrey.ac.uk> > Lars wrote: > On 2007-12-7, at 12:54, ext L.Wood at surrey.ac.uk wrote: > > Consider our moving Saratoga from DTNRG to TSVWG and > > draft-wood-tsvwg-saratoga-00 (as discussed with you in Chicago) > > a vote of confidence in the transport area and its processes. > > Just so we're clear - you do have expressed interest that TSVWG take > on Saratoga, but we haven't established consensus on this in the WG. Exactly - nor, at this point, have we even asked TSVWG to consent to taking on Saratoga. (Though it's a far more appealing thought than asking DTNRG the same.) As far as TSVWG is concerned, it's just another -00 individual draft, and too early to tell. cheers, L. Saratoga: http://www.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071208/f5b8e779/attachment.html From kfall at cs.berkeley.edu Sat Dec 8 21:05:10 2007 From: kfall at cs.berkeley.edu (Kevin Fall) Date: Sat, 8 Dec 2007 21:05:10 -0800 Subject: [e2e] end to end arguments in systems design -> checksums in bundle protocol In-Reply-To: References: Message-ID: <99669B37-D557-4D51-BB01-502E79166FF0@cs.berkeley.edu> Well, I guess I should respond to the message from Lloyd regarding checksums in the bundle protocol (DTNRG). As is not uncommon, I believe he totally misrepresents what happened, for reasons I do not (care to) know. The checksum was deliberately omitted. Here is why (see www.dtnrg.org if you desire more background): 1. many of the environments we have discussed intend to run the bundle protocol atop other protocols that already have checksums 2. there is a desire among some of the researchers to utilize object- level reliability and security; requiring a checksum at the bundle layer would be redundant 3. there is a security protocol (described separately) that provides greater reliability than any simple checksum [yes, I do realize various types of checksums or CRC-like codes can be used] 4. there is an extensibility mechanism in the bundle protocol, much like IPv6 extension headers. If, remarkably, it is decided to put one in the BP, it is a very simple matter 5. the BP is not necessarily a 'transport' protocol with transport functionality in the Internet stack sense. There are discussions regarding presentation-layer-like functionality (indeed one might conceivably think of BP as a session protocol, although we don't adopt "layerism" as any fundamental tenet) I could go on, but those are the main reasons. - K On Dec 7, 2007, at Dec 712:00 PMPST, end2end-interest- request at postel.org wrote: > > > > Today's Topics: > > 1. Re: end to end arguments in systems design (Lars Eggert) > 2. Re: end to end arguments in systems design (Lloyd Wood) > 3. Re: end to end arguments in systems design (David P. Reed) > 4. Re: end to end arguments in systems design (Lars Eggert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 6 Dec 2007 12:38:46 -0800 > From: Lars Eggert > Subject: Re: [e2e] end to end arguments in systems design > To: ext Lloyd Wood > Cc: Jon Crowcroft , e2e > > Message-ID: > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > Lloyd, > > On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org wrote: >> I've recently noticed that RFCs can get published without any >> reference to how end-to-to-end reliability is ensured, even when >> it's extremely relevant to the protocol being described and the >> design decisions made for that protocol. This is not good - >> particularly when detailing a new transport protocol or >> entire architecture. Error detection and reliability can't just >> be ignored. > > it sounds like you have a specific protocol/RFC in mind - can I ask > which one? > > Lars > > > ------------------------------ > > Message: 2 > Date: Fri, 07 Dec 2007 03:14:37 +0000 > From: Lloyd Wood > Subject: Re: [e2e] end to end arguments in systems design > To: Lars Eggert > Cc: Jon Crowcroft , e2e > > Message-ID: <200712070314.DAA02595 at cisco.com> > Content-Type: text/plain; charset="us-ascii" > > At Thursday 06/12/2007 12:38 -0800, Lars Eggert wrote: >> Lloyd, >> >> On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org wrote: >>> I've recently noticed that RFCs can get published without any >>> reference to how end-to-to-end reliability is ensured, even when >>> it's extremely relevant to the protocol being described and the >>> design decisions made for that protocol. This is not good - >>> particularly when detailing a new transport protocol or >>> entire architecture. Error detection and reliability can't just >>> be ignored. >> >> it sounds like you have a specific protocol/RFC in mind - can I ask >> which one? > > Lars, > > Since you asked: > > Two examples that spring to mind are in the output of the IRTF > Delay Tolerant Networking (DTN) research group - the DTN bundle > protocol (now published as RFC5050) and the Licklider transport > protocol (pending). > > Yes, these protocols are being published as IRTF experimental - > which deliberately means 'anything goes' with good reason; no IETF > review, to prevent limiting new ideas and approaches, nice big > warning boilerplate at the top saying as much, caveat lector. > (Though that boilerplate doesn't mention reliability as one example > review criterion, it should imo, to encourage readers to bear > reliability in mind. We take reliability of computers and > transmission far too much for granted these days, and we shouldn't. > All those IETFers beavering away on MacBooks which don't even have > ECC RAM, not thinking about cosmic rays...) > > Still, one would expect any IRTF group to recognise reliability and > error detection and handling as important (nay, fundamental! as is > layering!) very early on in its initial design discussions... > > Once the lack of error detection in these DTN protocols was agreed > to be an oversight, late in the design process after much lobbying > and discussion, the DTNRG chairs made the call not to disrupt the > then-ongoing publication process, rather than alter the protocol > designs - having no error detection, or ways to ensure reliability, > was seen by them as in retrospect a missing piece that needed to be > added, but not considered that important a showstopping oversight > or fundamental. [*] > > (The DTNRG group has been imo overly focused on security above all > else, though lacking a threat analysis of any kind to work from, > and attempts have since been made to add in reliability checks via > reusing complex security mechanisms - which doesn't quite work for > the bundle protocol. The interested can see all the caveats we laid > out in the approaches in various drafts, including draft-irtf-dtnrg- > bundle-checksum-00.txt, particularly in the security considerations > at end. Reusing security protocols in this way also happily allows > for more time to be spent on security protocol design, which is the > raison d'etre of DTNRG. Still, at least the DTN's reliability > problem is now under scrutiny, though rather late, and any kludged > fix will be far less than ideal within the constraints of the > published protocols.) > > This is just IRTF experimental stuff, likely just an interesting > thought exercise worked out on paper, and nobody in their right > mind would ever choose to deploy first-cut IRTF experimental > protocols in real operational scenarios, right? But, should they do > so, discovering errors and discussing what to do about them in the > limits of the existing protocol designs and implementations could > be grist for paper mills for years to come... who knows, the end-to- > end principle and the reasons for it may even be rediscovered. > > Now, here's the chilling thought that Jon's email prompted: when > the IRTF _itself_ clearly doesn't view the implications of the end- > to-end principle and how you get stuff from A to B without > detecting introduced errors as fundamentally important to bear in > mind when doing initial designs in its research groups, and much > effort has to be expended into getting reliability considered as an > issue and accepted as worth looking at, "who cares?" wins, and we > may as well close down the IRTF e2e mailing list as an obviously > long-lost cause. > > Mandating an 'Implications for end-to-end reliability' section in > drafts to encourage writers to think about reliability is a last > line of defence. (Perhaps we should also have an 'Implications for > layering' section, which might act as a useful bozo filter.) In > many ways, we've already built the flaky network infrastructure > that we so richly deserve, and focusing on security alone as a > panacea can't fix that. > > If you wanted to see arguments about implications of basic end-to- > end reliability on design in 2007, > http://maillists.intel-research.net/pipermail/dtn-interest/ > was where it was at. > > Anyhow, seasons greetings and a happy new year to all and sundry. > > L. > > [*] to put it in perspective, it's rather like leaving checksums > out of early UDP and TCP RFCs, and saying you'll fix it later. What > could possibly go wrong? > > And since Jon prompted this and I've just been rereading his Dec > '94 posting decrying ATM, which echoes down the years, it's > tempting to simply say "J'Accuse, DTN." > > > > > ------------------------------ > > Message: 3 > Date: Fri, 07 Dec 2007 00:42:03 -0500 > From: "David P. Reed" > Subject: Re: [e2e] end to end arguments in systems design > To: Lloyd Wood > Cc: Jon Crowcroft , e2e > > Message-ID: <4758DD2B.4010603 at reed.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Leaving such ideas as deciding where the reliability function is > placed > out of contemporary research seems silly - unless there is a really > good > reason for randomness. > > One can argue many views, but one must argue a particular view. It > ain't obvious. > > > Lloyd Wood wrote: >> At Thursday 06/12/2007 12:38 -0800, Lars Eggert wrote: >> >>> Lloyd, >>> >>> On 2007-12-6, at 7:17, ext end2end-interest-bounces at postel.org >>> wrote: >>> >>>> I've recently noticed that RFCs can get published without any >>>> reference to how end-to-to-end reliability is ensured, even when >>>> it's extremely relevant to the protocol being described and the >>>> design decisions made for that protocol. This is not good - >>>> particularly when detailing a new transport protocol or >>>> entire architecture. Error detection and reliability can't just >>>> be ignored. >>>> >>> it sounds like you have a specific protocol/RFC in mind - can I ask >>> which one? >>> >> >> Lars, >> >> Since you asked: >> >> Two examples that spring to mind are in the output of the IRTF >> Delay Tolerant Networking (DTN) research group - the DTN bundle >> protocol (now published as RFC5050) and the Licklider transport >> protocol (pending). >> >> Yes, these protocols are being published as IRTF experimental - >> which deliberately means 'anything goes' with good reason; no IETF >> review, to prevent limiting new ideas and approaches, nice big >> warning boilerplate at the top saying as much, caveat lector. >> (Though that boilerplate doesn't mention reliability as one >> example review criterion, it should imo, to encourage readers to >> bear reliability in mind. We take reliability of computers and >> transmission far too much for granted these days, and we >> shouldn't. All those IETFers beavering away on MacBooks which >> don't even have ECC RAM, not thinking about cosmic rays...) >> >> Still, one would expect any IRTF group to recognise reliability >> and error detection and handling as important (nay, fundamental! >> as is layering!) very early on in its initial design discussions... >> >> Once the lack of error detection in these DTN protocols was agreed >> to be an oversight, late in the design process after much lobbying >> and discussion, the DTNRG chairs made the call not to disrupt the >> then-ongoing publication process, rather than alter the protocol >> designs - having no error detection, or ways to ensure >> reliability, was seen by them as in retrospect a missing piece >> that needed to be added, but not considered that important a >> showstopping oversight or fundamental. [*] >> >> (The DTNRG group has been imo overly focused on security above all >> else, though lacking a threat analysis of any kind to work from, >> and attempts have since been made to add in reliability checks via >> reusing complex security mechanisms - which doesn't quite work for >> the bundle protocol. The interested can see all the caveats we >> laid out in the approaches in various drafts, including draft-irtf- >> dtnrg-bundle-checksum-00.txt, particularly in the security >> considerations at end. Reusing security protocols in this way also >> happily allows for more time to be spent on security protocol >> design, which is the raison d'etre of DTNRG. Still, at least the >> DTN's reliability problem is now under scrutiny, though rather >> late, and any kludged fix will be far less than ideal within the >> constraints of the published protocols.) >> >> This is just IRTF experimental stuff, likely just an interesting >> thought exercise worked out on paper, and nobody in their right >> mind would ever choose to deploy first-cut IRTF experimental >> protocols in real operational scenarios, right? But, should they >> do so, discovering errors and discussing what to do about them in >> the limits of the existing protocol designs and implementations >> could be grist for paper mills for years to come... who knows, the >> end-to-end principle and the reasons for it may even be rediscovered. >> >> Now, here's the chilling thought that Jon's email prompted: when >> the IRTF _itself_ clearly doesn't view the implications of the end- >> to-end principle and how you get stuff from A to B without >> detecting introduced errors as fundamentally important to bear in >> mind when doing initial designs in its research groups, and much >> effort has to be expended into getting reliability considered as >> an issue and accepted as worth looking at, "who cares?" wins, and >> we may as well close down the IRTF e2e mailing list as an >> obviously long-lost cause. >> >> Mandating an 'Implications for end-to-end reliability' section in >> drafts to encourage writers to think about reliability is a last >> line of defence. (Perhaps we should also have an 'Implications for >> layering' section, which might act as a useful bozo filter.) In >> many ways, we've already built the flaky network infrastructure >> that we so richly deserve, and focusing on security alone as a >> panacea can't fix that. >> >> If you wanted to see arguments about implications of basic end-to- >> end reliability on design in 2007, >> http://maillists.intel-research.net/pipermail/dtn-interest/ >> was where it was at. >> >> Anyhow, seasons greetings and a happy new year to all and sundry. >> >> L. >> >> [*] to put it in perspective, it's rather like leaving checksums >> out of early UDP and TCP RFCs, and saying you'll fix it later. >> What could possibly go wrong? >> >> And since Jon prompted this and I've just been rereading his Dec >> '94 posting decrying ATM, which echoes down the years, it's >> tempting to simply say "J'Accuse, DTN." >> >> >> >> > > > ------------------------------ > > Message: 4 > Date: Fri, 7 Dec 2007 11:21:10 -0800 > From: Lars Eggert > Subject: Re: [e2e] end to end arguments in systems design > To: ext Lloyd Wood > Cc: Jon Crowcroft , e2e > > Message-ID: <103FAD02-401F-4ECB-BB2C-35D509E9372C at nokia.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On 2007-12-6, at 19:14, ext Lloyd Wood wrote: >> Two examples that spring to mind are in the output of the IRTF Delay >> Tolerant Networking (DTN) research group - the DTN bundle protocol >> (now published as RFC5050) and the Licklider transport protocol >> (pending). >> >> Yes, these protocols are being published as IRTF experimental > > Thanks for clarifying. I was worried for a minute that you were > referring to transport area standards track protocols. > > (And the rest of your email clarifies that you're concerned about the > inner workings of DTNRG and what impact that has on their Experimental > RFCs, and not on the workings of IETF WGs in this space. But shouldn't > you bring this up on the DTNRG list, rather than that of a the E2E > RG?) > > Lars > > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 46, Issue 2 > *********************************************** > From ramana at cs.ucsd.edu Tue Dec 11 06:25:25 2007 From: ramana at cs.ucsd.edu (Ramana Kompella) Date: Tue, 11 Dec 2007 09:25:25 -0500 Subject: [e2e] ICNP 2008: Call for papers Message-ID: <475E9DD5.4020607@cs.ucsd.edu> [Sincere apologies if you receive multiple copies of this CFP.] CALL FOR PAPERS ICNP 2008 16th IEEE International Conference on Network Protocols Orlando, Florida October 19-22, 2008 ICNP 2008, the sixteenth IEEE International Conference on Network Protocols, is a conference covering all aspects of network protocols, including design, analysis, specification, verification, implementation, and performance. ICNP 2008 will be held in Orlando, Florida, on October 19-22, 2008. Papers with significant research contributions to the field of network protocols are solicited for submission. Papers cannot be previously published nor under review by another conference or journal. Topics of interest include, but are not limited to: 1. Protocol testing, analysis, design and implementation 2. Measurement and monitoring of protocols 3. Protocols designed for specific functions, such as: routing, flow and congestion control, QoS, signaling, security, network management, or resilience 4. Protocols designed for specific networks, such as: wireless and mobile networks, Ad hoc and sensor networks, virtual networks, and ubiquitous networks Papers must deal specifically with protocols. Papers of general networking nature where protocols are only a secondary focus will be considered only if they are of exceptional high quality and only a very limited number of such papers will be included in the technical program. ICNP will select an accepted full paper for the best paper award. For the first time, ICNP is using a double-blind review process. The identity of authors and referees will not be revealed to each other. To ensure blind reviewing, authors names and affiliations should not appear in the paper; bibliographic references should be made in such a way as to preserve author anonymity. IMPORTANT DATES Abstract registration: April 19, 2008 11:59 PM EDT Paper submission: April 25, 2008 11:59 PM EDT Notification of acceptance: July 29, 2008 Camera ready version: September 5, 2008 ORGANIZING COMMITTEES EXECUTIVE COMMITTEE: David Lee, Ohio State University, USA (chair) Mostafa Ammar, Georgia Tech, USA Ken Calvert, University of Kentucky, USA Teruo Higashino, Osaka University, Japan Raymond Miller, University of Maryland, USA GENERAL CHAIRS: Sonia Fahmy, Purdue University, USA Mohamed Gouda, University of Texas, Austin, USA PROGRAM CHAIRS: Kevin Almeroth, University of California, Santa Barbara, USA K. K. Ramakrishnan, AT&T Labs Research, USA LOCAL ARRANGEMENT CHAIRS: Ahmed Helmy, University of Florida, USA Cliff Zou, University of Central Florida, USA PUBLICATION CHAIR: Kamil Sarac, University of Texas at Dallas, USA PUBLICITY CHAIRS: Ramana Rao Kompella, Purdue University, USA James Minseok Kwon, Rochester Institute of Technology, USA WEB CHAIR: Ossama Younis, Telcordia Applied Research, USA STEERING COMMITTEE: Simon Lam, University of Texas, USA David Lee, Ohio State University, USA Mostafa Ammar, Georgia Tech, USA Ken Calvert, University of Kentucky, USA Mohamed Gouda, University of Texas, USA Teruo Higashino, Osaka University, Japan Mike T. Liu, Ohio State University, USA Raymond Miller, University of Maryland, USA Krishan Sabnani, Bell Labs, USA PROGRAM COMMITTEE: See Web site. FURTHER INFORMATION: Web site: http://www.cs.purdue.edu/homes/fahmy/icnp2008/ E-mail: icnp2008 at cs.purdue.edu From pganti at gmail.com Tue Dec 18 11:11:09 2007 From: pganti at gmail.com (Paddy Ganti) Date: Tue, 18 Dec 2007 14:11:09 -0500 Subject: [e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers? Message-ID: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> Hello e2e, Does anyone have some quantitative experimental data on what percentage of reliable packet delivery in TCP is done through Fast Retransmit versus that of a RTO expiry? Specifically I am looking at such data being available for HTTP class of traffic. Some raw issues that lead for such data to be interesting: (a) When the initial cwnd is less than 4 then there is a chance that initial SYN/SYNACK oss cannot be recovered using FastRetransmit (this is also worse than RTO expiry because of additional 3 seconds).Magic value of 4 seems to be from the paper Morris' *Scalable TCP Congestion Control* (b) The last packet isnt eligible for fast retransmit as well by the same logic albeit this time the recovert via RTO (c) In between (a) and (b) lets say we have a train of packets (dictated by the cwnd size or the application's PSH). If you imagine this flight of packets as a train, the last packet of such a burst cannot also be recovered using fast retransmit (d) Some other cases that I am not thinking of here. Given that HTTP traffic seems to be like small bursts of packet trains, there will be many last packets in a train and hence response time suffers on lossy/congested networks. -Paddy Ganti -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071218/241550ea/attachment.html From jasleen at cs.unc.edu Tue Dec 18 12:56:54 2007 From: jasleen at cs.unc.edu (Jasleen Kaur) Date: Tue, 18 Dec 2007 15:56:54 -0500 Subject: [e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers? In-Reply-To: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> References: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> Message-ID: <47683416.3010109@cs.unc.edu> Paddy, You'll find our recent work on studying the performance of TCP loss detection useful (please see the two citations below). One of the data-sets we've used (ibi) is collected from a cluster of web-servers --- however, this cluster also handles some fairly large file transfers. The first paper below studies the impact of configuring RTO and FR/R parameters on the durations of TCP connections. We've found that RTOs are still pretty common (more than FR/R). Interestingly, we've found that reconfiguring the parameters associated with these can help improve the situation to some extent (the overall impact on connection durations can sometimes be quite significant). S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss Detection/Recovery in Real-world TCP Implementations", in Proceedings of the IEEE International Conference on Network Protocols (ICNP'07), Beijing, China, Oct 2007. http://www.cs.unc.edu/~jasleen/papers/icnp07.pdf Rewaskar, J. Kaur, and F.D. Smith, "A Passive State-Machine Approach for Accurate Analysis of TCP Out-of-Sequence Segments", in ACM Computer Communications Review (CCR), July 2006. http://www.cs.unc.edu/~jasleen/papers/ccr06.pdf We'd welcome any feedback. Thanks, Jasleen Paddy Ganti wrote: > Hello e2e, > > Does anyone have some quantitative experimental data on what > percentage of reliable packet delivery in TCP is done through Fast > Retransmit versus that of a RTO expiry? Specifically I am looking at > such data being available for HTTP class of traffic. > > Some raw issues that lead for such data to be interesting: > > (a) When the initial cwnd is less than 4 then there is a chance that > initial SYN/SYNACK oss cannot be recovered using FastRetransmit (this > is also worse than RTO expiry because of additional 3 seconds).Magic > value of 4 seems to be from the paper Morris' /Scalable TCP > Congestion Control/ > > (b) The last packet isnt eligible for fast retransmit as well by the > same logic albeit this time the recovert via RTO > > (c) In between (a) and (b) lets say we have a train of packets > (dictated by the cwnd size or the application's PSH). If you imagine > this flight of packets as a train, the last packet of such a burst > cannot also be recovered using fast retransmit > > (d) Some other cases that I am not thinking of here. > > Given that HTTP traffic seems to be like small bursts of packet > trains, there will be many last packets in a train and hence response > time suffers on lossy/congested networks. > > -Paddy Ganti From mellia at tlc.polito.it Tue Dec 18 13:37:12 2007 From: mellia at tlc.polito.it (Mellia Marco) Date: Tue, 18 Dec 2007 22:37:12 +0100 Subject: [e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers? In-Reply-To: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> References: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> Message-ID: <47683D88.7080400@tlc.polito.it> Your intuition is quite right... RTO kicks in much more often than FR... There are a couple of papers/ideas/rfcs that try to address this problem. You may have a look at this paper... in which we explicitely study the problem you mention, and compare our proposal to others'. M. Mellia, M. Meo, C. Casetti TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN: 1063-6692, April 2005 http://www.tlc-networks.polito.it/mellia/papers/TNG-TCP-SF.ps In addition, we are continously monitoring TCP retransmission using tstat. Some measurements are available on-line from tstat web site Http://www.tstat.polito.it E.G. http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&var=tcp_anomalies&dir=rrd_data/FW/LIVE&logscale=&bigpic=true&advopt=true&yauto=false&ymax=10&direction=both&advcmd=&describe=&hifreq=false&ymin=-10 Hope you find this useful. Ciao, Marco > Hello e2e, > > Does anyone have some quantitative experimental data on what percentage > of reliable packet delivery in TCP is done through Fast Retransmit > versus that of a RTO expiry? Specifically I am looking at such data > being available for HTTP class of traffic. > > Some raw issues that lead for such data to be interesting: > > (a) When the initial cwnd is less than 4 then there is a chance that > initial SYN/SYNACK oss cannot be recovered using FastRetransmit (this > is also worse than RTO expiry because of additional 3 seconds).Magic > value of 4 seems to be from the paper Morris' /Scalable TCP Congestion > Control/ > > (b) The last packet isnt eligible for fast retransmit as well by the > same logic albeit this time the recovert via RTO > > (c) In between (a) and (b) lets say we have a train of packets (dictated > by the cwnd size or the application's PSH). If you imagine this flight > of packets as a train, the last packet of such a burst cannot also be > recovered using fast retransmit > > (d) Some other cases that I am not thinking of here. > > Given that HTTP traffic seems to be like small bursts of packet trains, > there will be many last packets in a train and hence response time > suffers on lossy/congested networks. > > -Paddy Ganti From pganti at gmail.com Tue Dec 18 14:58:49 2007 From: pganti at gmail.com (Paddy Ganti) Date: Tue, 18 Dec 2007 17:58:49 -0500 Subject: [e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers? In-Reply-To: <47683D88.7080400@tlc.polito.it> References: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> <47683D88.7080400@tlc.polito.it> Message-ID: <2ff1f08a0712181458x39ddc423udd7450db4846de39@mail.gmail.com> Marco, Thank you for the live data pointer. Your paper looks very interesting (still need to digest all of whats being said though). I have one suggestion which you might have already thought about when proposing smart framing: Why not resend cloned packets of the last one after the last one? I mean,only for the first (send 2 SYNs spaced at 600ms0 and last packets, why cant we modify the stack to send 2 copies of the last packet for FR. Would this crash stacks? -Paddy On Dec 18, 2007 4:37 PM, Mellia Marco wrote: > > Your intuition is quite right... RTO kicks in much more often than FR... > > There are a couple of papers/ideas/rfcs that try to address this problem. > You may have a look at this paper... in which we explicitely study the > problem you mention, and compare our proposal to others'. > > M. Mellia, M. Meo, C. Casetti > TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency > IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN: > 1063-6692, April 2005 > > http://www.tlc-networks.polito.it/mellia/papers/TNG-TCP-SF.ps > > In addition, we are continously monitoring TCP retransmission using tstat. > Some measurements are available on-line from tstat web site > Http://www.tstat.polito.it > > > E.G. > > http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&var=tcp_anomalies&dir=rrd_data/FW/LIVE&logscale=&bigpic=true&advopt=true&yauto=false&ymax=10&direction=both&advcmd=&describe=&hifreq=false&ymin=-10 > > Hope you find this useful. > > Ciao, > Marco > > > Hello e2e, > > > > Does anyone have some quantitative experimental data on what percentage > > of reliable packet delivery in TCP is done through Fast Retransmit > > versus that of a RTO expiry? Specifically I am looking at such data > > being available for HTTP class of traffic. > > > > Some raw issues that lead for such data to be interesting: > > > > (a) When the initial cwnd is less than 4 then there is a chance that > > initial SYN/SYNACK oss cannot be recovered using FastRetransmit (this > > is also worse than RTO expiry because of additional 3 seconds).Magic > > value of 4 seems to be from the paper Morris' /Scalable TCP Congestion > > Control/ > > > > (b) The last packet isnt eligible for fast retransmit as well by the > > same logic albeit this time the recovert via RTO > > > > (c) In between (a) and (b) lets say we have a train of packets (dictated > > by the cwnd size or the application's PSH). If you imagine this flight > > of packets as a train, the last packet of such a burst cannot also be > > recovered using fast retransmit > > > > (d) Some other cases that I am not thinking of here. > > > > Given that HTTP traffic seems to be like small bursts of packet trains, > > there will be many last packets in a train and hence response time > > suffers on lossy/congested networks. > > > > -Paddy Ganti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071218/025cfdc0/attachment.html From mellia at tlc.polito.it Tue Dec 18 15:17:47 2007 From: mellia at tlc.polito.it (Mellia Marco) Date: Wed, 19 Dec 2007 00:17:47 +0100 Subject: [e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers? In-Reply-To: <2ff1f08a0712181458x39ddc423udd7450db4846de39@mail.gmail.com> References: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> <47683D88.7080400@tlc.polito.it> <2ff1f08a0712181458x39ddc423udd7450db4846de39@mail.gmail.com> Message-ID: <4768551B.3070809@tlc.polito.it> I would not support this... basically you are suggesting to transmit twice the last segment. This means adding an overhead of 100% (tothe last segment), that would be probably helpful only if the first copy get dropped by the network. Even if the dropping probabilty is quite large, say 5%, you waste 95% of the bandwidth ... Probably not a smart choice... Moreover, after the "last" segment, the server could send a FIN message, that would cause eventual dup-acks to be generated... Allowing the sender to immediately retransmit the last segment in case a dup-ack is received, would do the job in a much more fair fashion... Marco > Marco, > > Thank you for the live data pointer. Your paper looks very interesting > (still need to digest all of whats being said though). I have one > suggestion which you might have already thought about when proposing > smart framing: Why not resend cloned packets of the last one after the > last one? I mean,only for the first (send 2 SYNs spaced at 600ms0 and > last packets, why cant we modify the stack to send 2 copies of the > last packet for FR. Would this crash stacks? > > -Paddy > > > On Dec 18, 2007 4:37 PM, Mellia Marco > wrote: > > > Your intuition is quite right... RTO kicks in much more often than > FR... > > There are a couple of papers/ideas/rfcs that try to address this > problem. > You may have a look at this paper... in which we explicitely study > the > problem you mention, and compare our proposal to others'. > > M. Mellia, M. Meo, C. Casetti > TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency > IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, > ISSN: > 1063-6692, April 2005 > > http://www.tlc-networks.polito.it/mellia/papers/TNG-TCP-SF.ps > > In addition, we are continously monitoring TCP retransmission > using tstat. > Some measurements are available on-line from tstat web site > Http://www.tstat.polito.it > > > E.G. > http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&var=tcp_anomalies&dir=rrd_data/FW/LIVE&logscale=&bigpic=true&advopt=true&yauto=false&ymax=10&direction=both&advcmd=&describe=&hifreq=false&ymin=-10 > > > Hope you find this useful. > > Ciao, > Marco > > > Hello e2e, > > > > Does anyone have some quantitative experimental data on what > percentage > > of reliable packet delivery in TCP is done through Fast Retransmit > > versus that of a RTO expiry? Specifically I am looking at such data > > being available for HTTP class of traffic. > > > > Some raw issues that lead for such data to be interesting: > > > > (a) When the initial cwnd is less than 4 then there is a chance that > > initial SYN/SYNACK oss cannot be recovered using FastRetransmit > (this > > is also worse than RTO expiry because of additional 3 > seconds).Magic > > value of 4 seems to be from the paper Morris' /Scalable TCP > Congestion > > Control/ > > > > (b) The last packet isnt eligible for fast retransmit as well by the > > same logic albeit this time the recovert via RTO > > > > (c) In between (a) and (b) lets say we have a train of packets > (dictated > > by the cwnd size or the application's PSH). If you imagine this > flight > > of packets as a train, the last packet of such a burst cannot > also be > > recovered using fast retransmit > > > > (d) Some other cases that I am not thinking of here. > > > > Given that HTTP traffic seems to be like small bursts of packet > trains, > > there will be many last packets in a train and hence response time > > suffers on lossy/congested networks. > > > > -Paddy Ganti > > From lastewart at swin.edu.au Tue Dec 18 23:54:42 2007 From: lastewart at swin.edu.au (Lawrence Stewart) Date: Wed, 19 Dec 2007 18:54:42 +1100 Subject: [e2e] Modular/Pluggable TCP Congestion Control for FreeBSD Message-ID: <4768CE42.80303@swin.edu.au> Hi all, We've been involved in a research project to implement and test an emerging TCP congestion control algorithm under FreeBSD. As a part of this, we've put together a patch for FreeBSD 7.0-BETA4 that modularises the congestion control code in the TCP stack. It allows for new congestion control algorithms to be developed as loadable kernel modules. This improves FreeBSD's usefulness as a TCP research platform and makes it easier to customise the stack for specific scenarios like high bandwidth, long delay paths. There is an accompanying technical report "Light-Weight Modular TCP Congestion Control for FreeBSD 7" [1] that covers the design, features, kernel interface and usage of the framework. Also on our website is a beta release of a module that implements the H-TCP[2] congestion control algorithm proposed by the Hamilton Institute. We believe that modular congestion control is a worthwhile addition to FreeBSD. We've performed significant internal testing and there are currently no known issues or regressions with the implementation compared to a 'vanilla' FreeBSD 7.0-BETA4 kernel. We would welcome further review and testing from the wider community in the hope of getting this patch folded into FreeBSD 8-CURRENT. SIFTR [3], our tool for monitoring FreeBSD kernel TCP connection state, has also received a minor update to v1.1.5, with the addition of 6 new, useful variables. All code and documentation is available on our website[3]. Cheers, Jim and Lawrence http://caia.swin.edu.au [1] http://caia.swin.edu.au/reports/071218A/CAIA-TR-071218A.pdf [2] http://www.hamilton.ie/net/htcp3.pdf [3] http://caia.swin.edu.au/urp/newtcp/tools.html From fred at cisco.com Tue Dec 18 10:53:18 2007 From: fred at cisco.com (Fred Baker) Date: Tue, 18 Dec 2007 10:53:18 -0800 Subject: [e2e] Modular/Pluggable TCP Congestion Control for FreeBSD In-Reply-To: <4767C338.4070709@freebsd.org> References: <47675291.5070101@swin.edu.au> <4767C338.4070709@freebsd.org> Message-ID: <7B13FFEE-F69D-4EBA-B734-356D8E63FDC7@cisco.com> Thanks to each of you. On Dec 18, 2007, at 4:55 AM, Andre Oppermann wrote: > Lawrence Stewart wrote: >> Hi all, >> We've been involved in a research project to implement and test an >> emerging TCP congestion control algorithm under FreeBSD. As a part of >> this, we've put together a patch for FreeBSD 7.0-BETA4 that >> modularises >> the congestion control code in the TCP stack. It allows for new >> congestion control algorithms to be developed as loadable kernel >> modules. >> This improves FreeBSD's usefulness as a TCP research platform and >> makes >> it easier to customise the stack for specific scenarios like high >> bandwidth, long delay paths. >> There is an accompanying technical report "Light-Weight Modular >> TCP Congestion Control for FreeBSD 7" [1] that covers the design, >> features, kernel interface and usage of the framework. Also on our >> website is >> a beta release of a module that implements the H-TCP[2] congestion >> control >> algorithm proposed by the Hamilton Institute. >> We believe that modular congestion control is a worthwhile >> addition to >> FreeBSD. We've performed significant internal testing and there are >> currently no known issues or regressions with the implementation >> compared to a 'vanilla' FreeBSD 7.0-BETA4 kernel. We would welcome >> further review and testing from the wider community in the hope of >> getting this >> patch folded into FreeBSD 8-CURRENT. >> SIFTR [3], our tool for monitoring FreeBSD kernel TCP connection >> state, has also >> received a minor update to v1.1.5, with the addition of 6 new, >> useful variables. >> All code and documentation is available on our website[3]. > > I've started to completely overhaul tcp_input and tcp_output > including separating out the congestion control. Actually it > is similiar to the way you seem to do it. > > A quick glance at your patch shows a couple of style issues > and a complete lack of locking. > > Let me get you a Perforce account so we can develop and complete > this work together. I'll create a Perforce branch and import my > code and work in progress. > > -- > Andre From gorinsky at arl.wustl.edu Thu Dec 20 12:18:25 2007 From: gorinsky at arl.wustl.edu (Sergey Gorinsky) Date: Thu, 20 Dec 2007 14:18:25 -0600 (CST) Subject: [e2e] Call for Papers: IEEE INFOCOM 2008 High-Speed Networks Workshop (HSN 2008) Message-ID: Call for Papers IEEE INFOCOM 2008 High-Speed Networks Workshop (HSN 2008) Phoenix, Arizona, USA Sunday, April 13, 2008, from 1 pm to 6 pm http://www.arl.wustl.edu/~hsn2008 Technical Sponsors * IEEE ComSoc Technical Committee on High-Speed Networking (TCHSN) * IEEE ComSoc Optical Networking Technical Committee (ONTC) Traditionally held in conjunction with IEEE INFOCOM, the workshop on High-Speed Networks brings together researchers from a wide spectrum of areas related to end-to-end communications at rates up to the Tbps range. While physical transmission media enable such high-bitrate communications, existing link, network, transport, and application protocols and their software and hardware implementations in both end systems and core nodes have not yet realized this potential. The limitations of the current designs justify exploration of novel clean-slate approaches to dependable high-bitrate networking desired in e-Science, medicine, entertainment, data centers and other application domains. HSN 2008 provides a unique forum for discussions centered on the design, validation and deployment of high-speed networks without imposing the constraint of straightforward integration of the proposed ideas into the existing network infrastructure. All topics pertinent to high-speed networking are of interest. They include but are not limited to the following: * Network architectures including clean-slate approaches * Switching technologies including packet and circuit switching * Transport protocols including congestion control, scheduling and reliable delivery * Applications requiring high-speed end-to-end services * Cross-layer network protocols * Security at high bitrates and with large data volumes * Node design including network processors, configurable logic, input/output and storage * Innovative physical transmission media and associated systems * Metropolitan area networks, Carrier Ethernet and next-generation optical transport * High-speed access technologies Submission Guidelines The workshop solicits submissions between 3 and 6 pages long. The following is a summary of the submission guidelines: * File format: PDF * Formatting instructions (except for the size): http://cse.unl.edu/~byrav/INFOCOM2008/paper-layout.html * Size of original submissions: between 3 and 6 pages * Maximum size of camera-ready versions: 6 pages * System for original submissions and reviews: EDAS * Publication venue for camera-ready versions: IEEE Xplore Important dates are as follows: * Paper submission: February 7, 2008 * Acceptance notification: March 15, 2008 * Camera-ready version due: April 4, 2008 General Chairs * Nasir Ghani, University of New Mexico, USA * Byrav Ramamurthy, University of Nebraska-Lincoln, USA Technical Program Committee Chairs * Sergey Gorinsky, Washington University in St. Louis, USA * Ashwin Gumaste, Indian Institute of Technology (IIT), Bombay, India Technical Program Committee * Lachlan Andrew, California Institute of Technology, USA * Torsten Braun, University of Bern, Switzerland * Georg Carle, University of Tuebingen, Germany * Vincent Chan, Massachusetts Institute of Technology, USA * Lars Eggert, Nokia Research Center, Finland * Maurice Gagnaire, ENST, France * Sergey Gorinsky, Washington University in St. Louis, USA * Ashwin Gumaste, Indian Institute of Technology (IIT), Bombay, India * Mohan Gurusamy, National University of Singapore, Singapore * David Hunter, University of Essex, UK * Jason Jue, University of Texas at Dallas, USA * Admela Jukan, Technical University of Braunschweig, Germany * Ken-ichi Kitayama, Osaka University, Japan * Tom Lehman, University of Southern California, ISI-East, USA * Jayaram Mudigonda, HP Labs, USA * Bernhard Plattner, ETH Zurich, Switzerland * Chunming Qiao, State University of New York Buffalo, USA * Srinivasan Ramasubramanian, University of Arizona, USA * Nageswara Rao, Oak Ridge National Labs, USA * Joel Rodrigues, University of Beira Interior, Portugal * George Rouskas, North Carolina State University, USA * Takashi Shimizu, NTT Network Innovation Laboratories, Japan * David Starobinski, Boston University, USA * Suresh Subramaniam, George Washington University, USA * Joe Touch, University of Southern California, ISI, USA * Marcel Waldvogel, University of Konstanz, Germany * Jianping Wang, City University of Hong Kong, Hong Kong * Tilman Wolf, University of Massachusetts Amherst, USA * Lisong Xu, University of Nebraska-Lincoln, USA From pganti at gmail.com Tue Dec 18 14:47:07 2007 From: pganti at gmail.com (Paddy Ganti) Date: Tue, 18 Dec 2007 17:47:07 -0500 Subject: [e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers? In-Reply-To: <47683416.3010109@cs.unc.edu> References: <2ff1f08a0712181111s54522b88id612adcc422ea68a@mail.gmail.com> <47683416.3010109@cs.unc.edu> Message-ID: <2ff1f08a0712181447i279509d1xf9f00c96d5c40f17@mail.gmail.com> Jasleen, Thank you for the pointers.Your ICNP '07 is very good as it is exactly looking at what I am proposing to do. Speaking of feedback, I have a quick question on splicing your data further. I want to know what your data will look like if I were to eliminate the SYN packets and then the FIN packet (more precisely the last packet) . On Table V in the paper regarding dupack threshold I have seen implementations with 1 and an extra timer (both ends of the stack speak modified TCP and hence they could get away with it). -Paddy On Dec 18, 2007 3:56 PM, Jasleen Kaur wrote: > > Paddy, > > You'll find our recent work on studying the performance of TCP loss > detection useful (please see the two citations below). One of the > data-sets we've used (ibi) is collected from a cluster of web-servers > --- however, this cluster also handles some fairly large file transfers. > > The first paper below studies the impact of configuring RTO and FR/R > parameters on the durations of TCP connections. > We've found that RTOs are still pretty common (more than FR/R). > Interestingly, we've found that reconfiguring the parameters > associated with these can help improve the situation to some extent (the > overall impact on connection durations can sometimes > be quite significant). > > S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss > Detection/Recovery in Real-world TCP Implementations", in Proceedings of > the IEEE International Conference on Network Protocols (ICNP'07), > Beijing, China, Oct 2007. > http://www.cs.unc.edu/~jasleen/papers/icnp07.pdf > > Rewaskar, J. Kaur, and F.D. Smith, "A Passive State-Machine Approach for > Accurate Analysis of TCP Out-of-Sequence Segments", in ACM Computer > Communications Review (CCR), July 2006. > http://www.cs.unc.edu/~jasleen/papers/ccr06.pdf > > We'd welcome any feedback. > > Thanks, > Jasleen > > > Paddy Ganti wrote: > > Hello e2e, > > > > Does anyone have some quantitative experimental data on what > > percentage of reliable packet delivery in TCP is done through Fast > > Retransmit versus that of a RTO expiry? Specifically I am looking at > > such data being available for HTTP class of traffic. > > > > Some raw issues that lead for such data to be interesting: > > > > (a) When the initial cwnd is less than 4 then there is a chance that > > initial SYN/SYNACK oss cannot be recovered using FastRetransmit (this > > is also worse than RTO expiry because of additional 3 seconds).Magic > > value of 4 seems to be from the paper Morris' /Scalable TCP > > Congestion Control/ > > > > (b) The last packet isnt eligible for fast retransmit as well by the > > same logic albeit this time the recovert via RTO > > > > (c) In between (a) and (b) lets say we have a train of packets > > (dictated by the cwnd size or the application's PSH). If you imagine > > this flight of packets as a train, the last packet of such a burst > > cannot also be recovered using fast retransmit > > > > (d) Some other cases that I am not thinking of here. > > > > Given that HTTP traffic seems to be like small bursts of packet > > trains, there will be many last packets in a train and hence response > > time suffers on lossy/congested networks. > > > > -Paddy Ganti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071218/b65e0763/attachment.html