From Jon.Crowcroft at cl.cam.ac.uk Sun Nov 1 02:10:52 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 01 Nov 2009 10:10:52 +0000 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AECB04F.8020802@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> Message-ID: There definitely are lessons in the evolution from end-mediated contention to switch-mediated access in ethernet-land. The oft-perceived analogy of the whole internet as a big ethernet, a huge shared resource with contention mainly mediated by end systems, is alluring. So the move to net/switch-centric resource allocation/control in the local, might suggest some similar move in the wide area... until you actually think about the heterogeneity in the topology, in capacity and in latency, of the system - Plenty of enterprise nets and small ISPs (e.g. UK size) can consider a carrier-grade switched ether control philosophy (e.g. esp. to replace complicated MPLS setups:) but it doesn't subsume/replace e2e resource sharing - It doesn't address multihomeing, multipath, mobility or multicast in any useful way either...it doesn't speak to swarms and CDNs much either. There were other lan technologies which didn't have built in collapse as part of the media-sharing protocols so the lesson wasn't as widely necessary as the e2e monoculture pretends (people who built token and slotted rings had other views of the world too:) On the other hand, it would be instructive to see how many end&edge systems are now on wireless ethernet and to see if the balance has swung back once again in "favour" of shared media/contention. aloha jon From Jon.Crowcroft at cl.cam.ac.uk Sun Nov 1 06:49:38 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 01 Nov 2009 14:49:38 +0000 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AED9B58.30809@reed.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AED9B58.30809@reed.com> Message-ID: well to be specific, TCP retransmission times and TCP congestion control were NOT designed in from day 1 early TCPs had fixed retransmit until the RSRE algorithm and then it was still some time before the Karn/Partridge improvements kicked in plus early TCPs had no congestion control at all until '87 however, since then the adaptation of timers and the adaption of flow rates makes the interweb look very much like a giant contention ethernet - in fact for exactly the same reason as voice on ethernet never was a big deal, voice on the interweb requires you to have a path running at releatively low utilisation otherwise delays diverge...and loss kicks in one thing (van pointed this out in a talk here a couple of days ago) that saves it from the same fate as pure contention systems is that there's a packet conservation principle... again NOT something designed in the original TCP so that's 3 new principles within the end2end system that actually weren't in the original design of the protocols that I count...there's a few other ones lurking inside IP too, but thats to do with routing, and as Bob Braden so wisely says, "we don't do routing in e2e" In missive <4AED9B58.30809 at reed.com>, "David P. Reed" typed: >>This is a multi-part message in MIME format. >>--------------080003040602040709060908 >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: 7bit >> >>There are probably also lessons in the evolution from networks that are >>synchronized with clocks that must have timing with parts-per-billion >>accuracy (the "Bell System" architecture - e.g. SONET) to networks that >>allow for internal retiming, buffering, etc. >> >>That doesn't mean that it is a fact that IP is a thin layer over such >>clock-synchronized networks, which still exist and carry IP traffic. >>Nor is TCP designed to be corrective of such networks brittle >>unreliability, which leads to rerouting over alternate paths that may >>cause transient out-of-order delivery, duplication, and a need to >>reallocate resources. >> >>TCP and IP were designed to handle heterogeneity and best efforts, and >>the idea that they were either designed to remedy Aloha or evolved so >>that they only run on Ethernet - that is nonsense, a just so story. >> >>On 11/01/2009 05:10 AM, Jon Crowcroft wrote: >>> There definitely are lessons >>> in the evolution from >>> end-mediated contention to >>> switch-mediated access >>> in ethernet-land. >>> >>> The oft-perceived analogy >>> of the whole internet as a big ethernet, >>> a huge shared resource >>> with contention mainly mediated >>> by end systems, is alluring. >>> >>> So the move to >>> net/switch-centric resource allocation/control >>> in the local, >>> might suggest some similar move >>> in the wide area... >>> until you actually think about the >>> heterogeneity in the >>> topology, in capacity and in latency, >>> of the system - >>> >>> Plenty of enterprise nets and small ISPs >>> (e.g. UK size) can consider >>> a carrier-grade switched ether >>> control philosophy (e.g. >>> esp. to replace >>> complicated MPLS setups:) >>> but it doesn't subsume/replace e2e >>> resource sharing - >>> >>> It doesn't address >>> multihomeing, multipath, mobility or multicast >>> in any useful way either...it doesn't >>> speak to swarms and CDNs much either. >>> >>> There were other lan technologies >>> which didn't have built in collapse >>> as part of the media-sharing protocols >>> so the lesson wasn't as widely >>> necessary as the e2e monoculture >>> pretends (people who built >>> token and slotted rings >>> had other views of the world >>> too:) >>> >>> On the other hand, it would be instructive >>> to see how many end&edge systems are now on >>> wireless ethernet and to see if the balance has >>> swung back once again in "favour" of >>> shared media/contention. >>> >>> aloha >>> >>> jon >>> >>> >> >>--------------080003040602040709060908 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: 7bit >> >> >> >> >> > http-equiv="Content-Type"> >> >> >>There are probably also >>lessons in the evolution from networks that are synchronized with >>clocks that must have timing with parts-per-billion accuracy (the >>"Bell System" architecture - e.g. SONET) to networks that allow for >>internal retiming, buffering, etc.
>>
>>That doesn't mean that it is a fact that IP is a thin layer over such >>clock-synchronized networks, which still exist and carry IP traffic.  >>Nor is TCP designed to be corrective of such networks brittle >>unreliability, which leads to rerouting over alternate paths that may >>cause transient out-of-order delivery, duplication, and a need to >>reallocate resources.
>>
>>TCP and IP were designed to handle heterogeneity and best efforts, and >>the idea that they were either designed to remedy Aloha or evolved so >>that they only run on Ethernet - that is nonsense, a just so story.
>>
>>On 11/01/2009 05:10 AM, Jon Crowcroft wrote: >>
>> 
There definitely are lessons 
 >>in the evolution from 
 >>end-mediated contention to 
 >>switch-mediated access
 >>in ethernet-land.
 >>
 >>The oft-perceived analogy
 >>of the whole internet as a big ethernet,
 >>a huge shared resource 
 >>with contention mainly mediated
 >>by end systems, is alluring.
 >>
 >>So the move to 
 >>net/switch-centric resource allocation/control
 >>in the local, 
 >>might suggest some similar move
 >>in the wide area...
 >>until you actually think about the
 >>heterogeneity in the
 >>topology, in capacity and in latency,
 >>of the system - 
 >>
 >>Plenty of enterprise nets and small ISPs
 >>(e.g. UK size) can consider
 >>a carrier-grade switched ether
 >>control philosophy (e.g. 
 >>esp. to replace
 >>complicated MPLS setups:)
 >>but it doesn't subsume/replace e2e
 >>resource sharing - 
 >>
 >>It doesn't address 
 >>multihomeing, multipath, mobility or multicast
 >>in any useful way either...it doesn't
 >>speak to swarms and CDNs much either.
 >>
 >>There were other lan technologies
 >>which didn't have built in collapse
 >>as part of the media-sharing protocols
 >>so the lesson wasn't as widely
 >>necessary as the e2e monoculture
 >>pretends (people who built 
 >>token and slotted rings
 >>had other views of the world 
 >>too:)
 >>
 >>On the other hand, it would be instructive
 >>to see how many end&edge systems are now on
 >>wireless ethernet and to see if the balance has
 >>swung back once again in "favour" of 
 >>shared media/contention. 
 >>
 >>aloha
 >>
 >>jon
 >>
 >>
>>
>> >> >> >>--------------080003040602040709060908-- cheers jon From braden at ISI.EDU Sun Nov 1 10:01:26 2009 From: braden at ISI.EDU (Bob Braden) Date: Sun, 01 Nov 2009 10:01:26 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AED9B58.30809@reed.com> Message-ID: <4AEDCCF6.3090600@isi.edu> Jon Crowcroft wrote: > well to be specific, > TCP retransmission times > and > TCP congestion control > were NOT designed in from day 1 > > Jon, It does not really matter, of course, but your quick summary is not quite accurate. It depends upon what you consider to be "Day 1". E.g., RFC 793 did NOT have a fixed retransmit time. And if you want to give RSRE credit for exponentially smoothed RTT measurements (a fact I had forgotten, assuming you are correct), you ought to give Van credit for finally figuring out how to do real congestion control, in 1987. Bob Braden > early TCPs had fixed retransmit until the RSRE algorithm > and then it was still some time before the Karn/Partridge > improvements kicked in > plus > early TCPs had no congestion control at all > until '87 > > > From braden at ISI.EDU Sun Nov 1 10:16:20 2009 From: braden at ISI.EDU (Bob Braden) Date: Sun, 01 Nov 2009 10:16:20 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AECFAB6.8030705@reed.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AECFAB6.8030705@reed.com> Message-ID: <4AEDD074.8090302@isi.edu> David P. Reed wrote: > On 10/31/2009 05:46 PM, Richard Bennett wrote: >> the fact that IP is a very thin abstraction of the Ethernet layer 2 >> and that TCP is a vehicle for resolving problems that are typical of >> the CSMA/CD Ethernet environment > This statement is nonsense. IP is not a very thin abstraction of > Ethernet layer 2. IP is carried over many protocols other than the > Ethernet. TCP is an end-to-end protocol for in-order virtual circuit > data delivery, designed to work over IP, and to handle problems that > have nothing to do with CSMA/CD. > Dave Reed is right, of course. Richard Bennett's declarative statement is so far into an alternate universe from the real world that one has to suspect he is baiting the list. Dave used the word "nonsense" ... it seems to me to be difficult to deny the rightness of that word choice. Bob Braden From perfgeek at mac.com Sun Nov 1 10:45:28 2009 From: perfgeek at mac.com (rick jones) Date: Sun, 01 Nov 2009 10:45:28 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AECB04F.8020802@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> Message-ID: <6CC846B9-8317-4267-962A-10A24BAAB04A@mac.com> On Oct 31, 2009, at 2:46 PM, Richard Bennett wrote: > Dave Eckhardt wrote: >> So it's unclear >> that CSMA/CD was a structural limit of Ethernet--the reality >> is probably more like "It doesn't matter much how you contend >> among a few hosts, but you can't build large networks unless >> you limit contention domains to less than the size of the >> large network", which is almost a tautology. >> > That's part of the story, but the implications of the switched > Ethernet killing off CSMA/CD Ethernet are much larger, and relate > the end-to-end arguments principle. CSMA/CD Ethernet was an end- > point managed system sharing a dump pipe, while switched Ethernet is > a system that deploys intelligence - switching, flow control, > buffering, QoS discrimination, VLANs - inside the network at > multiple points. Switched Ethernet is scalable, manageable, > diagnosable, and future-proof, while CSMA/CD Ethernet is none of > these things. So the competition of CSMA/CD and Active Switching for > markets demonstrates something about which approach to the design of > layer 2 networks is superior. I think you left-out how Power over Ethernet will replace the global power grid and that it also juliennes fries :) Color me a cynic, but I rather thought that today's switched "Ethernet" needed flow control and buffering precisely because CSMA/CD was removed from Ethernet when it went full-duplex? I seem to recall that flow-control was not initially present in full-duplex Ethernet. I'm still not sure how much of the rest of the laundry list above has been added to Ethernet has been in response to folks going "Routing is hard, lets go shopping for switches" and the switch vendors being quite happy to provide a solution to encourage people to buy new switches. rick jones there is no rest for the wicked, yet the virtuous have no pillows From richard at bennett.com Sun Nov 1 13:26:02 2009 From: richard at bennett.com (Richard Bennett) Date: Sun, 01 Nov 2009 16:26:02 -0500 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <6CC846B9-8317-4267-962A-10A24BAAB04A@mac.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <6CC846B9-8317-4267-962A-10A24BAAB04A@mac.com> Message-ID: <4AEDFCEA.7020104@bennett.com> There was a need for flow control as soon as full dupex was included in the 10BASET spec, but it became even more important with the addition of 100BASETx to switches that were backward compatible with 10BASET. A collision is better than a silent drop, but neither is necessary. Full duplex Ethernet switches can transmit multiple frames at the same time, which is quite convenient in meet-me rooms at IXPs so I don't buy the routing vs. switching dichotomy; switching helps us do routing. The point about the thinness of the IP layer doesn't have to do with routing as much as it has to do with what's in the IP header and what isn't. I would expect that a network layer protocol would have an unambiguous address for the host, like CYCLADES, DECNet, XNS, and ISO CLNP. But all IP has is an address that's a synonym for the LAN interface address, a point of attachment. So it's not fully separated from Layer 2. This is especially stark in IPv6 where they just throw in the whole MAC address into the IP header in order to bypass ARP. In addition to IP lacking an actual host address, it doesn't do any protocol either - it's just a packet format and doesn't participate in any specific sequences of behavior, which is once again just like Blue Book Ethernet, AKA V2. It's perhaps worth noting that V2 is an odd MAC protocol since most of its cousins have multiple frame types and state machines for each, even Switched Ethernet. Granted, there is a network address in the IP header, for what it's worth, but IP seems to be missing some function that would make networking a lot easier than it is in scenarios where a number of diverse applications contend for resources, and some of the function it's missing was also missing in V2. This is true in many universes, some of the alternates to this one. Regarding Jon's comment on the rebirth of CSMA at the edge, there is some ironic truth to it, but Wi-Fi's not the same style as CSMA/CD because with 802.11n we have a selectively acknowledged windowing protocol, much more efficient than TCP where you have to discard everything after a dropped packet and do it again. I suspect that LTE is going to be a very large factor one day, and it uses a scheduled system that doesn't have collisions. RB rick jones wrote: > > On Oct 31, 2009, at 2:46 PM, Richard Bennett wrote: > >> Dave Eckhardt wrote: >>> So it's unclear >>> that CSMA/CD was a structural limit of Ethernet--the reality >>> is probably more like "It doesn't matter much how you contend >>> among a few hosts, but you can't build large networks unless >>> you limit contention domains to less than the size of the >>> large network", which is almost a tautology. >>> >> That's part of the story, but the implications of the switched >> Ethernet killing off CSMA/CD Ethernet are much larger, and relate the >> end-to-end arguments principle. CSMA/CD Ethernet was an end-point >> managed system sharing a dump pipe, while switched Ethernet is a >> system that deploys intelligence - switching, flow control, >> buffering, QoS discrimination, VLANs - inside the network at multiple >> points. Switched Ethernet is scalable, manageable, diagnosable, and >> future-proof, while CSMA/CD Ethernet is none of these things. So the >> competition of CSMA/CD and Active Switching for markets demonstrates >> something about which approach to the design of layer 2 networks is >> superior. > > I think you left-out how Power over Ethernet will replace the global > power grid and that it also juliennes fries :) > > Color me a cynic, but I rather thought that today's switched > "Ethernet" needed flow control and buffering precisely because CSMA/CD > was removed from Ethernet when it went full-duplex? I seem to recall > that flow-control was not initially present in full-duplex Ethernet. > I'm still not sure how much of the rest of the laundry list above has > been added to Ethernet has been in response to folks going "Routing is > hard, lets go shopping for switches" and the switch vendors being > quite happy to provide a solution to encourage people to buy new > switches. > > rick jones > there is no rest for the wicked, yet the virtuous have no pillows > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From perfgeek at mac.com Sun Nov 1 13:57:17 2009 From: perfgeek at mac.com (rick jones) Date: Sun, 01 Nov 2009 13:57:17 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AEDFCEA.7020104@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <6CC846B9-8317-4267-962A-10A24BAAB04A@mac.com> <4AEDFCEA.7020104@bennett.com> Message-ID: <254482CC-0546-4832-95B0-BE4EE4BA0AE3@mac.com> On Nov 1, 2009, at 1:26 PM, Richard Bennett wrote: > Regarding Jon's comment on the rebirth of CSMA at the edge, there is > some ironic truth to it, but Wi-Fi's not the same style as CSMA/CD > because with 802.11n we have a selectively acknowledged windowing > protocol, much more efficient than TCP where you have to discard > everything after a dropped packet and do it again. My history with TCP stacks does not go back "to the beginning" (whatever that might actually be), and I did not start in the "PC" space so perhaps my life was charmed, but going back to 1988 I'd not encountered any TCP where that was the case. rick jones there is no rest for the wicked, yet the virtuous have no pillows From Jon.Crowcroft at cl.cam.ac.uk Mon Nov 2 01:37:22 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 02 Nov 2009 09:37:22 +0000 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AEDCCF6.3090600@isi.edu> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AED9B58.30809@reed.com> <4AEDCCF6.3090600@isi.edu> Message-ID: In missive <4AEDCCF6.3090600 at isi.edu>, Bob Braden typed: >>It does not really matter, of course, but your quick summary is not >>quite accurate. >>It depends upon what you consider to be "Day 1". E.g., RFC 793 did NOT absolutely - sorry - i was talkin about first cut at design - the RSRE discussion predates the RFC and the result made it in to the spec.. >>have a >>fixed retransmit time. And if you want to give RSRE credit for >>exponentially smoothed >>RTT measurements (a fact I had forgotten, assuming you are correct), you see IEN160 for the discussion and credit - was a couple of years before i was doin this sort of thing so you prob. know more about this than me... http://www.postel.org/ien/pdf/ien160.pdf but the smarter smoothing happened in 87 (using smoothed mean + mean squre difference for retransmit rather than just EWMA) and the late 80s stuff had input from Karn&Partridge >>ought to >>give Van credit for finally figuring out how to do real congestion >>control, in 1987. of course! but that work is so heavily cited I just thought everyone would know it anyhow :) one should also cite Raj Jain and KK Ramakrishnan for the DECNET work from which some of it came, and Frank Kelly for packet conservation ideas but the purpose of my comment wasnt to go down memory lane and build a perfect family tree of ideas (that would be a good thing to do e.g. based o na code audit:) but to point out that the original designers did NOT get everything right in one go... indeed some of donald davies' (and others) original ideas about resource pooling and congestion control which were integral in his vision of packet switching, were actually lost from between early 70s and late 80s... alas... suppose those who teach history are doomed to repeat themselves:) >>> early TCPs had fixed retransmit until the RSRE algorithm >>> and then it was still some time before the Karn/Partridge >>> improvements kicked in >>> plus >>> early TCPs had no congestion control at all >>> until '87 >>> >>> >>> >> >> >> cheers jon From dpreed at reed.com Mon Nov 2 08:33:06 2009 From: dpreed at reed.com (David P. Reed) Date: Mon, 02 Nov 2009 11:33:06 -0500 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> Message-ID: <4AEF09C2.3040106@reed.com> There are probably also lessons in the evolution from networks that are synchronized with clocks that must have timing with parts-per-billion accuracy (the "Bell System" architecture - e.g. SONET) to networks that allow for internal retiming, buffering, etc. That doesn't mean that it is a fact that IP is a thin layer over such clock-synchronized networks, which still exist and carry IP traffic. Nor is TCP designed to be corrective of such networks brittle unreliability, which leads to rerouting over alternate paths that may cause transient out-of-order delivery, duplication, and a need to reallocate resources. TCP and IP were designed to handle heterogeneity and best efforts, and the idea that they were either designed to remedy Aloha or evolved so that they only run on Ethernet - that is nonsense, a just so story. On 11/01/2009 05:10 AM, Jon Crowcroft wrote: > There definitely are lessons > in the evolution from > end-mediated contention to > switch-mediated access > in ethernet-land. > > The oft-perceived analogy > of the whole internet as a big ethernet, > a huge shared resource > with contention mainly mediated > by end systems, is alluring. > > So the move to > net/switch-centric resource allocation/control > in the local, > might suggest some similar move > in the wide area... > until you actually think about the > heterogeneity in the > topology, in capacity and in latency, > of the system - > > Plenty of enterprise nets and small ISPs > (e.g. UK size) can consider > a carrier-grade switched ether > control philosophy (e.g. > esp. to replace > complicated MPLS setups:) > but it doesn't subsume/replace e2e > resource sharing - > > It doesn't address > multihomeing, multipath, mobility or multicast > in any useful way either...it doesn't > speak to swarms and CDNs much either. > > There were other lan technologies > which didn't have built in collapse > as part of the media-sharing protocols > so the lesson wasn't as widely > necessary as the e2e monoculture > pretends (people who built > token and slotted rings > had other views of the world > too:) > > On the other hand, it would be instructive > to see how many end&edge systems are now on > wireless ethernet and to see if the balance has > swung back once again in "favour" of > shared media/contention. > > aloha > > jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091102/c8dc5eb4/attachment.html From suzihollis at hotmail.co.uk Thu Nov 5 01:55:44 2009 From: suzihollis at hotmail.co.uk (suzi) Date: Thu, 5 Nov 2009 09:55:44 -0000 Subject: [e2e] mail enquirey Message-ID: hi can you tell me if you are the company sending me mail in the post if you are i need some pre-paid envelopes. could you let me know thanks susan hollis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091105/177b0635/attachment.html From suzihollis at hotmail.co.uk Fri Nov 6 04:23:53 2009 From: suzihollis at hotmail.co.uk (sue hollis) Date: Fri, 6 Nov 2009 12:23:53 +0000 Subject: [e2e] end2end-interest Digest, Vol 68, Issue 4 In-Reply-To: References: Message-ID: hi ive been recieving post this week thru my letter box but need to send them back at the end of this week, also i need to log onto my account but you havnt sent me any emails to do this as i need to log on to let you know what days i recieve the mail. please reply to this as im unsure what to do now. many thanks susan hollis > From: end2end-interest-request at postel.org > Subject: end2end-interest Digest, Vol 68, Issue 4 > To: end2end-interest at postel.org > Date: Thu, 5 Nov 2009 12:00:00 -0800 > > Send end2end-interest mailing list submissions to > end2end-interest at postel.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.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. mail enquirey (suzi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 5 Nov 2009 09:55:44 -0000 > From: "suzi" > Subject: [e2e] mail enquirey > To: > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > hi can you tell me if you are the company sending me mail in the post if you are i need some pre-paid envelopes. could you let me know thanks susan hollis > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091105/177b0635/attachment-0001.html > > ------------------------------ > > _______________________________________________ > end2end-interest mailing list > end2end-interest at postel.org > http://mailman.postel.org/mailman/listinfo/end2end-interest > > > End of end2end-interest Digest, Vol 68, Issue 4 > *********************************************** _________________________________________________________________ New Windows 7: Find the right PC for you. Learn more. http://www.microsoft.com/uk/windows/buy/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091106/731e5683/attachment.html From detlef.bosau at web.de Wed Nov 11 11:11:50 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 11 Nov 2009 20:11:50 +0100 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AECB04F.8020802@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> Message-ID: <4AFB0C76.9000004@web.de> Richard Bennett wrote: > > In other words: does the success of Switched Ethernet suggest that > it's better to think of network protocols as units of recursion than > as collections of statically-placed functions that operate once and > only once in the lifetime of a packet? > > RB I've just had a very first glance at this discussion. (Thanks god, I first wrote the post by Joe....) However, I'm a bit curious what this discussion is all about. Many of us enjoy Switched Ethernet, me too. However, what is the very issue with switched Ethernet from the end to end arguments point of view? And second: Shall switched Ethernet replace TCP/IP? If not: What is this argument all about? Just curious. Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From richard at bennett.com Wed Nov 11 16:08:26 2009 From: richard at bennett.com (Richard Bennett) Date: Wed, 11 Nov 2009 16:08:26 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFB0C76.9000004@web.de> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> Message-ID: <4AFB51FA.9070609@bennett.com> Classical Ethernet - the co-ax cable-based, Aloha-derived CSMA/CD system - is one of the canonical examples of a purely edge-managed network. It actually hails from the era during which the Internet protocols were designed, and expresses a similar set of engineering trade-offs. Thirty-five years after the design of Ethernet, we've dropped the purely edge-managed approach to building layer 1 and 2 networks in favor of somewhat more centralized systems: Switched Ethernet, DOCSIS, DSL, Wi-Max, and Wi-Fi are the leading examples. These systems aren't purely centralized, of course; they're more like multiply-centralized meshes than either edge-managed or core-managed systems. While we now know that edge-managed LANs and MANs are not the way to go, we still use edge-managed protocols to operate the Internet. The Jacobson Algorithm is probably the purest example. The triumph of switched and semi-centralized systems at layer 2 suggests that it might be beneficial to revisit some of the design tradeoffs at layer 3 if for no other reason than to bring them up-to-date. In principle, IP isn't supposed to care what's happening at layer 2, but in practice it makes a great deal of difference; this is one reason that people design networks nowadays with the express intention of being good for IP; e.g., MPLS. That's the general idea. RB Detlef Bosau wrote: > Richard Bennett wrote: >> >> In other words: does the success of Switched Ethernet suggest that >> it's better to think of network protocols as units of recursion than >> as collections of statically-placed functions that operate once and >> only once in the lifetime of a packet? >> >> RB > > I've just had a very first glance at this discussion. (Thanks god, I > first wrote the post by Joe....) > > However, I'm a bit curious what this discussion is all about. > > Many of us enjoy Switched Ethernet, me too. However, what is the very > issue with switched Ethernet from the end to end arguments point of view? > > And second: Shall switched Ethernet replace TCP/IP? > > If not: What is this argument all about? > > Just curious. > > Detlef > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From detlef.bosau at web.de Thu Nov 12 08:15:54 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 12 Nov 2009 17:15:54 +0100 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFB51FA.9070609@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> Message-ID: <4AFC34BA.8090807@web.de> O.k., I still don't have an idea, what this argument is all about. Nevertheless: Richard Bennett wrote: > Classical Ethernet - the co-ax cable-based, Aloha-derived CSMA/CD > system - is one of the canonical examples of a purely edge-managed > network. First of all, classical Ethernet is the canonical example of classical Ethernet. Period. No one was forced to use classical Ethernet, and no one was forced to avoid classical Ethernet. The discussion initiated by Salzer, Reed and Clark was _not_, whether or not a certain network technology should have management capabilies, leaky bucket facilities, SNMP agents or whatever. Instead, the authors invite us to carefully consider, where certain functions, duties, responsibilities should be placed and where not. IIRC, Dave Reed told us, there were no such think like an "end to end principle" some weeks ago. And in fact, there is none. But it is useful to carefully consider the placement and separation of concerns and responsibilities. No more, no less. > It actually hails from the era during which the Internet protocols > were designed, and expresses a similar set of engineering trade-offs. And scientists and priests still argue, whether we hail from adam and eve - or from apes and evolution. Would this make a difference? Despite of the fact, that mankind should rather behave like apes (and hopefully, apes still do!), because we wouldn't have seen thermonuclear weapons and many other "human inventions" then? When I use a network, my primary interest is not its historical origin but its use for my problem. > Thirty-five years after the design of Ethernet, we've dropped the > purely edge-managed approach to building layer 1 and 2 networks in > favor of somewhat more centralized systems: Switched Ethernet, DOCSIS, > DSL, Wi-Max, and Wi-Fi are the leading examples. You mentioned some examples where some separations of concerns might have been done in a different way than 1985. Wonderful! When there are compelling reasons for doing so: Go ahead! > > While we now know that edge-managed LANs and MANs are not the way to > go, we still use edge-managed protocols to Why not? Typically, it's a good idea to fit a solution to a problem and not the other way round. So, first of all, I will have a look at my problem, e.g. how many systems are to be connected, are there constraints, e.g. I must not use a wireline connection in a certain scenario and so on, and then I will make a choice for a certain networking technology. This may be switched Ethernet - or it may be something different. Depending on my actual needs and my actual constraints. > operate the Internet. The Jacobson Algorithm is probably the purest > example. And I don't see, how switched Ethernet provides an alternative to VJCC. > > The triumph of switched and semi-centralized systems at layer 2 > suggests that it might be beneficial to revisit some of Excuse me, but where is the triumph of switched Ethernet over VJCC? > the design tradeoffs at layer 3 if for no other reason than to bring > them up-to-date. In principle, IP isn't supposed to care what's > happening at layer 2, but it's always a good idea for IP, not to ignore the lower layers. (I'm actually writing a very small and tiny network simulator, because NS2 and other ones are still to big for my purposes and it's quite appealing to have a small simulator in some few hundred lines of Java, which simply does its job. However, it would really spare me quite a few night sessions, if IP could really ignore the lower layers.) > but in practice it makes a great deal of difference; this is one > reason that people design networks nowadays with the express intention > of being good for IP; e.g., MPLS. > Excuse me, but I don't see your point. We can well discuss the advantages of circuit switching over packet switching or the other way round. However, both have their justification and both are in use for several decades now. And I really don't see the big difference between placing a flow label into an Ethernet frame or to introduce some "Flow Switching Over Ethernet Protocol (FSOEP)" to achieve the same goal. This is a major argument for minor a minor benefit. Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From richard at bennett.com Thu Nov 12 15:10:27 2009 From: richard at bennett.com (Richard Bennett) Date: Thu, 12 Nov 2009 15:10:27 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFC34BA.8090807@web.de> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> Message-ID: <4AFC95E3.3000505@bennett.com> Detlef, I'm asking you to think abstractly about certain problems in the design of distributed systems. I regard many of the interpretations and applications of end-to-end notions to network management and regulation as flawed, regardless of the intent of any of the authors of any particular paper decades ago, or even to their subsequent refinement by the original authors or others. One the problems that arises in distributed systems is access to shared resources, and the end-to-end solution to this problem is deeply flawed. In order to share resources according to a policy, there needs to be a system element enforcing the policy. In network operations, this function is indispensable and must be part of the network infrastructure. There are many reasons for this, of course, but the chief ones are a) the lack of reliability and trust in end systems; and b) the lack of information about system demand on the part of the end system, which in principle only knows that it wants and not what anyone else wants to do on the shared resource. The idea that access to shared resources is best accomplished by uncoordinated end systems leads to a lot of grief. What does this have to do with Jacobson's Algorithm? A lot, it turns out, as we see in the rise of systems that take the job of congestion mediation a couple of steps further, such as ECN and Re-ECN. If you recognize that information about the state of shared resources is essential to their rational management, no problem. Of course, all of this is simply to say that optimal solutions to problems of resource management can only be made close to the resource in question, but it doesn't address a later version of the end-to-end arguments principle, that sub-optimal solutions (from an efficiency of fair-sharing perspective) to such problems may be preferred if they lead to greater system generality, opportunities for innovation, free speech, reliability, or some other reason. I hear this sort of argument being made very frequently these days, and it does have some resonance. Efficiency is after all a short-term goal, while generality is a long-term goal and innovation is a positive externality. But to appreciate that, one needs to think a bit abstractly. RB Detlef Bosau wrote: > O.k., I still don't have an idea, what this argument is all about. > > Nevertheless: > > Richard Bennett wrote: >> Classical Ethernet - the co-ax cable-based, Aloha-derived CSMA/CD >> system - is one of the canonical examples of a purely edge-managed >> network. > > First of all, classical Ethernet is the canonical example of classical > Ethernet. > > Period. > > No one was forced to use classical Ethernet, and no one was forced to > avoid classical Ethernet. > > The discussion initiated by Salzer, Reed and Clark was _not_, whether > or not a certain network technology should have management capabilies, > leaky bucket facilities, SNMP agents or whatever. Instead, the authors > invite us to carefully > consider, where certain functions, duties, responsibilities should be > placed and where not. > > IIRC, Dave Reed told us, there were no such think like an "end to end > principle" some weeks ago. > > And in fact, there is none. But it is useful to carefully consider the > placement and separation of concerns and responsibilities. No more, no > less. > > >> It actually hails from the era during which the Internet protocols >> were designed, and expresses a similar set of engineering trade-offs. > > And scientists and priests still argue, whether we hail from adam and > eve - or from apes and evolution. > > Would this make a difference? Despite of the fact, that mankind should > rather behave like apes (and hopefully, apes still do!), because we > wouldn't have seen thermonuclear weapons and many other "human > inventions" then? > > When I use a network, my primary interest is not its historical origin > but its use for my problem. > >> Thirty-five years after the design of Ethernet, we've dropped the >> purely edge-managed approach to building layer 1 and 2 networks in >> favor of somewhat more centralized systems: Switched Ethernet, >> DOCSIS, DSL, Wi-Max, and Wi-Fi are the leading examples. > > You mentioned some examples where some separations of concerns might > have been done in a different way than 1985. > > Wonderful! > > When there are compelling reasons for doing so: Go ahead! > >> >> While we now know that edge-managed LANs and MANs are not the way to >> go, we still use edge-managed protocols to > > Why not? > > Typically, it's a good idea to fit a solution to a problem and not the > other way round. > > So, first of all, I will have a look at my problem, e.g. how many > systems are to be connected, are there constraints, e.g. I must not > use a wireline connection in a certain scenario and so on, and then I > will make a choice for a certain networking technology. > > This may be switched Ethernet - or it may be something different. > Depending on my actual needs and my actual constraints. > > >> operate the Internet. The Jacobson Algorithm is probably the purest >> example. > > And I don't see, how switched Ethernet provides an alternative to VJCC. > >> >> The triumph of switched and semi-centralized systems at layer 2 >> suggests that it might be beneficial to revisit some of > > Excuse me, but where is the triumph of switched Ethernet over VJCC? > >> the design tradeoffs at layer 3 if for no other reason than to bring >> them up-to-date. In principle, IP isn't supposed to care what's >> happening at layer 2, > > but it's always a good idea for IP, not to ignore the lower layers. > > (I'm actually writing a very small and tiny network simulator, because > NS2 and other ones are still to big for my purposes and it's quite > appealing to have a small simulator in some few hundred lines of Java, > which simply does its job. > > However, it would really spare me quite a few night sessions, if IP > could really ignore the lower layers.) > >> but in practice it makes a great deal of difference; this is one >> reason that people design networks nowadays with the express >> intention of being good for IP; e.g., MPLS. >> > > Excuse me, but I don't see your point. > > We can well discuss the advantages of circuit switching over packet > switching or the other way round. > > However, both have their justification and both are in use for several > decades now. > > And I really don't see the big difference between placing a flow label > into an Ethernet frame or to introduce some > "Flow Switching Over Ethernet Protocol (FSOEP)" to achieve the same goal. > > This is a major argument for minor a minor benefit. > > Detlef > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From braden at ISI.EDU Thu Nov 12 16:47:27 2009 From: braden at ISI.EDU (Bob Braden) Date: Thu, 12 Nov 2009 16:47:27 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFC95E3.3000505@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> Message-ID: <4AFCAC9F.3060808@isi.edu> Richard Bennett wrote: > Detlef, I'm asking you to think abstractly about certain problems in > the design of distributed systems. I regard many of the > interpretations and applications of end-to-end notions to network > management and regulation as flawed, regardless of the intent of any > of the authors of any particular paper decades ago, or even to their Richard, I am sure that the Internet designers (who wrote running code before they wrote papers) will be greatly relieved to know that you ascribe good intentions to them. My only problem is that you think they were well intnetioned but wrong, while I believe that they were well intentioned and right. Given the history of the Internet, this seems hard to deny. > subsequent refinement by the original authors or others. > > One the problems that arises in distributed systems is access to > shared resources, and the end-to-end solution Yes, and those shared resources are queues (or equivalently, lines) > to this problem is deeply flawed. This seems to be proof by assertion. > In order to share resources according to a policy, there needs to be a > system element enforcing the policy. Well, no. There are papers showing that is not strictly true.. > In network operations, this function is indispensable and must be part > of the network infrastructure. There are many reasons for this, of > course, but the chief ones are a) the lack of The Internet demonstrates that your assertion "must be part of the network infrastructure" is incorrect. > reliability and trust in end systems; and b) the lack of information > about system demand on the part of the end The fate sharing concept shows that the reliability and trust in end systems is irrelevant. > system, which in principle only knows that it wants and not what > anyone else wants to do on the shared resource. > > The idea that access to shared resources is best accomplished by > uncoordinated end systems leads to a lot of grief. > "Greif" is one of those loaded words that is inappropriate to this discussion, but in any case "uncoordinated end systems" also leads to a lot of advantages, like application-neutrality of the network. Have you Skyped lately? A lot of people will be surprised when you tell them it is fatally flawed. > What does this have to do with Jacobson's Algorithm? A lot, it turns > out, as we see in the rise of systems that take the job of congestion > mediation a couple of steps further, such as ECN and Re-ECN. If you > recognize that information about the state of shared resources is > essential to their rational management, no problem. > "Rational" -- another of those Words. It clearly is not essential (we got along pretty well with simple VJCC and cumulative ACKs, but certainly SACK, RED, and ECN all extend the range of efficient performance. But yes, I agree with you, it helps a lot if the end systems have some knowledge of conditions along the path. > Of course, all of this is simply to say that optimal solutions to > problems of resource management can only be made close to the resource > in question, but it doesn't address a later version of the end-to-end > arguments principle, that sub-optimal solutions (from an efficiency of > fair-sharing perspective) to such problems may be preferred if they > lead to greater system generality, opportunities for innovation, free > speech, reliability, or some other reason. > > I hear this sort of argument being made very frequently these days, > and it does have some resonance. Efficiency is after all a short-term > goal, while generality is a long-term goal and innovation is a > positive externality. But to appreciate that, one needs to think a bit > abstractly. So we are having an agreement, except for your implication that the Internet designers did not think abstractly but you do. I can assure you that they did think abstractly, and around 1980 came to exactly the conclusions of your last paragraph. Now can we find some new Dead Horse to beat? Or even add some new insights? Bob Braden > > RB > >> > From braden at ISI.EDU Thu Nov 12 17:58:02 2009 From: braden at ISI.EDU (Bob Braden) Date: Thu, 12 Nov 2009 17:58:02 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFCAC9F.3060808@isi.edu> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> Message-ID: <4AFCBD2A.90006@isi.edu> Bob Braden wrote: > > "Greif" is one ... ("Good grief, Charlie Brown!") Bob Braden From richard at bennett.com Thu Nov 12 18:45:19 2009 From: richard at bennett.com (Richard Bennett) Date: Thu, 12 Nov 2009 18:45:19 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFCAC9F.3060808@isi.edu> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> Message-ID: <4AFCC83F.3010406@bennett.com> I'm not persuaded that the best engineering solution always wins the prize, Bob: VHS vs. Beta for example. I think there's a lot of evidence to suggest that non-engineering factors have had a lot to do with the hegemony of TCP/IP. It's difficult to respond in detail to the following as much of it is mid-sentence complaints about thing that happen to be answered in the next phrase or so, but I will say I don't imply that the designers of internetworks didn't think abstractly; Pouzin certainly did and still does.But I am saying the argument that a particular sub-optimal design is best for a production network because it happens to avoid fate-sharing or support innovation seems a bit like grasping at straws. Secure, reliable, and efficient networks support innovation best. RB Bob Braden wrote: > Richard Bennett wrote: >> Detlef, I'm asking you to think abstractly about certain problems in >> the design of distributed systems. I regard many of the >> interpretations and applications of end-to-end notions to network >> management and regulation as flawed, regardless of the intent of any >> of the authors of any particular paper decades ago, or even to their > Richard, I am sure that the Internet designers (who wrote running > code before they wrote papers) will be greatly > relieved to know that you ascribe good intentions to them. My only > problem is that you think they were well intnetioned but wrong, while > I believe that they were well intentioned and right. Given the history > of the Internet, > this seems hard to deny. >> subsequent refinement by the original authors or others. >> >> One the problems that arises in distributed systems is access to >> shared resources, and the end-to-end solution > > Yes, and those shared resources are queues (or equivalently, lines) >> to this problem is deeply flawed. > This seems to be proof by assertion. >> In order to share resources according to a policy, there needs to be >> a system element enforcing the policy. > > Well, no. There are papers showing that is not strictly true.. >> In network operations, this function is indispensable and must be >> part of the network infrastructure. There are many reasons for this, >> of course, but the chief ones are a) the lack of > > The Internet demonstrates that your assertion "must be part of the > network infrastructure" is incorrect. >> reliability and trust in end systems; and b) the lack of information >> about system demand on the part of the end > > The fate sharing concept shows that the reliability and trust in end > systems is irrelevant. >> system, which in principle only knows that it wants and not what >> anyone else wants to do on the shared resource. >> >> The idea that access to shared resources is best accomplished by >> uncoordinated end systems leads to a lot of grief. >> > > "Greif" is one of those loaded words that is inappropriate to this > discussion, but in any case "uncoordinated end systems" also leads to > a lot of advantages, like application-neutrality of the network. Have > you Skyped lately? A lot of people will be surprised when you tell > them it is fatally flawed. >> What does this have to do with Jacobson's Algorithm? A lot, it turns >> out, as we see in the rise of systems that take the job of congestion >> mediation a couple of steps further, such as ECN and Re-ECN. If you >> recognize that information about the state of shared resources is >> essential to their rational management, no problem. >> > "Rational" -- another of those Words. It clearly is not essential (we > got along pretty well with simple VJCC and cumulative ACKs, but > certainly SACK, RED, and ECN all extend the range of efficient > performance. > But yes, I agree with you, it helps a lot if the end systems have some > knowledge of conditions along the path. >> Of course, all of this is simply to say that optimal solutions to >> problems of resource management can only be made close to the >> resource in question, but it doesn't address a later version of the >> end-to-end arguments principle, that sub-optimal solutions (from an >> efficiency of fair-sharing perspective) to such problems may be >> preferred if they lead to greater system generality, opportunities >> for innovation, free speech, reliability, or some other reason. >> >> I hear this sort of argument being made very frequently these days, >> and it does have some resonance. Efficiency is after all a short-term >> goal, while generality is a long-term goal and innovation is a >> positive externality. But to appreciate that, one needs to think a >> bit abstractly. > > So we are having an agreement, except for your implication that the > Internet designers did not think abstractly but you do. I can assure > you that they did think abstractly, and around 1980 came to exactly > the conclusions of your last paragraph. > > Now can we find some new Dead Horse to beat? Or even add some new > insights? > > Bob Braden > >> >> RB >> >>> >> > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From braden at ISI.EDU Thu Nov 12 19:15:59 2009 From: braden at ISI.EDU (Bob Braden) Date: Thu, 12 Nov 2009 19:15:59 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFCC83F.3010406@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> Message-ID: <4AFCCF6F.1010808@isi.edu> Richard Bennett wrote: > I'm not persuaded that the best engineering solution always wins the > prize, Bob: VHS vs. Beta for example. I think there's a lot of > evidence to suggest that non-engineering factors have had a lot to do > with the hegemony of TCP/IP. Absolutely no question about that.There were half a dozen places along they way from 1978 when political/commercial forces could have limited or killed the Internet. (And it could still happen) OTOH, the robustness of TCP in the world illustrates the power of (sophisticated) simplicity in design, and the power of decentralization. > > It's difficult to respond in detail to the following as much of it is > mid-sentence complaints about thing that happen to be answered in the > next phrase or so, I am sorry, that just is not true (that the next sentence answered the comment). > but I will say I don't imply that the designers of internetworks > didn't think abstractly; Pouzin certainly did and still does.But I am > saying the argument that a particular sub-optimal design is best for a > production network By picking out Pouzin (as an example (he deserves it, of course) you are subtly implying that Dave Clark, for example, does NOT think abstractly? > because it happens to avoid fate-sharing or support innovation seems a > bit like grasping at straws. Huh?? > > > Secure, reliable, and efficient networks support innovation best. Not if they obtain security, reliability, and efficiency through centralized control and application-dependent networking.. Bob Braden > > RB > From richard at bennett.com Thu Nov 12 20:10:10 2009 From: richard at bennett.com (Richard Bennett) Date: Thu, 12 Nov 2009 20:10:10 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFCCF6F.1010808@isi.edu> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> Message-ID: <4AFCDC22.4050309@bennett.com> Weren't the designers of the Internet Kleinrock, Roberts, Kahn, and Cerf? I heard that on the Internet today. Dave Clark is a fine gentleman, but it was my impression that the design work was mainly done in the mid-70s. You make an interesting claim in this and one of the preceding msgs, to wit that the Internet is "application-neutral." Does anybody really believe that? RB Bob Braden wrote: > Richard Bennett wrote: >> I'm not persuaded that the best engineering solution always wins the >> prize, Bob: VHS vs. Beta for example. I think there's a lot of >> evidence to suggest that non-engineering factors have had a lot to do >> with the hegemony of TCP/IP. > > Absolutely no question about that.There were half a dozen places along > they way from 1978 when political/commercial forces could have limited > or killed the Internet. (And it could still happen) OTOH, the > robustness of TCP in the world illustrates the power of > (sophisticated) simplicity in design, and the power of decentralization. >> >> It's difficult to respond in detail to the following as much of it is >> mid-sentence complaints about thing that happen to be answered in the >> next phrase or so, > > I am sorry, that just is not true (that the next sentence answered > the comment). >> but I will say I don't imply that the designers of internetworks >> didn't think abstractly; Pouzin certainly did and still does.But I am >> saying the argument that a particular sub-optimal design is best for >> a production network > > By picking out Pouzin (as an example (he deserves it, of course) you > are subtly implying that Dave Clark, for example, does NOT think > abstractly? >> because it happens to avoid fate-sharing or support innovation seems >> a bit like grasping at straws. > > Huh?? >> >> >> Secure, reliable, and efficient networks support innovation best. > > Not if they obtain security, reliability, and efficiency through > centralized control and application-dependent networking.. > > Bob Braden >> >> RB >> > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From Jon.Crowcroft at cl.cam.ac.uk Fri Nov 13 02:34:51 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 13 Nov 2009 10:34:51 +0000 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFCDC22.4050309@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> Message-ID: given there's 4.3billion wireless cellular devices in the world and growing, i can't believe people are still baning on about switched networks taking over from shared media - the fact is that the edge AND the center are statistically multiplexed resources and the wished for simplicity of isolation and protection you get from some global switched system is flying in the face of all the trends. oh, sure, you find strict resource allocation in enterprise nets and "carrier grade" ethernet installations are fine and dandy in their niche environments, but its a niche. in fact, as we get more and more mimo and network coding, and other new ideas for content centric networking, which cross layer storage/cache and packet switching the system looks less and less like some sort of graph in the interconnect layer at all - in fact it looks less end2end at any layer at all can we start an entire new name&list for this new model whatever it is, coz this discussion isn't part of any future i recoznize, and is hauling over coals that have long gone cold. j. From detlef.bosau at web.de Fri Nov 13 06:42:25 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 13 Nov 2009 15:42:25 +0100 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFC95E3.3000505@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> Message-ID: <4AFD7051.8000705@web.de> Hi Richard, to be honest: I thought a bit about answering to this post. However, I well remember my first posts to this list some years ago and I well remember some posts of people, who where both, new to this list and new to distributed systems. So, people can learn from posts to this list, myself explicitly included. So, I think it to be worthwhile to add some comments. Richard Bennett wrote: > Detlef, I'm asking you to think abstractly about certain problems in > the design of distributed systems. I regard many of That's exactly what I'm doing. I simply does not matter whether a packed is conveyed via a shared Ethernet or via a switched Ethernet. From an abstract point of view, the packet is conveyed from a sender to a receiver. And this process takes some time and the "server", i.e. the conveying network, may process quite some packets in parallel. (I recently talked about TCP multipath issues to some colleagues, and I got the insight, perhaps many others got this long ago, that it simply does not matter, whether one packet is conveyed via a Cheapernet segment while a second one is conveyed via a fibre link and a third one via WiFi. There are three packets on the fly. Now: The endpoints are not interested in the details of transport here - and in addition: there's no need for them to give it even a thought! (O.k., you will object that the service times on different media may be different. Granted. Leave it out for the moment.) Do you see, what I'm doing here? I make an _abstraction_. I regard the net as some kind of transportation pipeline with some average (or expected) service time and a certain capacity. And from this point of view, I well may ignore the details. > the interpretations and applications of end-to-end notions to network > management and regulation as flawed, O.k., you're welcome to mention some concrete examples. But of course, when I mention a concrete flaw, I must not only say: "This is wrong, and I'm old enough and big enough and ugly enough to be correct here!" but I have to give a compelling reason, why something is wrong. > regardless of the intent of any of the authors of any particular paper > decades ago, or even to their subsequent refinement by the original > authors or others. In fact, I'm not interested in the intention but in the results. > > One the problems that arises in distributed systems is access to > shared resources, and the end-to-end solution to this problem is > deeply flawed. Why and where? > In order to share resources according to a policy, there needs to be a > system element enforcing the policy. Exactly. (Certainly, you know Keshav's PhD dissertation.) However, and I'm convinced Keshav will agree here: There are systems _without_ such a system. And there are systems, where the amount of resources is unknown. Think not only of any kinds of ad hoc systems and spontaneous collaboration. Think of an arbitrary "Linux installation party" - where some PC are interconnected via a coax-"backbone". Do you measure the coax backbone's length in advance to calculate its storage capacity for packets? Certainly not. You simply use the system, and - surprise! - it works! > In network operations, this function is indispensable and must be part > of the network infrastructure. There are many I've just given you and example, where this indispensable function can well be spared. > reasons for this, of course, but the chief ones are a) the lack of > reliability and trust in end systems; The less components a system will need, the more reliable a system will be. (This basic insight is often referet to / abbreviated as KISS. Keep It Small and Simple.) > and b) the lack of information about system demand on the part of the > end system, which in principle only knows that it wants and not what > anyone else wants to do on the shared resource. > And particularly, an Ethernet switch in between has no knowledge about the end system's needs. > The idea that access to shared resources is best accomplished by > uncoordinated end systems leads to a lot of grief. > One part of the grief is that you can read my answer ;-) > What does this have to do with Jacobson's Algorithm? A lot, it turns > out, as we see in the rise of systems that take the job of congestion > mediation a couple of steps further, such as ECN and Re-ECN. Which rise of system are you talking about? I definitely see a rise of papers which propose design rules for ECN, showing that we did not find compelling ones throughout the last decade. However, without VJCC, this seminal discussion of ECN would not even be possible. > If you recognize that information about the state of shared resources > is essential to their rational management, no problem. > I well recognize this. However, I recognize as well, that VJCC does its job. And the algorithm is shamelessly simple. > Of course, all of this is simply to say that optimal solutions to > problems of resource management can only be made close to the resource > in question, Which is known from the works by Srinivasan Keshav and Frank Kelly and many others. However, it's a simple fact in practical engineering, that we do not obtain optimal solutions for all problems, particularly the aforementioned works run into some difficulties when applied to wireless systems, but we obtain _practical_ solutions, we can well live with which. Actually, we are that comfortable with these practical solutions, that the only purpose of some of the optimal ones is to protect the bald heads of PhD students from the cold by providing them warming hats. And, of course, these practical solutions provide you with a punch-ball as well ;-) > but it doesn't address a later version of the end-to-end arguments > principle, that sub-optimal solutions (from an efficiency of > fair-sharing perspective) to such problems may be preferred if they > lead to greater system generality, Wow! You're willing to accept sub-optimal solutions when they lead to greater system generality! Welcome to the club! I think, about all of us do. > opportunities for innovation, free speech, reliability, or some other > reason. > > I hear this sort of argument being made very frequently these days, > and it does have some resonance. Efficiency is At least, it shows some effect eventually... > after all a short-term goal, while generality is a long-term goal and > innovation is a positive externality. But to appreciate that, one > needs to think a bit abstractly. > ...which may mean that we should rather not bother with irrelevant problems of minor importance. (@Joe: Hopefully, I was not too misbehaved here, but I really could not resist...) Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Fri Nov 13 06:52:04 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 13 Nov 2009 15:52:04 +0100 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFCDC22.4050309@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> Message-ID: <4AFD7294.9010501@web.de> Richard Bennett wrote: > Weren't the designers of the Internet Kleinrock, Roberts, Kahn, and > Cerf? I heard that on the Internet today. Dave And this shall give evidence that Dave Clark could not think abstractly? (Just to return to the context.) Sorry, but instead of arguing like a patent attorney, we should appreciate each researchers contribution as it deserves. -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From richard at bennett.com Fri Nov 13 13:13:12 2009 From: richard at bennett.com (Richard Bennett) Date: Fri, 13 Nov 2009 13:13:12 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFD7294.9010501@web.de> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> <4AFD7294.9010501@web.de> Message-ID: <4AFDCBE8.9040404@bennett.com> It's rather interesting that while Bob Braden insists that the Internet is an "application neutral network" David Clark famously derides such views as "happy little bunny rabbit dreams" and works to make it better able to support diverse applications. Who's right? RB Detlef Bosau wrote: > Richard Bennett wrote: >> Weren't the designers of the Internet Kleinrock, Roberts, Kahn, and >> Cerf? I heard that on the Internet today. Dave > > And this shall give evidence that Dave Clark could not think abstractly? > > (Just to return to the context.) > > Sorry, but instead of arguing like a patent attorney, we should > appreciate each researchers contribution as it deserves. > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From richard at bennett.com Fri Nov 13 13:16:01 2009 From: richard at bennett.com (Richard Bennett) Date: Fri, 13 Nov 2009 13:16:01 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> Message-ID: <4AFDCC91.9080400@bennett.com> Are you claiming the cell network is an edge-managed system? I don't think so. RB Jon Crowcroft wrote: > given there's 4.3billion wireless cellular devices in the world > and growing, i can't believe people are still baning on about > switched networks taking over from shared media - the fact is that > the edge AND the center are statistically multiplexed resources > and the wished for simplicity of isolation and protection you get from > some global switched system is flying in the face of all the trends. > oh, sure, you find strict resource allocation in enterprise nets > and "carrier grade" ethernet installations are fine and dandy in their > niche environments, but its a niche. > > in fact, as we get more and more mimo and network coding, > and other new ideas for content centric networking, > which cross layer storage/cache and packet switching > the system looks less and less like some sort of > graph in the interconnect layer at all - > > in fact it looks less end2end at any layer at all > > can we start an entire new name&list for this new model > whatever it is, coz this discussion isn't part of any future > i recoznize, and is hauling over coals that have > long gone cold. > > j. > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From detlef.bosau at web.de Fri Nov 13 13:41:44 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 13 Nov 2009 22:41:44 +0100 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFDCBE8.9040404@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> <4AFD7294.9010501@web.de> <4AFDCBE8.9040404@bennett.com> Message-ID: <4AFDD298.8050101@web.de> Richard Bennett wrote: > It's rather interesting that while Bob Braden insists that the > Internet is an "application neutral network" David Clark famously > derides such views as "happy little bunny rabbit dreams" and works to > make it better able to support diverse applications. > > Who's right? > Perhaps both of them. Some time ago, someone wrote here in the list: Science is about asking questions and answering them. Perhaps, science can even be about proposing views - and evaluating them. Do we always need a clear "right" and "wrong"? I've seen Ethernet installations which clearly distinguish different VLANs with different properties, e.g. one "best effort" network for client server applications and QoS properties for VoIP. I don't have a problem with this. I don't even have a problem with using VJCC for the one network and circuit switching like MPLS for the other. It is sometimes a bit confusing that we have end to end applications and centrally managed ones on the same infrastructure. We only should avoid to think in to strict right vs. wrong, black vs. white. (It took me some years to accept a coexistence of different paradigms like these on wireless networks. And, btw., wireless networks are a wonderful example for the coexistence of real time and best effort applications, end to end applications and ones with centrally managed switching. Networks are flexible enough. We just should learn to be flexible as well.) -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jnc at mercury.lcs.mit.edu Fri Nov 13 13:50:36 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Fri, 13 Nov 2009 16:50:36 -0500 (EST) Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument Message-ID: <20091113215036.826FA6BE681@mercury.lcs.mit.edu> > From: Richard Bennett > It's rather interesting that while Bob Braden insists that the Internet > is an "application neutral network" David Clark famously derides such > views as "happy little bunny rabbit dreams" and works to make it better > able to support diverse applications. Without taking the time to delve into exactly the cimcumstance of each statement (since it's not that important), I suspect that Bob was talking of 'the network as first designed and deployed, where new stuff was easy to roll out', and Dave was talking of 'the network we actually have today, with routers filtering on protocol/port for security, commercial reasons, etc, etc'. Noel From richard at bennett.com Fri Nov 13 14:09:44 2009 From: richard at bennett.com (Richard Bennett) Date: Fri, 13 Nov 2009 14:09:44 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <20091113215036.826FA6BE681@mercury.lcs.mit.edu> References: <20091113215036.826FA6BE681@mercury.lcs.mit.edu> Message-ID: <4AFDD928.9000302@bennett.com> I think that would be an incorrect interpretation, Noel. Clark says the Internet is not neutral *and never has been* because the edge-managed, best-efforts paradigm supports content-oriented applications better than communications-oriented, real-time applications; or that's my understanding, at least. The question that I find interesting is whether the Internet is on its way toward becoming a legacy network for content distribution in a triple-play world where more compelling communications-oriented applications will share the same infrastructure but use fundamentally different protocols, as Detlef indicated in his message about VLANs and such. It appears to me that the legacy direction seems most likely at the moment. This doesn't have to be the case, however, and it would be more interesting to me for the Internet protocols to grow the capability to support VoIP, gaming, and real-time video streaming capabilities that would eliminate the need for network fragmentation via VLANs or some similar means. The doctrinaire insistence that the Internet must always work the way it has in the past is a recipe for obsolescence, in other words. RB Noel Chiappa wrote: > > From: Richard Bennett > > > It's rather interesting that while Bob Braden insists that the Internet > > is an "application neutral network" David Clark famously derides such > > views as "happy little bunny rabbit dreams" and works to make it better > > able to support diverse applications. > > Without taking the time to delve into exactly the cimcumstance of each > statement (since it's not that important), I suspect that Bob was talking of > 'the network as first designed and deployed, where new stuff was easy to roll > out', and Dave was talking of 'the network we actually have today, with > routers filtering on protocol/port for security, commercial reasons, etc, > etc'. > > Noel > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From Jon.Crowcroft at cl.cam.ac.uk Sat Nov 14 02:21:07 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 14 Nov 2009 10:21:07 +0000 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFDCC91.9080400@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> <4AFDCC91.9080400@bennett.com> Message-ID: In missive <4AFDCC91.9080400 at bennett.com>, Richard Bennett typed: >>Are you claiming the cell network is an edge-managed system? I don't >>think so. given the overload on 3G backhauls being experienced by many with the onslaught of handset devices whose capabilities are no longer dictated to by cellular providers, that is exactly what I am claiming, evidentially and technically plus the only way they are going to cope with deploying enough capacity to cope with demand is to build cooperative wireless edge networks - you can't get enough classic model cell towers out there (ignore femtocell hype - whatever you do you want path diversity and that needs a non hierarchical approach... if you think i was referring to the _old_ cellular voice system then you have misinterpreted what i am banging on about c'est la vie >> >>Jon Crowcroft wrote: >>> given there's 4.3billion wireless cellular devices in the world >>> and growing, i can't believe people are still baning on about >>> switched networks taking over from shared media - the fact is that >>> the edge AND the center are statistically multiplexed resources >>> and the wished for simplicity of isolation and protection you get from >>> some global switched system is flying in the face of all the trends. >>> oh, sure, you find strict resource allocation in enterprise nets >>> and "carrier grade" ethernet installations are fine and dandy in their >>> niche environments, but its a niche. >>> >>> in fact, as we get more and more mimo and network coding, >>> and other new ideas for content centric networking, >>> which cross layer storage/cache and packet switching >>> the system looks less and less like some sort of >>> graph in the interconnect layer at all - >>> >>> in fact it looks less end2end at any layer at all >>> >>> can we start an entire new name&list for this new model >>> whatever it is, coz this discussion isn't part of any future >>> i recoznize, and is hauling over coals that have >>> long gone cold. >>> >>> j. >>> >> >>-- >>Richard Bennett >>Research Fellow >>Information Technology and Innovation Foundation >>Washington, DC >> cheers jon From detlef.bosau at web.de Sat Nov 14 05:16:39 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 14 Nov 2009 14:16:39 +0100 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFDCC91.9080400@bennett.com> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> <4AFDCC91.9080400@bennett.com> Message-ID: <4AFEADB7.7070301@web.de> Let me again state my point of view as written yesterday in <4AFDD298.8050101 at web.de> Richard Bennett wrote: > Are you claiming the cell network is an edge-managed system? I don't > think so. > A cell network integrates both kinds of networks, edge managed ones and centrally managed ones as well. The thrill is the coexistence of these. Particularly, as the separation (and vice versa the convergence) of both starts at extremely low layers, i.e. the physical layer when data and speech may use different, if compatible, line coding schemes. For quite some years I suffered from the paradigm that IP would be "the" convergence layer and both, data and speech as well, should be conveyed packet switched via IP datagrams. Eventually, this questionable approach is about to be overcome even in the CS community. Particularly, as the "there's no switching like packet switching" attitude of some CS guys ad the "there's no switching like line switching" attitude of some EE guys caused lots of misconceptions and even some severe waste of money spent for nonsense research projects. Perhaps, we should bring these useless arguments to an end and simply accept, that both concepts exist, both concepts are useful. They don't compete each other, they complete each other. We all should remember Hammings insight: ?Mathematicians /stand on each other's/ shoulders while computer scientists /stand on each other's toes/.? -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From richard at bennett.com Sat Nov 14 10:19:00 2009 From: richard at bennett.com (Richard Bennett) Date: Sat, 14 Nov 2009 10:19:00 -0800 Subject: [e2e] Switched Ethernet is Not an End-to-End System; was Protocols breaking the end-to-end argument In-Reply-To: <4AFEADB7.7070301@web.de> References: <30424.1256839558@lunacy.ugrad.cs.cmu.edu> <4AECB04F.8020802@bennett.com> <4AFB0C76.9000004@web.de> <4AFB51FA.9070609@bennett.com> <4AFC34BA.8090807@web.de> <4AFC95E3.3000505@bennett.com> <4AFCAC9F.3060808@isi.edu> <4AFCC83F.3010406@bennett.com> <4AFCCF6F.1010808@isi.edu> <4AFCDC22.4050309@bennett.com> <4AFDCC91.9080400@bennett.com> <4AFEADB7.7070301@web.de> Message-ID: <4AFEF494.5090507@bennett.com> Maybe ISO had it right after all. Detlef Bosau wrote: > Let me again state my point of view as written yesterday in > > <4AFDD298.8050101 at web.de> > > > Richard Bennett wrote: >> Are you claiming the cell network is an edge-managed system? I don't >> think so. >> > > A cell network integrates both kinds of networks, edge managed ones > and centrally managed ones as well. > > The thrill is the coexistence of these. > > Particularly, as the separation (and vice versa the convergence) of > both starts at extremely low layers, i.e. the physical layer when data > and speech may use different, if compatible, line coding schemes. > > For quite some years I suffered from the paradigm that IP would be > "the" convergence layer and both, data and speech as well, should be > conveyed packet switched via IP datagrams. > > Eventually, this questionable approach is about to be overcome even in > the CS community. > > Particularly, as the "there's no switching like packet switching" > attitude of some CS guys ad the "there's no switching like line > switching" attitude of some EE guys caused lots of misconceptions and > even some severe waste of money spent for nonsense research projects. > > Perhaps, we should bring these useless arguments to an end and simply > accept, that both concepts exist, both concepts are useful. They don't > compete each other, they complete each other. > > We all should remember Hammings insight: ?Mathematicians /stand on > each other's/ shoulders while computer scientists /stand on each > other's toes/.? > > > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From detlef.bosau at web.de Sun Nov 22 11:04:45 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 22 Nov 2009 20:04:45 +0100 Subject: [e2e] Some questions about TCP. Message-ID: <4B098B4D.2060806@web.de> Hi to all. The following questions may be stupid - however, the most stupid questions are the never asked ones ;-) 1.: Recently, I was told, however I did not find a reference in some RFC, we had two distinct packet types in TCP: - those _with_ payload, which are _data_ _segments_, - those _without_ payload, which are _acknowledgements_. If this is correct, I would appreciate some reference. 2.: RFC 2581 states, tat in slow start state CWND is incremented by _new_ acknowledgements, not by duplicate acks. The same holds true in congestion avoidance state. Question: Why is CWND is not incremented for dupacks? When I think about it, I can find arguments for both ways. So, I would like to here the rationale for the "standard version". 3. I do not quite understand the fast retransmit procedure in RFC 2581. RFC 2581 says: The fast retransmit and fast recovery algorithms are usually implemented together as follows. 1. When the third duplicate ACK is received, set ssthresh to no more than the value given in equation 3. 2. Retransmit the lost segment and set cwnd to ssthresh plus 3*SMSS. This artificially "inflates" the congestion window by the number of segments (three) that have left the network and which the receiver has buffered. 3. For each additional duplicate ACK received, increment cwnd by SMSS. This artificially inflates the congestion window in order to reflect the additional segment that has left the network. 4. Transmit a segment, if allowed by the new value of cwnd and the receiver's advertised window. 5. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This is termed "deflating" the window. This ACK should be the acknowledgment elicited by the retransmission from step 1, one RTT after the retransmission (though it may arrive sooner in the presence of significant out- of-order delivery of data segments at the receiver). Additionally, this ACK should acknowledge all the intermediate segments sent between the lost segment and the receipt of the third duplicate ACK, if none of these were lost. Note: This algorithm is known to generally not recover very efficiently from multiple losses in a single flight of packets [FF96]. One proposed set of modifications to address this problem can be found in [FH98]. To my understanding, the fast retransmit retransmits the "one" lost segment indicated by last ack and does _not_ a go back n. Hence, we should introduce a step "0": 0. When the third dup ack is received, inflate CWND to CWND + 3. 1. Set ssthresh = .... The rest remains the same. Could somebody please help me here? Thanks! Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jnc at mercury.lcs.mit.edu Sun Nov 22 13:05:46 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 22 Nov 2009 16:05:46 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> > From: Detlef Bosau > 1.: Recently, I was told, however I did not find a reference in some > RFC, we had two distinct packet types in TCP: > - those _with_ payload, which are _data_ _segments_, > - those _without_ payload, which are _acknowledgements_. > If this is correct, I would appreciate some reference. No, not really. All TCP packets contain both i) an ack field (for acking data bytes sent from the other end), and ii) provisions for carriage of data. (Well, putting data in with a SYN is allowed, but is a bit odd.) Iff there is bi-directional data flow, a packet with data in it (going in one direction) can _also_ ack bytes received from the other side. An ack packet is just a normal TCP data packet with 0 bytes of data in it. You sometimes see the term 'ack packet' used to describe such packets. Noel From detlef.bosau at web.de Sun Nov 22 13:24:57 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 22 Nov 2009 22:24:57 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> References: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> Message-ID: <4B09AC29.5010800@web.de> Noel Chiappa wrote: > > From: Detlef Bosau > > > 1.: Recently, I was told, however I did not find a reference in some > > RFC, we had two distinct packet types in TCP: > > - those _with_ payload, which are _data_ _segments_, > > - those _without_ payload, which are _acknowledgements_. > > If this is correct, I would appreciate some reference. > > No, not really. Argh! :-[ > All TCP packets contain both i) an ack field (for acking > Correct. So, basically I would expect acks to flow "piggypack" on the data packets. The problem occurs when you clock out several segments from a TCP peer. In that case, several segments / TCP packets will contain the same ack number. Now, the RFC states explicitly that a segment _MUST_ _NOT_ be acknowled more than once. So, how do we avoid incoming packets to be mistaken for dup acks? So, I asked a number of people and was told the above.... > data bytes sent from the other end), and ii) provisions for carriage of > data. (Well, putting data in with a SYN is allowed, but is a bit odd.) > > Iff there is bi-directional data flow, a packet with data in it (going in > one direction) can _also_ ack bytes received from the other side. An ack > O.k.. One thought of mine was that the ACK flag will indicate a significant ack number. However, RFC 793 states that in "established" state, a packet's ACK flag is always set. So, there's some confusion.... Meanwhile, I looked into some real TCP connections using wireshark - and found the aforementioned statement confirmed... > packet is just a normal TCP data packet with 0 bytes of data in it. You > sometimes see the term 'ack packet' used to describe such packets. > Hm.... So, my confusion retains.... Detlef > Noel > -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jnc at mercury.lcs.mit.edu Sun Nov 22 14:47:42 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 22 Nov 2009 17:47:42 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091122224742.B1EB26BE56D@mercury.lcs.mit.edu> > From: Detlef Bosau > The problem occurs when you clock out several segments from a TCP peer. > In that case, several segments / TCP packets will contain the same ack > number. Yes... I see no problem here? > Now, the RFC states explicitly that a segment _MUST_ _NOT_ be acknowled > more than once. So, how do we avoid incoming packets to be mistaken for > dup acks? I'm not sure what you're referring to here? Where did you see that 'segment must not be acked more than once' thing? I looked in RFC-793 and found only three instances of "must not", none of them about ACKs. Maybe it means 'you shouldn't send more than one ACK-only packet in response to a single data packet', or something like that? If a TCP connection is unidirectional, then the outgoing data packets must, if they carry an ACK at all, have the same ACK value. It's true that since there is an ACK bit, one could emit packets with that bit off, but I think most TCPs leave it on pretty much all the time. (I can't be bothered to go dig out the hardcopy listings of the TCP I did, to see if I did, but I think I did.) > However, RFC 793 states that in "established" state, a packet's ACK > flag is always set. Yes, that matches my memory. Noel From detlef.bosau at web.de Sun Nov 22 15:04:14 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 23 Nov 2009 00:04:14 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <20091122224742.B1EB26BE56D@mercury.lcs.mit.edu> References: <20091122224742.B1EB26BE56D@mercury.lcs.mit.edu> Message-ID: <4B09C36E.8020202@web.de> Noel Chiappa wrote: > > From: Detlef Bosau > > > The problem occurs when you clock out several segments from a TCP peer. > > In that case, several segments / TCP packets will contain the same ack > > number. > > Yes... I see no problem here? > Surely the problem is between keyboard and chair hiere.... However: How can I prevent to mistake several segments with the same ack number as duplicate acknowledgements? > > Now, the RFC states explicitly that a segment _MUST_ _NOT_ be acknowled > > more than once. So, how do we avoid incoming packets to be mistaken for > > dup acks? > > I'm not sure what you're referring to here? Where did you see that 'segment > must not be acked more than once' thing? I looked in RFC-793 and found only > three instances of "must not", none of them about ACKs. > > RFC 2581 Section 4.2 A TCP receiver MUST NOT generate more than one ACK for every incoming segment, other than to update the offered window as the receiving application consumes new data [page 42, Pos81][Cla82]. So, when a node sends several segments without receiving new ones, it will repeat the same ack number several times. > Maybe it means 'you shouldn't send more than one ACK-only packet in response > to a single data packet', or something like that? > > It's actually MUST NOT (capitals in the RFC) in RFC 2581 ;-) > If a TCP connection is unidirectional, then the outgoing data packets must, > if they carry an ACK at all, have the same ACK value. It's true that since > there is an ACK bit, one could emit packets with that bit off, but I think > most TCPs leave it on pretty much all the time. RFC 793 explicitly says so. However, my problem is: When it is possible for a sender, to have the same packet acknowledged by several packets from the peer, not to mistake these for e.g. da Triple Duplicate Acknowledgement, which will cause the sender to go into fast retransmission and fast recovery? Perhaps, I don't see the clue here for some reason... Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jnc at mercury.lcs.mit.edu Sun Nov 22 15:56:20 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sun, 22 Nov 2009 18:56:20 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091122235620.36A3E6BE560@mercury.lcs.mit.edu> > From: Detlef Bosau > How can I prevent to mistake several segments with the same ack number > as duplicate acknowledgements? If they contain no data, by definition they _are_ duplicate acknowledgements. That is not necessarily a problem, though. > RFC 2581 Section 4.2 > > A TCP receiver MUST NOT generate more than one ACK for every incoming > segment, other than to update the offered window as the receiving > application consumes new data [page 42, Pos81][Cla82]. That is poorly phrased. It should say 'more than one ACK-only packet', or something like that. > So, when a node sends several segments without receiving new ones, it > will repeat the same ack number several times. Yes, that is OK. Just as long as one does not send multiple ACK-only packets in response to a single data-containing packet. > my problem is: When it is possible for a sender, to have the same > packet acknowledged by several packets from the peer, not to mistake > these for e.g. da Triple Duplicate Acknowledgement, which will cause > the sender to go into fast retransmission and fast recovery? I'm not an expert in this area of TCP, but I think you have to look at the larger situation - i.e. look to see what exactly you have outstanding, etc. E.g. if you send segments A, A+100, A+200, and A+300, and you get back ACK-only packets for A, A, A then you can be fairly sure that A+100 has been lost, and you need to re-send it. That is because you know that the A packet got there (it was ack'd), as well as two packets _after_ the A (since the TCP on the other end _could not_ have sent those acks _unless it saw packets_ - at least if it's following the spec :-), but the A+100 was not seen (or it would have been acked). But depending on exactly what it going on, there may be no absolute certainty. E.g. if the other side _is_ sending data in those packets (or changing the window), then perhaps the A+100 packet, and the following packets, just hadn't gotten there yet. Adding timers allows you to make even better estimations of what it going on. But, like I said, this is not my area of expertise, so perhaps someone else can help. Noel From detlef.bosau at web.de Mon Nov 23 00:18:05 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 23 Nov 2009 09:18:05 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <20091122235620.36A3E6BE560@mercury.lcs.mit.edu> References: <20091122235620.36A3E6BE560@mercury.lcs.mit.edu> Message-ID: <4B0A453D.4000607@web.de> Noel Chiappa wrote: > > From: Detlef Bosau > > > How can I prevent to mistake several segments with the same ack number > > as duplicate acknowledgements? > > If they contain no data, by definition they _are_ duplicate acknowledgements. > That is not necessarily a problem, though. > ;-) > > > RFC 2581 Section 4.2 > > > > A TCP receiver MUST NOT generate more than one ACK for every incoming > > segment, other than to update the offered window as the receiving > > application consumes new data [page 42, Pos81][Cla82]. > > That is poorly phrased. It should say 'more than one ACK-only packet', or > something like that. > However, this does not solve my problem. In a bidirectional flow, it is well possible that one segment sent from a to be can see several acknowledgements in packets from b to a. Imagine a simple asymmetric connection with 2 MBit/s throughput in the one direction and 500 kBit/s in the other. The question is: How can a sender determine whether he sees a "normal" number of acknowledgements for a packet or "more then DUPACKTHRESH", hence the sender has to retransmit the packet and must do recovery actions? > > So, when a node sends several segments without receiving new ones, it > > will repeat the same ack number several times. > > Yes, that is OK. Just as long as one does not send multiple ACK-only packets > in response to a single data-containing packet. > Hm. I don't get the clue...... ;-) > > > my problem is: When it is possible for a sender, to have the same > > packet acknowledged by several packets from the peer, not to mistake > > these for e.g. da Triple Duplicate Acknowledgement, which will cause > > the sender to go into fast retransmission and fast recovery? > > I'm not an expert in this area of TCP, but I think you have to look at the > larger situation - i.e. look to see what exactly you have outstanding, etc. > The problem is quite simple. I'm working at a very simple tiny simulator at the moment - and anything was fine and worked as the RFC told - as long as I did not send any data full duplex. As soon as both parties started to send, the party was over and both peers throttled their windows down to a single segment due to duplicate acknowledgements. And now, I'm simply looking for the correct way to handle this situation..... > E.g. if you send segments A, A+100, A+200, and A+300, and you get back > ACK-only packets for A, A, A then you can be fairly sure that A+100 has been > lost, and you need to re-send it. O.k., and when I see 10 or 15 data carrying segments which acknowledge A? You will observe this with an arbitrary ADSL line! Detlef -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Mon Nov 23 01:23:48 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Mon, 23 Nov 2009 09:23:48 +0000 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B0A453D.4000607@web.de> References: <20091122235620.36A3E6BE560@mercury.lcs.mit.edu> <4B0A453D.4000607@web.de> Message-ID: I suggest you read thru W Richard Stevens TCP/IP Illustrated, esp. vol 2 where he goes thru the code... basically, while all TCP packets can carry data, there is a notion of a "pure ack" implicit in a packet that is triggered internally by TCP even when there isn't data which acks cumulatively received sequence number space (or (inclusive or) notifies the far end that there's more window space... you don't have to ack every packet, but if a packet is "new" (e.g. carries new data) then you probably should ack it soon ... if you see a new packet (i.e. it carries new data), but its sequence is not the _expected_ one (i.e. next chunk), then you might dupack the oldest one received so far... I think this is all beautifully explained by Stevens, so I will now await whhile you go and read it:) In missive <4B0A453D.4000607 at web.de>, Detlef Bosau typed: >>Noel Chiappa wrote: >>> > From: Detlef Bosau >>> >>> > How can I prevent to mistake several segments with the same ack n= >>umber >>> > as duplicate acknowledgements? >>> >>> If they contain no data, by definition they _are_ duplicate acknowledge= >>ments. >>> That is not necessarily a problem, though. >>> =20 >>;-) >> >> >>> >>> > RFC 2581 Section 4.2 >>> > >>> > A TCP receiver MUST NOT generate more than one ACK for every in= >>coming >>> > segment, other than to update the offered window as the receivi= >>ng >>> > application consumes new data [page 42, Pos81][Cla82]. >>> >>> That is poorly phrased. It should say 'more than one ACK-only packet', = >>or >>> something like that. >>> =20 >> >>However, this does not solve my problem. >> >>In a bidirectional flow, it is well possible that one segment sent from=20 >>a to be can see several acknowledgements in packets from b to a. Imagine=20 >>a simple asymmetric connection with 2 MBit/s throughput in the one=20 >>direction and 500 kBit/s in the other. >> >>The question is: How can a sender determine whether he sees a "normal"=20 >>number of acknowledgements for a packet or "more then DUPACKTHRESH",=20 >>hence the sender has to retransmit the packet and must do recovery action= >>s? >> >> >>> > So, when a node sends several segments without receiving new ones= >>, it >>> > will repeat the same ack number several times. >>> >>> Yes, that is OK. Just as long as one does not send multiple ACK-only pa= >>ckets >>> in response to a single data-containing packet. >>> =20 >> >>Hm. I don't get the clue...... ;-) >> >>> >>> > my problem is: When it is possible for a sender, to have the same >>> > packet acknowledged by several packets from the peer, not to mist= >>ake >>> > these for e.g. da Triple Duplicate Acknowledgement, which will ca= >>use >>> > the sender to go into fast retransmission and fast recovery? >>> >>> I'm not an expert in this area of TCP, but I think you have to look at = >>the >>> larger situation - i.e. look to see what exactly you have outstanding, = >>etc. >>> =20 >> >>The problem is quite simple. I'm working at a very simple tiny simulator=20 >>at the moment - and anything was fine and worked as the RFC told - as=20 >>long as I did not send any data full duplex. >> >>As soon as both parties started to send, the party was over and both=20 >>peers throttled their windows down to a single segment due to duplicate=20 >>acknowledgements. >> >>And now, I'm simply looking for the correct way to handle this=20 >>situation..... >> >>> E.g. if you send segments A, A+100, A+200, and A+300, and you get back >>> ACK-only packets for A, A, A then you can be fairly sure that A+100 has= >> been >>> lost, and you need to re-send it. >> >>O.k., and when I see 10 or 15 data carrying segments which acknowledge A? >> >>You will observe this with an arbitrary ADSL line! >> >>Detlef >> >>--=20 >>Detlef Bosau Galileistra=DFe 30 70565 Stuttgart >>phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau =20 >>ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.d= >>e =20 >> >> cheers jon From nishida at sfc.wide.ad.jp Mon Nov 23 01:51:33 2009 From: nishida at sfc.wide.ad.jp (Yoshifumi Nishida) Date: Mon, 23 Nov 2009 18:51:33 +0900 (JST) Subject: [e2e] Some questions about TCP. In-Reply-To: <4B09C36E.8020202@web.de> References: <20091122224742.B1EB26BE56D@mercury.lcs.mit.edu> <4B09C36E.8020202@web.de> Message-ID: <20091123.185133.172139801.nishida@sfc.wide.ad.jp> Hello, From: Detlef Bosau Subject: Re: [e2e] Some questions about TCP. Date: Mon, 23 Nov 2009 00:04:14 +0100 Message-ID: <4B09C36E.8020202 at web.de> > However, my problem is: When it is possible for a sender, to have the > same packet acknowledged by several packets from the peer, not to > mistake these for e.g. da Triple Duplicate Acknowledgement, which will > cause the sender to go into fast retransmission and fast recovery? A sender can know which packets are already transmitted, which are not. If the ack indicates that all transmitted packets are received, it is not a dupack which might be a sign for packet loss. -- Yoshifumi Nishida nishida at sfc.wide.ad.jp From jnc at mercury.lcs.mit.edu Mon Nov 23 07:32:35 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 23 Nov 2009 10:32:35 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091123153235.EFA5D6BE576@mercury.lcs.mit.edu> > From: Detlef Bosau >>> "A TCP receiver MUST NOT generate more than one ACK for every incoming >>> segment ..." >> That is poorly phrased. It should say 'more than one ACK-only packet' > However, this does not solve my problem. Well, it does clear up issue you had, where you thought it was incorrect for a TCP to issue more than one acknowledgement for a particular place in the stream... > In a bidirectional flow, it is well possible that one segment sent from > a to be can see several acknowledgements in packets from b to a. Yes, the indirect meaning (as far as indicating missing segments) of the acknowledgement fields in bidirectional flows is definitely less clear. > The question is: How can a sender determine whether he sees a "normal" > number of acknowledgements for a packet or "more then DUPACKTHRESH", > hence the sender has to retransmit the packet and must do recovery > actions? I do not have a definite answer to this (in the case above, where multiple data+ack packets are coming in from the other end). Perhaps one of the TCP experts here can help? >> Just as long as one does not send multiple ACK-only packets in >> response to a single data-containing packet. > Hm. I don't get the clue...... ;-) Sorry, I did not understand that? > I'm working at a very simple tiny simulator at the moment - and > anything was fine and worked as the RFC told - as long as I did not > send any data full duplex. I would not be surprised if some TCPs do not work well when there is simultaneous bidirectional traffic. This is because the rule about 'only send an ack-only packet in response to an incoming data packet' does not apply in that case (since one is sending packets which contain data _and_ an ACK, and hence are not covered by that rule). It is that rule which allows one to infer, when one sees multiple ACK-only packets in a row, that the other end _has_ seen multiple data packets arrive, BUT is _also_ missing the next one in sequence. And that signal (of a packet loss) is what drives a lot of other stuff (e.g. fast retransmit). When you see a packet with data _and_ an ACK, you cannot draw any such conclusions about what packets the other end has seen, from that packet alone, without any other information - all you know is that the other end _has_ seen packets up through that indicated in the ACK field. > As soon as both parties started to send, the party was over and both > peers throttled their windows down to a single segment due to duplicate > acknowledgements. It sounds like the code is treating _all_ packets with an acknowledgment as usable as an indication of packet loss (as above), when it it seem to me that it should _ignore_ packets with data in them for that purpose, because they are not covered by the 'only send when an incoming packet arrives' rule.. Do the TCP experts here agree with that supposition? > and when I see 10 or 15 data carrying segments which acknowledge A? Like I said, "you have to look at the larger situation ... Adding timers allows you to make even better estimations of what it going on". For instance, as an example, there is probably something you can do if you know the time at which A and succeeding segments are sent, and you have a good estimate of the RTT. For instance, if A was sent at T, A+100 at T+10, A+200 at T+20, etc, and the RTT is R, then if you get you first ACK for A at T+R+, and at T+R+100+<3*epsilon> (3 is picked out of the air - I don't know what the right value needs to be, perhaps it should be based on the RTT variation) you start to get a bunch of segments which contain data and an ACK for A, you can _guess_ that A+100 has been lost, and resend it. Noel From perfgeek at mac.com Mon Nov 23 07:47:25 2009 From: perfgeek at mac.com (rick jones) Date: Mon, 23 Nov 2009 07:47:25 -0800 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B09AC29.5010800@web.de> References: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> <4B09AC29.5010800@web.de> Message-ID: <2E27D7DF-398F-4097-A217-4A0952730FD4@mac.com> On Nov 22, 2009, at 1:24 PM, Detlef Bosau wrote: > Noel Chiappa wrote: >> > From: Detlef Bosau >> >> > 1.: Recently, I was told, however I did not find a reference >> in some >> > RFC, we had two distinct packet types in TCP: >> > - those _with_ payload, which are _data_ _segments_, >> > - those _without_ payload, which are _acknowledgements_. >> > If this is correct, I would appreciate some reference. >> >> No, not really. > > Argh! :-[ I always thought that without data one would call it a control segment, or perhaps overhead :) A SYN or FIN segment can also flow sans data, but they are not necessarily ACKs. >> All TCP packets contain both i) an ack field (for acking >> > > Correct. So, basically I would expect acks to flow "piggypack" on > the data packets. > > The problem occurs when you clock out several segments from a TCP > peer. In that case, several segments / TCP packets will contain the > same ack number. > > Now, the RFC states explicitly that a segment _MUST_ _NOT_ be > acknowled more than once. So, how do we avoid > incoming packets to be mistaken for dup acks? IIRC the duplicate ACK test includes the advertised window holding fixed. If the arriving segment updates the window, then it would not qualify for a duplicate ACK. I have some other recollection about the arriving segments being ack-only, but perhaps that is ancient recall and things were updated? rick jones there is no rest for the wicked, yet the virtuous have no pillows From dpreed at reed.com Sun Nov 22 13:45:57 2009 From: dpreed at reed.com (David P. Reed) Date: Sun, 22 Nov 2009 16:45:57 -0500 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B098B4D.2060806@web.de> References: <4B098B4D.2060806@web.de> Message-ID: <4B09B115.9020209@reed.com> On 11/22/2009 02:04 PM, Detlef Bosau wrote: > 1.: Recently, I was told, however I did not find a reference in some > RFC, we had two distinct packet types in TCP: > - those _with_ payload, which are _data_ _segments_, > - those _without_ payload, which are _acknowledgements_. > Not true. TCP was designed to piggyback acknowledgements with data. Acknowledgements are reflected only as increases in sequence numbers. One can think of the arrival of a packet with a sequence number larger than any previous sequence number as a "virtual" acknowledgement message. I am curious who told you that "fact". From jnc at mercury.lcs.mit.edu Mon Nov 23 08:56:18 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 23 Nov 2009 11:56:18 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091123165618.EAAF06BE591@mercury.lcs.mit.edu> > From: Jon Crowcroft > I suggest you read thru W Richard Stevens TCP/IP Illustrated, esp. vol > 2 where he goes thru the code... > ... > I think this is all beautifully explained by Stevens, so I will now > await whhile you go and read it:) So I'm too lazy to go find my copy of Stevens... do you happen to know if it talks about my supposition that duplicate acks in segments which _also_ contain data don't count as 'duplicate acks', for the purposes of the 'lost segment' signal? Noel From braden at ISI.EDU Mon Nov 23 09:53:26 2009 From: braden at ISI.EDU (Bob Braden) Date: Mon, 23 Nov 2009 09:53:26 -0800 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B098B4D.2060806@web.de> References: <4B098B4D.2060806@web.de> Message-ID: <4B0ACC16.20607@isi.edu> Detlef Bosau wrote: > Hi to all. > > The following questions may be stupid - however, the most stupid > questions are the never asked ones ;-) > > 1.: Recently, I was told, however I did not find a reference in some > RFC, we had two distinct packet types in TCP: > - those _with_ payload, which are _data_ _segments_, > - those _without_ payload, which are _acknowledgements_. Detlef, "Two distinct packet types" is a mistaken model. There is no such concept in TCP, which is a rather more subtle protocol. Every segment carries all the control bits, and TCP uses concurrent state machines, one operating in each direction. Recall that TCP allows simultaneous data transmission in both directions on the same connection. A segment without a payload was sometimes called an "empty ACK segment" or maybe simply an "ACK segment" when that was unambiguous. But this terminology is not part of the protocol. When Postel used the term "acknowledgment", he was referring to the effect of the ACK field of the packet, not to some distinct packet type. For convenience, Postel and his cohorts who developed the TCP spec used the phrase "XXX segment" to indicate "a segment whose effect is to carry information XXX" (but the segment may also carry other information). Thus, 793 refers to "RST segments" and "SYN segments" (and probably "FIN segments", tho I have not checked). As Noel (?) pointed out, after synchronization the ACK bit is always on, so EVERY TCP segment is effectively an acknowledgment segment. And indeed, a segment carrying data ("text" in 793) was often called a "data segment" in discourse, but that does not make it a term in the protocol. A useful reference for what Postel and cohorts thought the TCP spec is contained in RFC 1122, Section 4.2. RFC 1122 represents the combined efforts of some 50 IETF members. Bob Braden From dokaspar.ietf at gmail.com Mon Nov 23 10:00:12 2009 From: dokaspar.ietf at gmail.com (Dominik Kaspar) Date: Mon, 23 Nov 2009 19:00:12 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B09B115.9020209@reed.com> References: <4B098B4D.2060806@web.de> <4B09B115.9020209@reed.com> Message-ID: <2a3692de0911231000l79ad2fau4edd3abe24440a6e@mail.gmail.com> Hi Detlef, Maybe the answer to your questions is that a DupACK never contains a payload. At least that is what a colleague and I could find in the Linux source code. I doubt you will find a reference in RFCs. The only hint that the RFC 2581 gives me, is the word "immediate" in the sentence "A TCP receiver SHOULD send an immediate duplicate ACK when an out-of-order segment arrives". I assume that "immediate" implies somehow a quickly sent "bare" ACK and the absence of a payload... FLAG_NOT_DUPACK defines the conditions of when a segment is not a duplicate acknowledgment: http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_input.c#L105 This might also answer your question about what happens in a scenario with extreme difference in up- and downlink speeds (like ADSL). The numerous data packets that are traveling over the fast downlink may acknowledge the same data, which might appear to be DupACKs, but they all contain a payload, therefore, they are not treated as DupACKs. Not sure if that was of any help... Greetings, Dominik From faber at ISI.EDU Mon Nov 23 10:52:40 2009 From: faber at ISI.EDU (Ted Faber) Date: Mon, 23 Nov 2009 10:52:40 -0800 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B098B4D.2060806@web.de> References: <4B098B4D.2060806@web.de> Message-ID: <20091123185240.GA49913@zod.isi.edu> On Sun, Nov 22, 2009 at 08:04:45PM +0100, Detlef Bosau wrote: > Hi to all. > > The following questions may be stupid - however, the most stupid > questions are the never asked ones ;-) Jon Crowcroft's right, you should spend some time with Stevens. I also suggest that if you're going to be studying TCP, a good place to start your trip through the RFCs is RFC4614, the TCP Roadmap. You can find it here: http://www.rfc-editor.org/rfc/rfc4614.txt . While any such roadmap is quickly out-of-date, it is a fairly recent assessment of the TCP standards and important experimental RFCs conducted by some TCP gear-heads with impeccable credentials (and I include the tcpm working group here, in addition to the authors). The fast retransmit procedure is somewhat intricate, even without selective acknowledgements, and it's well worth studying Stevens' detailed, well written description of it. Jacobson's original paper is also worth a look, and referenced in the roadmap. But... > > 1.: Recently, I was told, however I did not find a reference in some > RFC, we had two distinct packet types in TCP: > - those _with_ payload, which are _data_ _segments_, > - those _without_ payload, which are _acknowledgements_. > > If this is correct, I would appreciate some reference. It's not. There is only one kind of segment, and during a connection's ESTABLISHED phase (the phase one cares about in congestion control) they all have ACKs. Note that each endpoint acknowledges the last data from the other. Endpoint A's packets contain the last byte received from endpoint B and vice versa. If one of those endpoints sends no data after acknowledging the other side's SYN+ACK segment, the ACKs from the other repeatedly acknowledge the last packet of the three-way handshake. One point you seem to be having trouble with: when an endpoint receives an ACK and that endpoint has no data outstanding (that is, all the data it has sent to the other endpoint has been previously acknowledged), it is safe to ignore the ACK. (OK, there are reasons to check the ACK to make sure your connection has not been hijacked or otherwise disrupted, but for the purposes of congestion control, you should ignore it). A duplicate ACK is only interesting to the congestion control system when the endpoint has sent data and is uncertain of that data's fate. It's difficult to lose data you have not sent. Imagine you got three duplicate acks of the last bit of acknowledged data you'd sent: what would you resend in the fast retransmit phase? > > 2.: RFC 2581 states, tat in slow start state CWND is incremented by > _new_ acknowledgements, not by duplicate acks. > The same holds true in congestion avoidance state. > > Question: Why is CWND is not incremented for dupacks? When I think about > it, I can find arguments for both ways. So, I would like to here the > rationale for the "standard version". If the duplicates are caused by reordering, the discrepency will be handled when the ACKs for the out of order packets arrive at the sender. If the packet is lost, the window will be inflated to account for them in the fast retransmit procedure. This is a little more hand-wavey than the rest of the procedure (and there are additional experimental procedures for recovering from reordered packets). Again, Stevens traces these paths in more detail than the RFC. > > 3. I do not quite understand the fast retransmit procedure in RFC 2581. That seems to be so. Again, I believe Stevens discusses it in detail. > To my understanding, the fast retransmit retransmits the "one" lost > segment indicated by last ack and does _not_ a go back n. In the absence of selective acknowledgements, the sender does a go-back-n when there is a fast retransmission. -- 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: 196 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20091123/45ceee94/attachment.bin From faber at ISI.EDU Mon Nov 23 11:49:08 2009 From: faber at ISI.EDU (Ted Faber) Date: Mon, 23 Nov 2009 11:49:08 -0800 Subject: [e2e] Some questions about TCP. In-Reply-To: <2a3692de0911231000l79ad2fau4edd3abe24440a6e@mail.gmail.com> References: <4B098B4D.2060806@web.de> <4B09B115.9020209@reed.com> <2a3692de0911231000l79ad2fau4edd3abe24440a6e@mail.gmail.com> Message-ID: <20091123194907.GC49913@zod.isi.edu> On Mon, Nov 23, 2009 at 07:00:12PM +0100, Dominik Kaspar wrote: > Hi Detlef, > > Maybe the answer to your questions is that a DupACK never contains a > payload. While a specific implementation may never generate a DUPACK with data (and I'm skeptical about that), the specification of the protocol certainly allows DUPACKs to exist on segments with payloads. TCP connections allow both endpoints to be sending data at once. You may have experienced this when you accidentally catted a large file through an ssh session. The server is pumping out streams of characters while you're trying to control-c the process. If one of your packets gets lost, the server need not stop to send 2 empty ACK segments back; it will simply duplicate the ACK on three data packets full of stuff you're trying to avoid seeing. :-) -- 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: 196 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20091123/3da5941e/attachment.bin From craig at aland.bbn.com Mon Nov 23 14:26:45 2009 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 23 Nov 2009 17:26:45 -0500 Subject: [e2e] E2E Research Group is shutting down Message-ID: <20091123222645.6B0D028E138@aland.bbn.com> Dear Friends and Colleagues: After 26 years, the End-to-End Research Group has decided to cease existence as of January 1st, 2010. While there is certainly still end-to-end research to be done, the group had ceased to effectively serve as a forum for those discussions. The E2E group had a great run, serving as a place where many researchers could bring their ideas for initial, informal, airing. The meetings could be bruising. (At one meeting, a member tried to encourage a speaker by saying "We're all friends here" only to pause and say, "No, I'm sorry, actually we eat our young, but proceed anyway"). But the meetings usually also brought insights. Ideas that were tested in E2E meetings include slow start and improved round-trip time estimation, Random Early Drop, Integrated and Differentiated Services, Weighted Fair Queuing, PAWS, and Transaction TCP. We'd like to single out Bob Braden's leadership in E2E's successes. Bob was chair of E2E from its inception until a few years ago. To support continued discussion of end-to-end research issues, the end2end-interest list will continue operation. We're grateful to Joe Touch for offering to keep the list alive. Joe will circulate a note soon about how the list will be managed going forward, after its Research Group home goes away. Thank you! Karen Sollins and Craig Partridge co-chairs, End-to-End Research Group From falk at bbn.com Mon Nov 23 14:39:57 2009 From: falk at bbn.com (Aaron Falk) Date: Mon, 23 Nov 2009 17:39:57 -0500 Subject: [e2e] [IRSG] E2E Research Group is shutting down In-Reply-To: <20091123222645.6B0D028E138@aland.bbn.com> References: <20091123222645.6B0D028E138@aland.bbn.com> Message-ID: <4B0B0F3D.2040509@bbn.com> Craig & Karen- My thanks to you and Karen -- and Bob Braden too, of course -- for your effort in keeping the RG going. I know this decision wasn't arrived at lightly. Best regards, --aaron -- Aaron Falk Chair Internet Research Task Force http://www.irtf.org Craig Partridge wrote: > Dear Friends and Colleagues: > > After 26 years, the End-to-End Research Group has decided to cease existence > as of January 1st, 2010. While there is certainly still end-to-end research > to be done, the group had ceased to effectively serve as a forum for those > discussions. > > The E2E group had a great run, serving as a place where many researchers > could bring their ideas for initial, informal, airing. The meetings could be > bruising. (At one meeting, a member tried to encourage a speaker by saying > "We're all friends here" only to pause and say, "No, I'm sorry, actually we > eat our young, but proceed anyway"). But the meetings usually also brought > insights. > > Ideas that were tested in E2E meetings include slow start and improved > round-trip time estimation, Random Early Drop, Integrated and Differentiated > Services, Weighted Fair Queuing, PAWS, and Transaction TCP. > > We'd like to single out Bob Braden's leadership in E2E's successes. Bob > was chair of E2E from its inception until a few years ago. > > To support continued discussion of end-to-end research issues, the > end2end-interest list will continue operation. We're grateful to Joe Touch > for offering to keep the list alive. Joe will circulate a note soon about > how the list will be managed going forward, after its Research Group home > goes away. > > Thank you! > > Karen Sollins and Craig Partridge > co-chairs, End-to-End Research Group > From richard at bennett.com Mon Nov 23 17:50:09 2009 From: richard at bennett.com (Richard Bennett) Date: Mon, 23 Nov 2009 17:50:09 -0800 Subject: [e2e] E2E Research Group is shutting down In-Reply-To: <20091123222645.6B0D028E138@aland.bbn.com> References: <20091123222645.6B0D028E138@aland.bbn.com> Message-ID: <4B0B3BD1.5010905@bennett.com> That's a shame, I just joined the party in time for the last round. RB Craig Partridge wrote: > Dear Friends and Colleagues: > > After 26 years, the End-to-End Research Group has decided to cease existence > as of January 1st, 2010. While there is certainly still end-to-end research > to be done, the group had ceased to effectively serve as a forum for those > discussions. > > The E2E group had a great run, serving as a place where many researchers > could bring their ideas for initial, informal, airing. The meetings could be > bruising. (At one meeting, a member tried to encourage a speaker by saying > "We're all friends here" only to pause and say, "No, I'm sorry, actually we > eat our young, but proceed anyway"). But the meetings usually also brought > insights. > > Ideas that were tested in E2E meetings include slow start and improved > round-trip time estimation, Random Early Drop, Integrated and Differentiated > Services, Weighted Fair Queuing, PAWS, and Transaction TCP. > > We'd like to single out Bob Braden's leadership in E2E's successes. Bob > was chair of E2E from its inception until a few years ago. > > To support continued discussion of end-to-end research issues, the > end2end-interest list will continue operation. We're grateful to Joe Touch > for offering to keep the list alive. Joe will circulate a note soon about > how the list will be managed going forward, after its Research Group home > goes away. > > Thank you! > > Karen Sollins and Craig Partridge > co-chairs, End-to-End Research Group > -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC From detlef.bosau at web.de Tue Nov 24 03:36:45 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 24 Nov 2009 12:36:45 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <2E27D7DF-398F-4097-A217-4A0952730FD4@mac.com> References: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> <4B09AC29.5010800@web.de> <2E27D7DF-398F-4097-A217-4A0952730FD4@mac.com> Message-ID: <4B0BC54D.3060505@web.de> rick jones wrote: > IIRC the duplicate ACK test includes the advertised window holding > fixed. If the arriving segment updates the window, On the sender side? Or on the receiver side? I can well imagine that a receiver may hand over data to the application between to acknowledging packets. So, why should particularly a receiver keep its advertised window fixed? -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Tue Nov 24 03:44:06 2009 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 24 Nov 2009 12:44:06 +0100 Subject: [e2e] Some questions about TCP. In-Reply-To: <2a3692de0911231000l79ad2fau4edd3abe24440a6e@mail.gmail.com> References: <4B098B4D.2060806@web.de> <4B09B115.9020209@reed.com> <2a3692de0911231000l79ad2fau4edd3abe24440a6e@mail.gmail.com> Message-ID: <4B0BC706.2010701@web.de> Dominik Kaspar wrote: > Hi Detlef, > > Maybe the answer to your questions is that a DupACK never contains a > payload. At least that is what a colleague and I could find in the > Linux source code. I doubt you will find a reference in RFCs. The only > hint that the RFC 2581 gives me, is the word "immediate" in the > sentence "A TCP receiver SHOULD send an immediate duplicate ACK when > an out-of-order segment arrives". I assume that "immediate" implies > somehow a quickly sent "bare" ACK and the absence of a payload... > > However, this requires to drop down the last sent acknowledgement at the receiver side in order to determine, whether a receiver sends a "new" ack or a "dup" ack. Is this correct? > FLAG_NOT_DUPACK defines the conditions of when a segment is not a > duplicate acknowledgment: > http://www.gelato.unsw.edu.au/lxr/source/net/ipv4/tcp_input.c#L105 > > This might also answer your question about what happens in a scenario > with extreme difference in up- and downlink speeds (like ADSL). The > numerous data packets that are traveling over the fast downlink may > acknowledge the same data, which might appear to be DupACKs, but they > all contain a payload, therefore, they are not treated as DupACKs. > > Not sure if that was of any help... > > I'm still thinking ;-) At least (after having slept one night over it ;-)) it seems to place the burden of discriminating new acks and dup acks on the receiver, correct? Detlef > Greetings, > Dominik > -- Detlef Bosau Galileistra?e 30 70565 Stuttgart phone: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From perfgeek at mac.com Tue Nov 24 08:41:30 2009 From: perfgeek at mac.com (rick jones) Date: Tue, 24 Nov 2009 08:41:30 -0800 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B0BC54D.3060505@web.de> References: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> <4B09AC29.5010800@web.de> <2E27D7DF-398F-4097-A217-4A0952730FD4@mac.com> <4B0BC54D.3060505@web.de> Message-ID: <4FA82414-DE2E-4BB6-BD35-E0AD520D33DE@mac.com> On Nov 24, 2009, at 3:36 AM, Detlef Bosau wrote: > rick jones wrote: >> IIRC the duplicate ACK test includes the advertised window holding >> fixed. If the arriving segment updates the window, > > On the sender side? Or on the receiver side? > > I can well imagine that a receiver may hand over data to the > application between to acknowledging packets. > So, why should particularly a receiver keep its advertised window > fixed? The receiver cannot hand to the application any data to the "right" of the first hole in the received sequence number space, there for it cannot advance the window past that hole. I believe it is this, and the "immediate" nature of ACKing segments arriving "out of order" coupled with the presumption that packet reordering is "rare" that allows the three "duplicate" ACKs from the receiver to signal that the segment starting at that sequence number was most likely lost. If the ACK advances the window, it cannot, by definition (?) say anything about reordering or loss. All the sender can infer from its receipt is that all is happiness and joy. Once there is a hole in the sequence space, there will be no advancing the window beyond it. So, ACKs arriving at the sender, for the same sequence number, and which do not advance the window can be presumed to have been triggered by segments "beyond" a hole starting at that point in the sequence space. Since reordering is presumed rare, when three of these duplicate ACKs have been received, we can presume that three segments beyond the possibly lost segment were received and be statistically certain that segment was indeed lost. rick jones there is no rest for the wicked, yet the virtuous have no pillows From perfgeek at mac.com Tue Nov 24 13:55:29 2009 From: perfgeek at mac.com (rick jones) Date: Tue, 24 Nov 2009 13:55:29 -0800 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B0C1F66.1030108@reed.com> References: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> <4B09AC29.5010800@web.de> <2E27D7DF-398F-4097-A217-4A0952730FD4@mac.com> <4B0BC54D.3060505@web.de> <4FA82414-DE2E-4BB6-BD35-E0AD520D33DE@mac.com> <4B0C1F66.1030108@reed.com> Message-ID: On Nov 24, 2009, at 10:01 AM, David P. Reed wrote: > > > On 11/24/2009 11:41 AM, rick jones wrote: >> Since reordering is presumed rare, when three of these duplicate >> ACKs have been received, we can presume that three segments beyond >> the possibly lost segment were received and be statistically >> certain that segment was indeed lost. >> > I may have gotten confused by the way this conversation has > wandered, but there is no statistical certainty of loss here. > There are lots of ways that three duplicate ACKs can be sent, and > then received. Every time the receiver receives a duplicate of a > previously accepted segment it will transmit another ACK with the > same content - there need be no "hole" and no segments to the > "right" of the hole. I shouldn't have invoked statistics when recounting my understanding of the reasoning behind the fast retransmit heuristic :) Wisdom teeth are impacted, people are affected by the effects of events From jnc at mercury.lcs.mit.edu Tue Nov 24 16:08:04 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 24 Nov 2009 19:08:04 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091125000804.DD1DD6BE5C0@mercury.lcs.mit.edu> > From: "David P. Reed" > there is no statistical certainty of loss here. There are lots of ways > that three duplicate ACKs can be sent, and then received. Every time > the receiver receives a duplicate of a previously accepted segment it > will transmit another ACK with the same content - there need be no > "hole" and no segments to the "right" of the hole. Sure, but the circumstances required to generate multiple ack-only packets (i.e. no data), where those aren't due to a lost packet causing a hole, are pretty unusual (i.e. rare). If you are seeing multiple ack-only TCP packets for the same segment, and those aren't due to a lost packet causing a hole, then either i) you retransmitted that segment several times, and either the original data segments, or the acks, all got wildly delayed (so long that you timed out and retransmitted it several times _before_ either a) the first segment got to the far end, or b) the first ack got back to you), or ii) it got duplicated somehow in the network. In other words, no, it's not 100% guaranteed that if you see multiple ack-only packets, there is a lost packet making a hole, but absent rare circumstances, it _most likely_ indicates a lost packet. I dunno what your definition of "statistical certainty" is, but that looks rather like it to me... :-) > TCP doesn't estimate certainties of loss Well, not directly, no. But fast-retransmit does effectively do just that ("estimate certaint[y] of loss"), doesn't it? Noel From jnc at mercury.lcs.mit.edu Tue Nov 24 16:18:08 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Tue, 24 Nov 2009 19:18:08 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091125001809.002596BE5C0@mercury.lcs.mit.edu> > then either i) you retransmitted that segment several times .. or > ii) it got duplicated somehow in the network. Ooops, I forgot about re-ordering (which can indeed simulate a hole). There may be others too, those are the only ones I can come up with off the top of my head. In that context, note this recent I-D: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-03.txt which is exactly 'on point' to this discussion. Noel From jtk at depaul.edu Wed Nov 25 08:17:58 2009 From: jtk at depaul.edu (John Kristoff) Date: Wed, 25 Nov 2009 10:17:58 -0600 Subject: [e2e] Some questions about TCP. In-Reply-To: <20091125000804.DD1DD6BE5C0@mercury.lcs.mit.edu> References: <20091125000804.DD1DD6BE5C0@mercury.lcs.mit.edu> Message-ID: <20091125161758.GA29932@condor.depaul.edu> On Tue, Nov 24, 2009 at 07:08:04PM -0500, Noel Chiappa wrote: > If you are seeing multiple ack-only TCP packets for the same segment, and > those aren't due to a lost packet causing a hole, then either i) you > retransmitted that segment several times, and either the original data > segments, or the acks, all got wildly delayed (so long that you timed out and > retransmitted it several times _before_ either a) the first segment got to > the far end, or b) the first ack got back to you), or ii) it got duplicated > somehow in the network. There is also the TCP keep-alive mechanism, which I believe may result in this type of behavior too, though I'm not familiar with implementation details or the scale of its deployment. John From jnc at mercury.lcs.mit.edu Wed Nov 25 11:18:55 2009 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 25 Nov 2009 14:18:55 -0500 (EST) Subject: [e2e] Some questions about TCP. Message-ID: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> > From: "David P. Reed" > if someone would provide a model with empirical parameters that > estimated the statistical probability for most cases in the network. Indeed; the I-D I referenced: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-03.txt does include such data, and points to the sources. Noel From braden at ISI.EDU Wed Nov 25 12:03:22 2009 From: braden at ISI.EDU (Bob Braden) Date: Wed, 25 Nov 2009 12:03:22 -0800 Subject: [e2e] Some questions about TCP. In-Reply-To: <20091125161758.GA29932@condor.depaul.edu> References: <20091125000804.DD1DD6BE5C0@mercury.lcs.mit.edu> <20091125161758.GA29932@condor.depaul.edu> Message-ID: <4B0D8D8A.2040807@isi.edu> John Kristoff wrote: > On Tue, Nov 24, 2009 at 07:08:04PM -0500, Noel Chiappa wrote: > >> If you are seeing multiple ack-only TCP packets for the same segment, and >> those aren't due to a lost packet causing a hole, then either i) you >> retransmitted that segment several times, and either the original data >> segments, or the acks, all got wildly delayed (so long that you timed out and >> retransmitted it several times _before_ either a) the first segment got to >> the far end, or b) the first ack got back to you), or ii) it got duplicated >> somehow in the network. >> > > There is also the TCP keep-alive mechanism, which I believe may result > in this type of behavior too, though I'm not familiar with implementation > details or the scale of its deployment. > > John > Note that there ISs no keepalive mechanism in the TCP spec (see the Discussion in Section 4.2.3.6 of RFC 1122). Jon Postel, the Arbiter of Good Taste in Protocols, was vehement against the idea. Berkeley Unix created one, and it caused a lot of mischief in the early days. Community concensus in the IETF forced RFC 1122 to allow ("MAY") implementation of a TCP keepalive, but it tried to severely limit its use (MUST default to "off"). Bob Braden From dpreed at reed.com Tue Nov 24 10:01:10 2009 From: dpreed at reed.com (David P. Reed) Date: Tue, 24 Nov 2009 13:01:10 -0500 Subject: [e2e] Some questions about TCP. In-Reply-To: <4FA82414-DE2E-4BB6-BD35-E0AD520D33DE@mac.com> References: <20091122210546.8B33B6BE564@mercury.lcs.mit.edu> <4B09AC29.5010800@web.de> <2E27D7DF-398F-4097-A217-4A0952730FD4@mac.com> <4B0BC54D.3060505@web.de> <4FA82414-DE2E-4BB6-BD35-E0AD520D33DE@mac.com> Message-ID: <4B0C1F66.1030108@reed.com> On 11/24/2009 11:41 AM, rick jones wrote: > Since reordering is presumed rare, when three of these duplicate ACKs > have been received, we can presume that three segments beyond the > possibly lost segment were received and be statistically certain that > segment was indeed lost. > I may have gotten confused by the way this conversation has wandered, but there is no statistical certainty of loss here. There are lots of ways that three duplicate ACKs can be sent, and then received. Every time the receiver receives a duplicate of a previously accepted segment it will transmit another ACK with the same content - there need be no "hole" and no segments to the "right" of the hole. TCP doesn't estimate certainties of loss - at best it tries to minimize the frequency that an IP datagram is unnecessarily retransmitted, while at the same time trying to estimate the short-term non-congesting rate that can be sustained by using the statistics of the queue-drop erasure channel and other inputs such as ECN bits as input to a channel model that is used to control the probability of congestion by controlling the window. From dpreed at reed.com Wed Nov 25 12:06:00 2009 From: dpreed at reed.com (David P. Reed) Date: Wed, 25 Nov 2009 15:06:00 -0500 Subject: [e2e] Some questions about TCP. In-Reply-To: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> References: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> Message-ID: <4B0D8E28.3090802@reed.com> Thanks, Noel. The statistics there are useful, but far from a model of the "erasure channel" created by packet drops due to congestion in a end-to-end congestion-controlled Internet. On 11/25/2009 02:18 PM, Noel Chiappa wrote: > > From: "David P. Reed" > > > if someone would provide a model with empirical parameters that > > estimated the statistical probability for most cases in the network. > > Indeed; the I-D I referenced: > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-03.txt > > does include such data, and points to the sources. > > Noel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20091125/1f58319a/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Fri Nov 27 01:19:54 2009 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 27 Nov 2009 09:19:54 +0000 Subject: [e2e] Some questions about TCP. In-Reply-To: <4B0D8E28.3090802@reed.com> References: <20091125191855.CA65C6BE59A@mercury.lcs.mit.edu> <4B0D8E28.3090802@reed.com> Message-ID: you wanna get pathological about it, there's a small, but non zero possibility that transmission errors caused by interference create a packet that is a duplicate of an ack, from a completely unrelated packet, and happen to create the right link and ip header and tcp checksum to match.... must have happened at least once since interweb day 0, whenever that was... In missive <4B0D8E28.3090802 at reed.com>, "David P. Reed" typed: >>This is a multi-part message in MIME format. >>--------------090609010209090806090900 >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>Content-Transfer-Encoding: 7bit >> >>Thanks, Noel. The statistics there are useful, but far from a model of >>the "erasure channel" created by packet drops due to congestion in a >>end-to-end congestion-controlled Internet. >> >>On 11/25/2009 02:18 PM, Noel Chiappa wrote: >>> > From: "David P. Reed" >>> >>> > if someone would provide a model with empirical parameters that >>> > estimated the statistical probability for most cases in the network. >>> >>> Indeed; the I-D I referenced: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-03.txt >>> >>> does include such data, and points to the sources. >>> >>> Noel >>> >>> >> >>--------------090609010209090806090900 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: 7bit >> >> >> >> >> > http-equiv="Content-Type"> >> >> >>Thanks, Noel.   The >>statistics there are useful, but far from a model of the "erasure >>channel" created by packet drops due to congestion in a end-to-end >>congestion-controlled Internet.
>>
>>On 11/25/2009 02:18 PM, Noel Chiappa wrote: >>
> type="cite"> >> 
    > From: "David P. Reed" <dpreed at reed.com>
 >>
 >>    > if someone would provide a model with empirical parameters that
 >>    > estimated the statistical probability for most cases in the network.
 >>
 >>Indeed; the I-D I referenced:
 >>
 >>  http://www.ietf.org/internet-drafts/draft-ietf-tcpm-early-rexmt-03.txt
 >>
 >>does include such data, and points to the sources.
 >>
 >>	Noel
 >>
 >>
>>
>> >> >> >>--------------090609010209090806090900-- cheers jon From jasleen at cs.unc.edu Wed Nov 25 08:27:32 2009 From: jasleen at cs.unc.edu (Jasleen Kaur) Date: Wed, 25 Nov 2009 11:27:32 -0500 Subject: [e2e] CFP: IEEE LANMAN 2010 Message-ID: <4B0D5AF4.6040903@cs.unc.edu> CALL FOR PAPERS The 17th IEEE Workshop on Local and Metropolitan Area Networks May 5-7, 2010, Long Branch, New Jersey, USA http://www.ieee-lanman.org The IEEE LAN/MAN Workshop continues its tradition as a leading forum for discussing the latest technical advances in networking in the local and metropolitan areas. The workshop will retain the LANMAN mainstay of Local and Metropolitan area networking, including edge applications. This year, the workshop will also focus on two compelling issues for edge networks that are currently experiencing significant change and innovation: the first is the design of scalable architectures for enterprise and data center networks. This area is motivated by the evolution of mega-scale data centers for which traditional layer-2 network designs simply do not scale, as well as the need to better design enterprise networks that carry increasing high bit-rate traffic. The second focus area is the design of scalable mechanisms and protocols for network management and trouble-shooting in home and enterprise networks. Currently, many of these issues are handled manually --- this practice is simply not scalable as home and enterprise networks get larger and user needs get more demanding. LANMAN seeks both theoretical and experimental contributions. Single-track presentations are planned to stimulate technical exchange among researchers and practitioners with a broad interest in networking. We expect the workshop to be a forum for discussion of new and interdisciplinary ideas on new architectures, paradigms, concepts, and economic and service models. Novel and speculative ideas are particularly encouraged. We also encourage studies based on measurements from real-life networks and testbeds. Extended abstracts are solicited on any LANMAN topic including, but not limited to, the following: * Broadband Wireless Access, including WiMAX * WiFi: roaming services, Architectures & Performance * Metropolitan & Residential Networks and Architectures including Ethernet in the First Mile, EPONs, FTTx etc. * IPTV, video delivery and applications * SANs and Storage over MANs * IEEE 802 standards * Optical WDM networks based on packet, burst, and flow switching * RFid protocols & performance * Topology adaptation, reconfigurability, routing * Network management related to Edge Networks * Heterogeneous Wireless and Ad-Hoc Networks * Ubiquitous wireless, wired and remote access * Adaptive wireless networks including cognitive radios * Measurement, modeling and performance evaluation * Cross layer QoS, dynamic bandwidth allocation, capacity placement/provisioning * Network reliability and survivability * Network security * Pricing, multi-vendor interoperability * LAN and MAN based applications (gaming, distributed computing, media distribution to and in the home, enterprise applications, ambient technology, wearable-computing) * Impact of sensors everywhere including homes The 17th LAN/MAN workshop will be held from May 5-7, 2010 at the Ocean Place Resort & Spa in Long Branch, New Jersey. The technical interactions at the workshop will be enhanced by the social activities and sightseeing possibilities in the area. Submission, Review and Publication: Please submit a 4-6 page extended abstract, including figures and tables. All abstracts must be electronically submitted in PDF according to the guidelines in the workshop website http://www.ieee-lanman.org The proceedings will be published by IEEE Xplore and will include the final version of the Extended Abstract of up to 6 pages. Two-page extended abstract (including figures and tables) will also be accepted for a Poster session. Important Dates: Paper Registration: February 5, 2010 Paper Submission: February 12, 2010 Poster Submission: March 10, 2010 Paper Notification: March 20, 2010 Camera-ready Submission: April 10, 2010 Workshop Dates: May 5-7, 2010 General Chairs Jacobus E van der Merwe, Maria Papadopouli, AT&T Labs-Research, USA ICS-FORTH, Greece Technical Program Chairs Jasleen Kaur, Srinivasan Ramasubramanian, UNC-Chapel Hill, USA University of Arizona, USA Program Committee Andrea Bianco, Politecnico di Torino, Italy Reuven Cohen, Technion, Israel Virgil Dobrota, Technical University of Cluj-Napoca, Romania Jordi Domingo-Pascual, Universitat Politecnica de Catalunya, Spain Stein Gjessing, University of Oslo, Norway Shivkumar Kalyanaraman, IBM Research Labs, India Arata Koike, NTT, Japan Cornal Pampu, Huawei Technologies Daniel Pitt, Palo Alto Innovation Advisors LLC George Polyzos, AUEB, Athens, Greece K.K. Ramakrishnan, AT&T Labs - Research, USA Byrav Ramamurthy, University of Nebraska-Lincoln, USA George Rouskas, North Carolina State University, USA Naveen Santhapuri, Duke University, USA Vasilios Siris, Athens Univ of Economics and Business and ICS-FORTH, Greece Cormac Sreenan, University College Cork, Ireland Kris Steenhaut, Vrije Universiteit Brussels, Belgium Burkhard Stiller, University of Zurich and ETH Zurich, Switzerland Geoff Xie, Naval Postgraduate School, USA From L.Wood at surrey.ac.uk Sat Nov 28 14:04:40 2009 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Sat, 28 Nov 2009 22:04:40 +0000 Subject: [e2e] E2E Research Group is shutting down In-Reply-To: <20091123222645.6B0D028E138@aland.bbn.com> References: <20091123222645.6B0D028E138@aland.bbn.com> Message-ID: <1F00E685-7380-4E6E-B3CC-87E2863C1B85@surrey.ac.uk> On 23 Nov 2009, at 22:26, Craig Partridge wrote: > > Dear Friends and Colleagues: > > After 26 years, the End-to-End Research Group has decided to cease existence > as of January 1st, 2010. While there is certainly still end-to-end research > to be done, the group had ceased to effectively serve as a forum for those > discussions. http://www.postel.org/pipermail/end2end-interest/2007-December/007005.html predicted: > 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. L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/