From braden at ISI.EDU Wed Jan 2 09:40:44 2008 From: braden at ISI.EDU (Bob Braden) Date: Wed, 2 Jan 2008 09:40:44 -0800 (PST) Subject: [e2e] Modular/Pluggable TCP Congestion Control for FreeBSD Message-ID: <200801021740.JAA29666@gra.isi.edu> *> *> Hi all, *> *> We've been involved in a research project to implement and test an *> emerging TCP congestion control algorithm under FreeBSD. As a part of *> this, we've put together a patch for FreeBSD 7.0-BETA4 that modularises *> the congestion control code in the TCP stack. It allows for new *> congestion control algorithms to be developed as loadable kernel modules. *> Research project? Uhhh, this sounds like an implementation of Hari Balakrishnan's Congestion Manager (ACM SIGCOMM 1999), but perhaps I am missing something. Long, long ago I heard Herb Simon quip that, while most scientists stand on each other's shoulders, Computer Scientists stand on each other's toes. Bob Braden From dpreed at reed.com Wed Jan 2 19:15:25 2008 From: dpreed at reed.com (David P. Reed) Date: Wed, 02 Jan 2008 22:15:25 -0500 Subject: [e2e] patents on routing algorithms Message-ID: <477C534D.3090206@reed.com> A student just mentioned to me that AODV and OLSR routing algorithms are patented. I have to say I was surprised. Anyone know by whom, and what the licensing requirements are? Are there also patents on any end-to-end protocols described by RFCs? From touch at ISI.EDU Wed Jan 2 21:45:04 2008 From: touch at ISI.EDU (Joe Touch) Date: Wed, 02 Jan 2008 21:45:04 -0800 Subject: [e2e] patents on routing algorithms In-Reply-To: <477C534D.3090206@reed.com> References: <477C534D.3090206@reed.com> Message-ID: <477C7660.8020406@isi.edu> David P. Reed wrote: > A student just mentioned to me that AODV and OLSR routing algorithms are > patented. I have to say I was surprised. Anyone know by whom, and > what the licensing requirements are? > > Are there also patents on any end-to-end protocols described by RFCs? See: https://datatracker.ietf.org/ipr/ OSPF, in particular, has IBM IPR claims. Many are of the form "don't enforce against us, and you can use this one for free"; something of that general flexibility is typically the most restrictive accepted for standards-track protocols. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080102/5ff4979a/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Wed Jan 2 22:53:30 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 03 Jan 2008 06:53:30 +0000 Subject: [e2e] patents on routing algorithms In-Reply-To: <477C7660.8020406@isi.edu> References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> Message-ID: a letter in this month's CACM reminds us that the Church-Turing Theorem states that algorithms and mathematics are the same - math is unpatentable so ... time to trash algorithm patents esp. where they are used in clear violation even of the original (at least US) intent of patent law....edison will be turning in his grave... the ietf has (had) the right model.. In missive <477C7660.8020406 at isi.edu>, Joe Touch typed: >>This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >>--------------enig1A3BBBC866E744BC19654C61 >>Content-Type: text/plain; charset=ISO-8859-1 >>Content-Transfer-Encoding: quoted-printable >> >> >> >>David P. Reed wrote: >>> A student just mentioned to me that AODV and OLSR routing algorithms ar= >>e >>> patented. I have to say I was surprised. Anyone know by whom, and >>> what the licensing requirements are? >>>=20 >>> Are there also patents on any end-to-end protocols described by RFCs? >> >>See: https://datatracker.ietf.org/ipr/ >> >>OSPF, in particular, has IBM IPR claims. Many are of the form "don't >>enforce against us, and you can use this one for free"; something of >>that general flexibility is typically the most restrictive accepted for >>standards-track protocols. >> >>Joe >> >> >>--------------enig1A3BBBC866E744BC19654C61 >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.7 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFHfHZsE5f5cImnZrsRAtvAAJ40kmzYfBSly/WuBGtKY7A/SjrPfwCgly99 >>gO04SV3gJ+tRnkS7lEz4XM8= >>=blSw >>-----END PGP SIGNATURE----- >> >>--------------enig1A3BBBC866E744BC19654C61-- cheers jon From detlef.bosau at web.de Thu Jan 3 07:39:38 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 03 Jan 2008 16:39:38 +0100 Subject: [e2e] Modular/Pluggable TCP Congestion Control for FreeBSD In-Reply-To: <200801021740.JAA29666@gra.isi.edu> References: <200801021740.JAA29666@gra.isi.edu> Message-ID: <477D01BA.3000706@web.de> Bob Braden wrote: > Long, long ago I heard Herb Simon quip that, while most scientists > stand on each other's shoulders, Computer Scientists stand on each > other's toes. > Hm. IIRC, Wes Eddy accredited this to Hamming ;-) > Bob Braden > > -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From bms at incunabulum.net Thu Jan 3 07:50:03 2008 From: bms at incunabulum.net (Bruce M Simpson) Date: Thu, 03 Jan 2008 15:50:03 +0000 Subject: [e2e] patents on routing algorithms In-Reply-To: <477C7660.8020406@isi.edu> References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> Message-ID: <477D042B.30707@incunabulum.net> Joe Touch wrote: > David P. Reed wrote: > >> A student just mentioned to me that AODV and OLSR routing algorithms are >> patented. I have to say I was surprised. Anyone know by whom, and >> what the licensing requirements are? >> > See: https://datatracker.ietf.org/ipr/ > I see no matches for RFC 3626 (OLSR), and am unaware of any patent claims in this area. David, can your student provide any more information about these IPR claims? There's a lot of junk (patents|laws|culture|food) out there these days. A brief search reveals this, which sounds like a junk patent: http://www.freshpatents.com/Network-architecture-dt20071213ptan20070286097.php There are a number of efforts related to OLSR which make the "don't hit us, and we won't hit you" approach explicit in their wording, but they are not OLSR itself, merely extensions. Perhaps someone should start a social networking site, whereby organisations which file embarassingly general patents, such as this one, are named and shamed, and generally poked fun at by the rest of the human race. Even more embarassingly, the implementation of such a social networking site would probably violate said 'patent'. Love and kisses BMS From touch at ISI.EDU Thu Jan 3 11:22:38 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Jan 2008 11:22:38 -0800 Subject: [e2e] Modular/Pluggable TCP Congestion Control for FreeBSD In-Reply-To: <477D01BA.3000706@web.de> References: <200801021740.JAA29666@gra.isi.edu> <477D01BA.3000706@web.de> Message-ID: <477D35FE.3090906@isi.edu> Detlef Bosau wrote: > Bob Braden wrote: >> Long, long ago I heard Herb Simon quip that, while most scientists >> stand on each other's shoulders, Computer Scientists stand on each >> other's toes. >> > > Hm. IIRC, Wes Eddy accredited this to Hamming ;-) FWIW: "If I have seen further than others, it is by standing on the shoulders of giants" is attributed to Isaac Newton from his use in a letter to Robert Hooke, February 5, 1675, but ts origin goes back another 400 years or so to a philosopher named Bernard of Chartres around 1130: "We are like dwarfs standing [or sitting] upon the shoulders of giants, and so able to see more and see farther than the ancients." http://www.aerospaceweb.org/question/history/q0162b.shtml Mathematicians were brought into the comparison by Gauss: "Mathematicians stand on each other's shoulders." Richard Hamming said the following, at least by most sources: "Mathematicians stand on each other's shoulders while computer scientists stand on each other's toes." A number of sources attribute a similar quote to Brian Reid: "In computer science, we stand on each other's feet." The version comparing scientists and computer scientists above hasn't (yet) been attributed to anyone... Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080103/13f73ff0/signature.bin From touch at ISI.EDU Thu Jan 3 13:38:23 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Jan 2008 13:38:23 -0800 Subject: [e2e] patents on routing algorithms In-Reply-To: References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> Message-ID: <477D55CF.5040704@isi.edu> Jon Crowcroft wrote: > a letter in this month's CACM reminds us that the Church-Turing Theorem > states that algorithms and mathematics are the same - math is unpatentable > so ... FWIW, math isn't patentable itself, but is potentially patentable when applied to a real problem (e.g., general path calculation wouldn't be, but IP packet routing would even if it's basically just an application of general path calculation). See, e.g.,: http://www.bitlaw.com/software-patent/history.html Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080103/862bd9a4/signature.bin From dpreed at reed.com Thu Jan 3 14:26:17 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 03 Jan 2008 17:26:17 -0500 Subject: [e2e] patents on routing algorithms In-Reply-To: <477D55CF.5040704@isi.edu> References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> Message-ID: <477D6109.9020701@reed.com> One should be careful that just because we speak English on this list, we don't all live in England. US patent law is different from that in other jurisdictions. We aren't talking about "software patents" when we refer to processes that involve sending messages between devices - i.e. network protocols - by the way. The BGP spec is not code for a computer, nor is AODV. In fact, BGP Algorithm patents are not strictly identical to software patents. An algorithm is a process. A software program is a recipe that causes a device to perform a process, but it also typically has "free variables" so it is a recipe that is not terribly specific. At some degree of non-specificity it almost certainly doesn't specify anything narrow enough to be patentable subject matter. Of course, all these nouns that I am forced to use to describe abstractions create the illusion that descriptions are equivalent to the things described. /*"Ceci n'est pas une pipe" (see http://en.wikipedia.org/wiki/The_Treachery_of_Images) or, if you prefer the American Presidentialism: "it all depends on what is is" (Clinton). */ Joe Touch wrote: > Jon Crowcroft wrote: > >> a letter in this month's CACM reminds us that the Church-Turing Theorem >> states that algorithms and mathematics are the same - math is unpatentable >> so ... >> > > FWIW, math isn't patentable itself, but is potentially patentable when > applied to a real problem (e.g., general path calculation wouldn't be, > but IP packet routing would even if it's basically just an application > of general path calculation). > > See, e.g.,: > http://www.bitlaw.com/software-patent/history.html > > Joe > > From touch at ISI.EDU Thu Jan 3 14:47:52 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Jan 2008 14:47:52 -0800 Subject: [e2e] patents on routing algorithms In-Reply-To: <477D6109.9020701@reed.com> References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> <477D6109.9020701@reed.com> Message-ID: <477D6618.8030409@isi.edu> David P. Reed wrote: ...> We aren't talking about "software patents" when we refer to processes > that involve sending messages between devices - i.e. network > protocols - by the way. The BGP spec is not code for a computer, nor > is AODV. In fact, BGP Algorithm patents are not strictly identical to > software patents. An algorithm is a process. Algorithms, in the abstract sense, are closer to mathematical equations, which (AFAICT, not being a lawyer) remain non-patentable in the US. Implementations of those algorithms in distributed systems are closer to processes, which is partly why the US patent law changed in this area (as the URL below notes). "Processes", as used in patents, refer to a sequence of steps that results in a physical artifact: A process or method that consists of an act, operation, or step or series thereof performed upon a specified subject matter to produce a physical result. E.g., the process for manufacturing wine from grapes or the process for making paper clips from wire. I'm not familiar with any pure algorithm patent. It's not the spec of BGP that would be patentable, AFAICT, but rather any rendering of the algorithm for the purposes of forwarding packets between administrative domains (presuming BGP were patented, as an example). Joe >> Joe Touch wrote: >> Jon Crowcroft wrote: >> >>> a letter in this month's CACM reminds us that the Church-Turing Theorem >>> states that algorithms and mathematics are the same - math is >>> unpatentable >>> so ... >>> >> >> FWIW, math isn't patentable itself, but is potentially patentable when >> applied to a real problem (e.g., general path calculation wouldn't be, >> but IP packet routing would even if it's basically just an application >> of general path calculation). >> >> See, e.g.,: >> http://www.bitlaw.com/software-patent/history.html >> >> Joe >> >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080103/102a2220/signature.bin From touch at ISI.EDU Thu Jan 3 15:05:34 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Jan 2008 15:05:34 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <45A4D230.5020105@web.de> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> Message-ID: <477D6A3E.7080900@isi.edu> Detlef Bosau wrote: > Lynne Jolitz wrote: ... >> Many people on the academic side still use forms of BSD, and perhaps >> prefer the old way of doing things. I use BSD myself. However, Linux >> is clearly the market leader and cooperating with how they handle >> their development model is a key consideration for promulgating new >> work in networking and operating systems. > > That?s simply not the point. > > I think, Lloyd Wood made the point precisely: > > "Academics are rewarded by writing papers. They are not rewarded by > staying current with the current codebase of the linux kernel/ns." Nor are they rewarded for paying the penalty of the goofiness of the Linux community in deploying experimental protocols as default. This has come up at a number of IETF meetings, in particular, regarding CUBIC which is currently the default in Linux despite being an Internet Draft intended as experimental in the IETF. Academics like stability, and they like things that follow standards. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080103/e90c4015/signature.bin From ian.mcdonald at jandi.co.nz Thu Jan 3 15:50:33 2008 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Fri, 4 Jan 2008 12:50:33 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477D6A3E.7080900@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> Message-ID: <5640c7e00801031550m3a49f988hde91950dce891c64@mail.gmail.com> On Jan 4, 2008 12:05 PM, Joe Touch wrote: > > > I think, Lloyd Wood made the point precisely: > > > > "Academics are rewarded by writing papers. They are not rewarded by > > staying current with the current codebase of the linux kernel/ns." > > Nor are they rewarded for paying the penalty of the goofiness of the > Linux community in deploying experimental protocols as default. This has > come up at a number of IETF meetings, in particular, regarding CUBIC > which is currently the default in Linux despite being an Internet Draft > intended as experimental in the IETF. > > Academics like stability, and they like things that follow standards. > > Joe > > I think academics do themselves a dis-service when they hide behind their simulators and don't go out and try and use software. It's often interesting to compare what happens in the simulator to the "real world". What use is the research without applying it? There is a real shortage of academics in the Linux community (and probably the BSD community too) - when I was involved I only saw two or three being active out of many 100s/1000s of network researchers there must be. I've personally been involved in the debates in the Linux community around BIC, Cubic, ABC, RTO minimums etc and have been able to influence some change. Where academics have gotten involved they have usually (but not always) been listened to. I know some academics have shied away from joining in the debates because they get "flamed". I'd say two things about this - it is getting less flamey and it's also less harsh than many peer reviews I've had on my papers! If you want to make a difference here, get involved. Regards, Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz From touch at ISI.EDU Thu Jan 3 15:59:11 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Jan 2008 15:59:11 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00801031550m3a49f988hde91950dce891c64@mail.gmail.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <5640c7e00801031550m3a49f988hde91950dce891c64@mail.gmail.com> Message-ID: <477D76CF.8000402@isi.edu> Ian McDonald wrote: > On Jan 4, 2008 12:05 PM, Joe Touch wrote: >>> I think, Lloyd Wood made the point precisely: >>> >>> "Academics are rewarded by writing papers. They are not rewarded by >>> staying current with the current codebase of the linux kernel/ns." >> Nor are they rewarded for paying the penalty of the goofiness of the >> Linux community in deploying experimental protocols as default. This has >> come up at a number of IETF meetings, in particular, regarding CUBIC >> which is currently the default in Linux despite being an Internet Draft >> intended as experimental in the IETF. >> >> Academics like stability, and they like things that follow standards. >> >> Joe > > > I think academics do themselves a dis-service when they hide behind > their simulators and don't go out and try and use software. Not all "non-Linux" research is done in simulators. BSD, e.g., *is* software. FreeBSD supported multilevel IP tunnels years before Linux, which is why I used it for overlay research for the past decade. And BSD is in Apple OS/X. ... > If you want to make a difference here, get involved. I have - in FreeBSD, FWIW. We've contributed a number of patches to enable multilayer tunneling and support IPsec interactions with tunnels to KAME and BSD. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080103/da6efabf/signature.bin From L.Wood at surrey.ac.uk Thu Jan 3 17:53:24 2008 From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk) Date: Fri, 4 Jan 2008 01:53:24 -0000 Subject: [e2e] Are we doing sliding window in the Internet? References: <003801c73448$713c10c0$6e8944c6@telemuse.net><45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> Message-ID: <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> Didn't we have this same conversation last January? How is e.g. Microsoft any different with compound TCP being only an internet-draft: http://tools.ietf.org/id/draft-sridharan-tcpm-ctcp-01.txt yet deployed widely in Vista? Doing the whole FreeBSD-sneering-at-Linux thing is, well, old. There are many academics using Linux, not least because it's not picky about what it runs on. You're ignoring the goofy elephant in the room. Linux deploying experimental protocols means it's less work for academics to tweak newly-designed protocols and propose and test variants, ergo academics like it. Stability doesn't come into it, if academic code is anything to go by. An academic views code as stable if it hasn't crashed on him recently, or if it gives usable results before (or even while) crashing. It's all about the results. Academics like results, and they like things that get them results easily. And where's the research value and funding in working on an already existing standard? L. Detlef Bosau wrote: > Lynne Jolitz wrote: ... >> Many people on the academic side still use forms of BSD, and perhaps >> prefer the old way of doing things. I use BSD myself. However, Linux >> is clearly the market leader and cooperating with how they handle >> their development model is a key consideration for promulgating new >> work in networking and operating systems. > > That?s simply not the point. > > I think, Lloyd Wood made the point precisely: > > "Academics are rewarded by writing papers. They are not rewarded by > staying current with the current codebase of the linux kernel/ns." Nor are they rewarded for paying the penalty of the goofiness of the Linux community in deploying experimental protocols as default. This has come up at a number of IETF meetings, in particular, regarding CUBIC which is currently the default in Linux despite being an Internet Draft intended as experimental in the IETF. Academics like stability, and they like things that follow standards. Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/05f4dc13/attachment.html From dpreed at reed.com Thu Jan 3 19:02:41 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 03 Jan 2008 22:02:41 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> References: <003801c73448$713c10c0$6e8944c6@telemuse.net><45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: <477DA1D1.50809@reed.com> This list, is, after all, associated with the IRTF, not the IETF. I must admit that I may be seen as biased, since I tend to run the "git" version of the Linux mainstream kernel, so I live at the bleeding edge, and I have contributed small fixes to the kernel development process (one being queued for 2.6.25 as we speak). It seems extremely healthy for Linux (as the only game in town for truly planet-scale open research collaboration at the OS level) to be allowing its users to participate in shaking out issues in the evolving Internet. If only Microsoft would allow experimenters planet-wide to experiment with its full OS source code so that students can learn... naah. Wouldn't want to hurt BillG's ego by confronting the idea that today's kids include some smarter than he is/was... better to act like IBM mainframers did when he was a kid. L.Wood at surrey.ac.uk wrote: > > Didn't we have this same conversation last January? > > How is e.g. Microsoft any different with compound TCP being only an > internet-draft: > http://tools.ietf.org/id/draft-sridharan-tcpm-ctcp-01.txt > yet deployed widely in Vista? > > Doing the whole FreeBSD-sneering-at-Linux thing is, well, old. There > are many academics using Linux, not least because it's not picky about > what it runs on. You're ignoring the goofy elephant in the room. > > Linux deploying experimental protocols means it's less work for > academics to tweak newly-designed protocols and propose and test > variants, ergo academics like it. > > Stability doesn't come into it, if academic code is anything to go by. > An academic views code as stable if it hasn't crashed on him recently, > or if it gives usable results before (or even while) crashing. It's > all about > the results. Academics like results, and they like things that get them > results easily. > > And where's the research value and funding in working on an > already existing standard? > > L. > > Detlef Bosau wrote: > > Lynne Jolitz wrote: > ... > >> Many people on the academic side still use forms of BSD, and perhaps > >> prefer the old way of doing things. I use BSD myself. However, Linux > >> is clearly the market leader and cooperating with how they handle > >> their development model is a key consideration for promulgating new > >> work in networking and operating systems. > > > > That?s simply not the point. > > > > I think, Lloyd Wood made the point precisely: > > > > "Academics are rewarded by writing papers. They are not rewarded by > > staying current with the current codebase of the linux kernel/ns." > > Nor are they rewarded for paying the penalty of the goofiness of the > Linux community in deploying experimental protocols as default. This has > come up at a number of IETF meetings, in particular, regarding CUBIC > which is currently the default in Linux despite being an Internet Draft > intended as experimental in the IETF. > > Academics like stability, and they like things that follow standards. > > Joe > > From touch at ISI.EDU Thu Jan 3 21:36:26 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Jan 2008 21:36:26 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477DA1D1.50809@reed.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net><45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> Message-ID: <477DC5DA.6070800@isi.edu> David P. Reed wrote: > This list, is, after all, associated with the IRTF, not the IETF. I > must admit that I may be seen as biased, since I tend to run the "git" > version of the Linux mainstream kernel, so I live at the bleeding edge, > and I have contributed small fixes to the kernel development process > (one being queued for 2.6.25 as we speak). > > It seems extremely healthy for Linux (as the only game in town for truly > planet-scale open research collaboration at the OS level) to be allowing > its users to participate in shaking out issues in the evolving Internet. It's great that Linux has variants of TCP that users can enable. It's irresponsible and/or sloppy to enable those experiments by default. > If only Microsoft would allow experimenters planet-wide to experiment > with its full OS source code so that students can learn... naah. I'm not sure I'd want my students have that kind of a setback; going back a decade or so in capability isn't an enabling experience. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080103/d3b78b2f/signature.bin From touch at ISI.EDU Thu Jan 3 21:37:10 2008 From: touch at ISI.EDU (Joe Touch) Date: Thu, 03 Jan 2008 21:37:10 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> References: <003801c73448$713c10c0$6e8944c6@telemuse.net><45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> Message-ID: <477DC606.1020203@isi.edu> L.Wood at surrey.ac.uk wrote: > Didn't we have this same conversation last January? > > How is e.g. Microsoft any different with compound TCP being only an > internet-draft: > http://tools.ietf.org/id/draft-sridharan-tcpm-ctcp-01.txt > yet deployed widely in Vista? It isn't; we were talking about Linux. I'll sneer at Windows too, if you like, on this point. > Doing the whole FreeBSD-sneering-at-Linux thing is, well, old. There > are many academics using Linux, not least because it's not picky about > what it runs on. You're ignoring the goofy elephant in the room. Some academics do use Linux. Some use BSD. You're certainly right that - depending on what you want as your base - Linux can be more enabling. If you want support for arbitrary device, Linux wins, e.g.. If I want a book that walks students through the networking source code, BSD wins, e.g. For networking, I admit I am perplexed. On the one hand, we have a system built by academics basically for research use. On the other, we have a system designed most specifically not to look like BSD. I'm not sure 'not being BSD' is the best core design criteria. However, yes, that's an academic discussion. > Stability doesn't come into it, if academic code is anything to go by. > An academic views code as stable if it hasn't crashed on him recently, > or if it gives usable results before (or even while) crashing. It's all > about > the results. Academics like results, and they like things that get them > results easily. Yes, and as I noted, BSD crashes never basically assumed file system corruption like Linux did. Academics - who crash systems a lot in the process of developing code - don't like systems that require complete reinstalls inside the debug cycle either. > And where's the research value and funding in working on an > already existing standard? There is research in working on new variants in a stable base; having Linux - or Windows - add a variable to an experiment doesn't help. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080103/7b8f0393/signature.bin From ian.mcdonald at jandi.co.nz Thu Jan 3 22:20:33 2008 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Fri, 4 Jan 2008 19:20:33 +1300 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477DC5DA.6070800@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> Message-ID: <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> On Jan 4, 2008 6:36 PM, Joe Touch wrote: > It's great that Linux has variants of TCP that users can enable. It's > irresponsible and/or sloppy to enable those experiments by default. > If that is your opinion then go argue your case on netdev at vger.kernel.org. I don't necessarily disagree but this is the area to debate it, not on this list (if you want change that is). I'm not aware of many Linux developers listening to this list. People there DO listen to good points so it is worth discussing there. Ian -- Web1: http://wand.net.nz/~iam4/ Web2: http://www.jandi.co.nz From Jon.Crowcroft at cl.cam.ac.uk Thu Jan 3 23:01:27 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 04 Jan 2008 07:01:27 +0000 Subject: [e2e] patents on routing algorithms In-Reply-To: <477D6109.9020701@reed.com> References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> <477D6109.9020701@reed.com> Message-ID: it is a goal of much recent work (see Sewell et al in sigcomm 05 "Rigorous specification and conformance testing techniques for network protocols, as applied to TCP, UDP, and sockets" and various papers by Griffin and Sobrinho on Metarouting) to render protocols merely algorithmic specifications that are fed into engines that run them shame on us as computer scientists that we dont use such techniques on a daily basis for well-found engineering instead of the handwaving that passes for communications work still in the 21st century it is a technical AND ethical goal to make it so and should be a duty on all of us to get the law to recognize it In missive <477D6109.9020701 at reed.com>, "David P. Reed" typed: >>One should be careful that just because we speak English on this list, >>we don't all live in England. US patent law is different from that in >>other jurisdictions. >> >>We aren't talking about "software patents" when we refer to processes >>that involve sending messages between devices - i.e. network protocols - >>by the way. The BGP spec is not code for a computer, nor is AODV. In >>fact, BGP >> >>Algorithm patents are not strictly identical to software patents. An >>algorithm is a process. A software program is a recipe that causes a >>device to perform a process, but it also typically has "free variables" >>so it is a recipe that is not terribly specific. At some degree of >>non-specificity it almost certainly doesn't specify anything narrow >>enough to be patentable subject matter. >> >>Of course, all these nouns that I am forced to use to describe >>abstractions create the illusion that descriptions are equivalent to the >>things described. >> >>/*"Ceci n'est pas une pipe" (see >>http://en.wikipedia.org/wiki/The_Treachery_of_Images) >> >>or, if you prefer the American Presidentialism: "it all depends on what >>is is" (Clinton). >>*/ >> >> >>Joe Touch wrote: >>> Jon Crowcroft wrote: >>> >>>> a letter in this month's CACM reminds us that the Church-Turing Theorem >>>> states that algorithms and mathematics are the same - math is unpatentable >>>> so ... >>>> >>> >>> FWIW, math isn't patentable itself, but is potentially patentable when >>> applied to a real problem (e.g., general path calculation wouldn't be, >>> but IP packet routing would even if it's basically just an application >>> of general path calculation). >>> >>> See, e.g.,: >>> http://www.bitlaw.com/software-patent/history.html >>> >>> Joe >>> >>> cheers jon From dpreed at reed.com Fri Jan 4 05:26:38 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Jan 2008 08:26:38 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> Message-ID: <477E340E.9050505@reed.com> To Ian's point: there are two highly separated layers of decision making in Linux. To wit: 1)the kernel developers (in which I include the net developers, though the groups are somewhat distinct), and 2) the distro makers. The distro makers are free to enable or disable many of the options in the kernel they choose to ship - including TCP experiments as part of a broad "permanent beta program" that certain distros aspire to be. Different distros may or may not do this. I happen to have settled on Fedora as my "base distro". I like it's risk-taking, relatively bleeding-edge approach of including the community in testing out new things (it's been called the "beta" for RedHat). But you can also use RedHat Enterprise Linux (or the free version of that or Suse if you want conservative, carefully thought through non-experimental distributions. The place to argue about what is distributed to the broad user groups who don't want to be part of the experimental linux community is with the distro builders in one or more of the distros that focus on "the general public". Ubuntu perhaps should have a different philosophy about releasing experimental TCP features in its kernels than does Fedora. Ian McDonald wrote: > On Jan 4, 2008 6:36 PM, Joe Touch wrote: > >> It's great that Linux has variants of TCP that users can enable. It's >> irresponsible and/or sloppy to enable those experiments by default. >> >> > If that is your opinion then go argue your case on > netdev at vger.kernel.org. I don't necessarily disagree but this is the > area to debate it, not on this list (if you want change that is). I'm > not aware of many Linux developers listening to this list. People > there DO listen to good points so it is worth discussing there. > > Ian > From dpreed at reed.com Fri Jan 4 05:42:39 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Jan 2008 08:42:39 -0500 Subject: [e2e] patents on routing algorithms In-Reply-To: References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> <477D6109.9020701@reed.com> Message-ID: <477E37CF.5010707@reed.com> Jon Crowcroft wrote: > it is a goal of much recent work (see Sewell et al in sigcomm 05 > "Rigorous specification and conformance testing techniques for network protocols, > as applied to TCP, UDP, and sockets" > and various papers > by Griffin and Sobrinho on Metarouting) > to render protocols merely > algorithmic specifications that are fed into engines that run them > > shame on us as computer scientists that > we dont use such techniques on a daily basis for > well-found engineering instead of the handwaving that passes > for communications work still in the 21st century > > it is a technical AND ethical goal to make it so > and should be a duty on all of us to get the law to recognize it > > That's a plausible point of view. I heartily disagree, however. In 1974 or so, our research group (Saltzer, Clark, Reed, Liskov, Svobodova, as I recall) decided that a *crucial* aspect of distributed systems was that they exhibited "autonomy", which implies a serious notion of loose coupling, flexibility, revisability, etc. That set of attributes are crucial, leaving them out for the sake of formal methods is just another Procrustean bed, where they are the Feet. *Protocols* are techniques for achieving communications in the face of uncertainty about who is on the other side of the network. Not just an unreliable network in the middle, but an uncertainty in a very fundamental sense about what is on the other side. In "distributed systems" that must function in the real world, a core and *essential* concept is that one must specify parts of the system to work "right" EVEN IF THE DEFINITION OF RIGHT CANNOT BE WELL-DEFINED MATHEMATICALLY. To someone who speaks English as a protocol, this is obvious. I can try to convince you, for example, by the words above that I am right. And I am using English correctly, and this can be verified. But it has nothing to do whatsoever with being able to prove that you *will* agree with me at the end of the conversation. Maybe it will take more conversations, maybe not. But a protocol is not an algorithm executed by a complete set of formal machines, though some protocols (a small subset might be in that category). That is a sad, little boring and utlimately trivial subset of the "protocols" of the world. Maybe it makes small-minded mathematicians happy because they can close off a "formal system" and prove theorems, as if proving theorems is the desired endpoint of system design. But the ability to prove theorems is not the test of a *useful* protocol set - neither of engineering value, nor of human value. The ability to communicate (which cannot be formalized in any way I know) is the correct test. The Internet is one example of a system that succeeds in communicating, and there really was NOT a need to define a formal specification of a collection of machines to achieve that result. From Jon.Crowcroft at cl.cam.ac.uk Fri Jan 4 05:51:12 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 04 Jan 2008 13:51:12 +0000 Subject: [e2e] patents on routing algorithms In-Reply-To: <477E37CF.5010707@reed.com> References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> <477D6109.9020701@reed.com> <477E37CF.5010707@reed.com> Message-ID: why do you think a loose coupled system cannot be described mathematically? clearly I can describe the code at each end of a protocol, and the channel, and at least derive theorems about how these combine. just because i dont over determine thigns doesn't mean that there isnt a precise mathematical description - it just means that there are non deterministic (external) events....thats been smething that process algebras have addressed since CCS, CSP, Lotos etc etc...even though those systems were somewhat unwieldy many processor designs today are specified - but a ot of asynch circuit design has to be underdetermined....that doesnt mean it isnt amenable to math (code/algorithmic) description. you're starting to sound like Richard Dawkin's who seems to think that human consciousness is not amanable to emulation by machine because of quantum mechaninics....an even great heresy description doesn't mean 100% prediction...:) In missive <477E37CF.5010707 at reed.com>, "David P. Reed" typed: >>Jon Crowcroft wrote: >>> it is a goal of much recent work (see Sewell et al in sigcomm 05 >>> "Rigorous specification and conformance testing techniques for network protocols, >>> as applied to TCP, UDP, and sockets" >>> and various papers >>> by Griffin and Sobrinho on Metarouting) >>> to render protocols merely >>> algorithmic specifications that are fed into engines that run them >>> >>> shame on us as computer scientists that >>> we dont use such techniques on a daily basis for >>> well-found engineering instead of the handwaving that passes >>> for communications work still in the 21st century >>> >>> it is a technical AND ethical goal to make it so >>> and should be a duty on all of us to get the law to recognize it >>> >>> >>That's a plausible point of view. I heartily disagree, however. In >>1974 or so, our research group (Saltzer, Clark, Reed, Liskov, Svobodova, >>as I recall) decided that a *crucial* aspect of distributed systems was >>that they exhibited "autonomy", which implies a serious notion of loose >>coupling, flexibility, revisability, etc. That set of attributes are >>crucial, leaving them out for the sake of formal methods is just another >>Procrustean bed, where they are the Feet. >> >>*Protocols* are techniques for achieving communications in the face of >>uncertainty about who is on the other side of the network. Not just an >>unreliable network in the middle, but an uncertainty in a very >>fundamental sense about what is on the other side. >> >>In "distributed systems" that must function in the real world, a core >>and *essential* concept is that one must specify parts of the system to >>work "right" EVEN IF THE DEFINITION OF RIGHT CANNOT BE WELL-DEFINED >>MATHEMATICALLY. >> >>To someone who speaks English as a protocol, this is obvious. I can >>try to convince you, for example, by the words above that I am right. >>And I am using English correctly, and this can be verified. But it has >>nothing to do whatsoever with being able to prove that you *will* agree >>with me at the end of the conversation. Maybe it will take more conversations, maybe not. >> >>But a protocol is not an algorithm executed by a complete set of formal >>machines, though some protocols (a small subset might be in that >>category). That is a sad, little boring and utlimately trivial subset >>of the "protocols" of the world. Maybe it makes small-minded >>mathematicians happy because they can close off a "formal system" and >>prove theorems, as if proving theorems is the desired endpoint of system >>design. But the ability to prove theorems is not the test of a >>*useful* protocol set - neither of engineering value, nor of human >>value. The ability to communicate (which cannot be formalized in any >>way I know) is the correct test. The Internet is one example of a >>system that succeeds in communicating, and there really was NOT a need >>to define a formal specification of a collection of machines to achieve >>that result. >> >> cheers jon From touch at ISI.EDU Fri Jan 4 07:53:27 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 07:53:27 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> Message-ID: <477E5677.6010808@isi.edu> Ian McDonald wrote: > On Jan 4, 2008 6:36 PM, Joe Touch wrote: >> It's great that Linux has variants of TCP that users can enable. It's >> irresponsible and/or sloppy to enable those experiments by default. >> > If that is your opinion then go argue your case on > netdev at vger.kernel.org. There are others in the IETF preparing lists of such misuse of experimental protocols and who have indicate they are already doing so, FWIW. > I don't necessarily disagree but this is the > area to debate it, not on this list (if you want change that is). It was raised on this list for other reasons, not to effect change. > I'm > not aware of many Linux developers listening to this list. People > there DO listen to good points so it is worth discussing there. FWIW, if they DO listen to good points, why isn't the mere fact that these protocols are Experimental not a sufficient point? If they're going to play with fire, they ought to seek out their own fire training IMO, not expect others to keep bailing them out when the get burned. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/a3ecef29/signature.bin From L.Wood at surrey.ac.uk Fri Jan 4 09:12:59 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Fri, 04 Jan 2008 17:12:59 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477E5677.6010808@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> Message-ID: <200801041713.RAA29230@cisco.com> At Friday 04/01/2008 07:53 -0800, Joe Touch wrote: >> I'm >> not aware of many Linux developers listening to this list. People >> there DO listen to good points so it is worth discussing there. > >FWIW, if they DO listen to good points, why isn't the mere fact that >these protocols are Experimental not a sufficient point? because linux development, like all development, is itself experimental in nature. The point about the difference between development and distribution has been made previously by Reed. (The problem of distinguishing between development and distribution only really occurs once you have a large userbase of non-developers. And doesn't the name Request For Comments itself sound experimental?) >If they're >going to play with fire, they ought to seek out their own fire training >IMO, not expect others to keep bailing them out when the get burned. Do you have examples of 'bailing out' to share? L. > It was raised on this list for other reasons, not to effect change From dpreed at reed.com Fri Jan 4 09:16:40 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Jan 2008 12:16:40 -0500 Subject: [e2e] patents on routing algorithms In-Reply-To: References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> <477D6109.9020701@reed.com> <477E37CF.5010707@reed.com> Message-ID: <477E69F8.5050106@reed.com> Jon Crowcroft wrote: > why do you think a loose coupled system cannot be described > mathematically? Perhaps it is an article of faith on my part. Dawkins claims that he takes nothing on faith - rejecting the concept of faith as non-mathematical, and therefore not scientifically real. I reject his views as self-contradictory, though I find them interesting and worthy of study. Of course there are many mathematicians (I think a minority, but a substantial one) who don't buy into Hilbert's pure formalism program, and further don't believe that the world must be formalizable in all aspects. I believe I am (to the extent I claim to be a mathematician) in that group. Bayesians tend to be in that group - you can be a Bayesian without expecting that there is a "ground truth" of ideals in the sense that Plato and his followers wished for. One can, of course, *define* a meaning for the term "loose coupling" as a mathematical property either as an axiom or by reduction to axiomatic elements of some formal system. But that definition, I personally suspect, will not be complete, in the sense of properly capturing the notion of a protocol of the sort that English, or Linear-B, or any other human mode of communication has. For example, we speak English and expect a wide variety of "systems" to change state in reasonably non-surprising ways that match our intention. > clearly I can describe the code at each end of a > protocol, and the channel, and at least derive theorems about how > these combine. just because i dont over determine thigns doesn't mean > that there isnt a precise mathematical description - it just means > that there are non deterministic (external) events....thats been > smething that process algebras have addressed since CCS, CSP, Lotos > etc etc...even though those systems were somewhat unwieldy > Process algebras start with assertions and definitions. That makes them useful tools, but it does not make them true. > many processor designs today are specified - but a ot of asynch > circuit design has to be underdetermined....that doesnt mean it isnt > amenable to math (code/algorithmic) description. > > you're starting to sound like Richard Dawkin's who seems to think that > human consciousness is not amanable to emulation by machine because > of quantum mechaninics....an even great heresy > > description doesn't mean 100% prediction...:) > > In missive <477E37CF.5010707 at reed.com>, "David P. Reed" typed: > > >>Jon Crowcroft wrote: > >>> it is a goal of much recent work (see Sewell et al in sigcomm 05 > >>> "Rigorous specification and conformance testing techniques for network protocols, > >>> as applied to TCP, UDP, and sockets" > >>> and various papers > >>> by Griffin and Sobrinho on Metarouting) > >>> to render protocols merely > >>> algorithmic specifications that are fed into engines that run them > >>> > >>> shame on us as computer scientists that > >>> we dont use such techniques on a daily basis for > >>> well-found engineering instead of the handwaving that passes > >>> for communications work still in the 21st century > >>> > >>> it is a technical AND ethical goal to make it so > >>> and should be a duty on all of us to get the law to recognize it > >>> > >>> > >>That's a plausible point of view. I heartily disagree, however. In > >>1974 or so, our research group (Saltzer, Clark, Reed, Liskov, Svobodova, > >>as I recall) decided that a *crucial* aspect of distributed systems was > >>that they exhibited "autonomy", which implies a serious notion of loose > >>coupling, flexibility, revisability, etc. That set of attributes are > >>crucial, leaving them out for the sake of formal methods is just another > >>Procrustean bed, where they are the Feet. > >> > >>*Protocols* are techniques for achieving communications in the face of > >>uncertainty about who is on the other side of the network. Not just an > >>unreliable network in the middle, but an uncertainty in a very > >>fundamental sense about what is on the other side. > >> > >>In "distributed systems" that must function in the real world, a core > >>and *essential* concept is that one must specify parts of the system to > >>work "right" EVEN IF THE DEFINITION OF RIGHT CANNOT BE WELL-DEFINED > >>MATHEMATICALLY. > >> > >>To someone who speaks English as a protocol, this is obvious. I can > >>try to convince you, for example, by the words above that I am right. > >>And I am using English correctly, and this can be verified. But it has > >>nothing to do whatsoever with being able to prove that you *will* agree > >>with me at the end of the conversation. Maybe it will take more > conversations, maybe not. > >> > >>But a protocol is not an algorithm executed by a complete set of formal > >>machines, though some protocols (a small subset might be in that > >>category). That is a sad, little boring and utlimately trivial subset > >>of the "protocols" of the world. Maybe it makes small-minded > >>mathematicians happy because they can close off a "formal system" and > >>prove theorems, as if proving theorems is the desired endpoint of system > >>design. But the ability to prove theorems is not the test of a > >>*useful* protocol set - neither of engineering value, nor of human > >>value. The ability to communicate (which cannot be formalized in any > >>way I know) is the correct test. The Internet is one example of a > >>system that succeeds in communicating, and there really was NOT a need > >>to define a formal specification of a collection of machines to achieve > >>that result. > >> > >> > > cheers > > jon > > > From L.Wood at surrey.ac.uk Fri Jan 4 09:46:54 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Fri, 04 Jan 2008 17:46:54 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477E6D30.1080905@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> Message-ID: <200801041747.RAA01412@cisco.com> At Friday 04/01/2008 09:30 -0800, Joe Touch wrote: >>> If they're >>> going to play with fire, they ought to seek out their own fire training >>> IMO, not expect others to keep bailing them out when the get burned. >> >> Do you have examples of 'bailing out' to share? > >IMO, fixing getting CUBIC out of default distros is one. I very much doubt that any Linux developers are expecting anyone to be 'bailing them out' here. Ditto for any Microsoft Compound TCP developers. L. From touch at ISI.EDU Fri Jan 4 09:30:24 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 09:30:24 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <200801041713.RAA29230@cisco.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> Message-ID: <477E6D30.1080905@isi.edu> Lloyd Wood wrote: > At Friday 04/01/2008 07:53 -0800, Joe Touch wrote: >>> I'm >>> not aware of many Linux developers listening to this list. People >>> there DO listen to good points so it is worth discussing there. >> FWIW, if they DO listen to good points, why isn't the mere fact that >> these protocols are Experimental not a sufficient point? > > because linux development, like all development, is itself experimental in nature. We're not talking about a variant that existed in someone's lab under controlled conditions. We're talking about public distributions. > The point about the difference between development and distribution > has been made previously by Reed. I'm talking about distros deploying experimental protocols in the wild. > (The problem of distinguishing between > development and distribution only really occurs once you have a large > userbase of non-developers. And doesn't the name Request For Comments > itself sound experimental?) Not when the label says "experiment" or "standards track" ;-) >> If they're >> going to play with fire, they ought to seek out their own fire training >> IMO, not expect others to keep bailing them out when the get burned. > > Do you have examples of 'bailing out' to share? IMO, fixing getting CUBIC out of default distros is one. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/e73f2c0f/signature.bin From touch at ISI.EDU Fri Jan 4 10:03:15 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 10:03:15 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <200801041747.RAA01412@cisco.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <200801041747.RAA01412@cisco.com> Message-ID: <477E74E3.3050501@isi.edu> Lloyd Wood wrote: > At Friday 04/01/2008 09:30 -0800, Joe Touch wrote: > >>>> If they're >>>> going to play with fire, they ought to seek out their own fire training >>>> IMO, not expect others to keep bailing them out when the get burned. >>> Do you have examples of 'bailing out' to share? >> IMO, fixing getting CUBIC out of default distros is one. > > I very much doubt that any Linux developers are expecting anyone to > be 'bailing them out' here. Ditto for any Microsoft Compound TCP > developers. That, perhaps, is part of the problem. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/24275fa4/signature.bin From dpreed at reed.com Fri Jan 4 12:27:30 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Jan 2008 15:27:30 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477E6D30.1080905@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> Message-ID: <477E96B2.3000600@reed.com> CUBIC is enabled in Fedora 8. However Fedora 8 is an experimental distribution, at least it is not viewed as "supported" by RedHat or any other vendor. Has the IETF become the protocol police? I do recall suggesting that the non-standard protocol called NAT was shipped by commercial companies like Microsoft and some "home router" hardware vendors while I was personally screaming and yelling about its non-standards track status. And those companies had the balls to say that because there was an RFC, it was a "standard" in their advertising. IETF refused to get its lawyers to sue the vendors who claimed the *lie* that NAT was a standard. I am not sure that gives it the standing to bar use of "experimental" software on the public Internet. Joe Touch wrote: > Lloyd Wood wrote: > >> At Friday 04/01/2008 07:53 -0800, Joe Touch wrote: >> >>>> I'm >>>> not aware of many Linux developers listening to this list. People >>>> there DO listen to good points so it is worth discussing there. >>>> >>> FWIW, if they DO listen to good points, why isn't the mere fact that >>> these protocols are Experimental not a sufficient point? >>> >> because linux development, like all development, is itself experimental in nature. >> > > We're not talking about a variant that existed in someone's lab under > controlled conditions. We're talking about public distributions. > > >> The point about the difference between development and distribution >> has been made previously by Reed. >> > > I'm talking about distros deploying experimental protocols in the wild. > > >> (The problem of distinguishing between >> development and distribution only really occurs once you have a large >> userbase of non-developers. And doesn't the name Request For Comments >> itself sound experimental?) >> > > Not when the label says "experiment" or "standards track" ;-) > > >>> If they're >>> going to play with fire, they ought to seek out their own fire training >>> IMO, not expect others to keep bailing them out when the get burned. >>> >> Do you have examples of 'bailing out' to share? >> > > IMO, fixing getting CUBIC out of default distros is one. > > Joe > > From dpreed at reed.com Fri Jan 4 12:43:21 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Jan 2008 15:43:21 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477E74E3.3050501@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <200801041747.RAA01412@cisco.com> <477E74E3.3050501@isi.edu> Message-ID: <477E9A69.5030705@reed.com> Joe Touch wrote: >> I very much doubt that any Linux developers are expecting anyone to >> be 'bailing them out' here. Ditto for any Microsoft Compound TCP >> developers. >> > > That, perhaps, is part of the problem. > > Is there a Security Hole if CUBIC is used? Should I be really scared? Will I bring down the entire Internet? If I'm willing to take a risk myself (running Fedora is a moderate risk, like opening up the case on your PC and installing a new memory card) why should anyone worry about me needing to be bailed out? I'm honestly curious. Since I build my own kernels every day, I could just turn CUBIC off. But I figure that exercising it a bit in the *real* world is probably good. Is that any different than running CUBIC between PlanetLab nodes and users on PCs in academic computer networking research labs? From touch at ISI.EDU Fri Jan 4 14:10:06 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 14:10:06 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477E96B2.3000600@reed.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> Message-ID: <477EAEBE.9080906@isi.edu> David P. Reed wrote: > CUBIC is enabled in Fedora 8. However Fedora 8 is an experimental > distribution, at least it is not viewed as "supported" by RedHat or any > other vendor. > > Has the IETF become the protocol police? The IETF has not; members of the IETF have taken the task on, though. ... > I am not sure that gives it the standing to bar use of "experimental" > software on the public Internet. It's not a matter of barring it per se; it's a matter of not enabling something by default that isn't explicitly intended to be an experiment. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/9c27c56a/signature.bin From touch at ISI.EDU Fri Jan 4 14:10:00 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 14:10:00 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477E9A69.5030705@reed.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <200801041747.RAA01412@cisco.com> <477E74E3.3050501@isi.edu> <477E9A69.5030705@reed.com> Message-ID: <477EAEB8.2070207@isi.edu> David P. Reed wrote: > > > Joe Touch wrote: >>> I very much doubt that any Linux developers are expecting anyone to >>> be 'bailing them out' here. Ditto for any Microsoft Compound TCP >>> developers. >>> >> >> That, perhaps, is part of the problem. > > Is there a Security Hole if CUBIC is used? Should I be really scared? > Will I bring down the entire Internet? Nobody knows. Again, that's why controlled testing would have been useful, rather than widescale deployment. > If I'm willing to take a risk > myself (running Fedora is a moderate risk, like opening up the case on > your PC and installing a new memory card) why should anyone worry about > me needing to be bailed out? There are concerns about its fairness: http://www.postel.org/pipermail/end2end-interest/2006-October/006327.html http://www.hamilton.ie/net/pfldnet2007_cubic_final.pdf There is a rebuttal as well: http://www4.ncsu.edu/~rhee/Rebuttal-LSM-new.pdf The jury is out as to whether this is safe to deploy, AFAICT. > I'm honestly curious. Since I build my own kernels every day, I could > just turn CUBIC off. But I figure that exercising it a bit in the > *real* world is probably good. This sounds a lot like you're interested in participating in an experiment where you don't know the impact. Does that seem like a good idea to you? > Is that any different than running CUBIC between PlanetLab nodes and > users on PCs in academic computer networking research labs? Those users knew they were running experiments, and knew when they were over. Deploying CUBIC in public distributions lets the experiment out into thw wild, and is no longer a controlled, voluntary participation experiment. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/b0eb499b/signature.bin From huitema at windows.microsoft.com Fri Jan 4 15:15:49 2008 From: huitema at windows.microsoft.com (Christian Huitema) Date: Fri, 4 Jan 2008 15:15:49 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EAEBE.9080906@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> Message-ID: > > Has the IETF become the protocol police? > > The IETF has not; members of the IETF have taken the task on, though. Well, who made you king? This is in fact a serious question, that goes well beyond the present discussion of CUBIC, or CTCP. I certainly respect the engineering talent of the people on this list, but we are speaking here of allowing or not some products to run on the Internet. I understand the feeling that improper use of some software might "harm the Internet". But where do we draw the line? Shall we ban Kazaa? BitTorrent? Skype? Video streaming over UDP? VoIP? Who draws that line? What are the checks and balances? Assuming that we can agree on who is the judge, who is the police? If there is a ban, how is that ban enforced? Do we rely on ISP to deploy some kind of firewalls? Do we ask the police to raid people's home and check that they are not using forbidden software? Do ask the department of commerce to ban the sale of some products? -- Christian Huitema From touch at ISI.EDU Fri Jan 4 15:25:21 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 15:25:21 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> Message-ID: <477EC061.4080101@isi.edu> Christian Huitema wrote: >>> Has the IETF become the protocol police? >> The IETF has not; members of the IETF have taken the task on, though. > > Well, who made you king? One question is whether they were enabled to deliberately explore an experimental protocol in a widely-deployed public distribution, or whether they were enabled without that understanding. Another question is whether Linux users should know when they are part of such an experiment or not. If Linux doesn't tell users and/or didn't know this was experimental, then maybe they should. Whether they will or not, maybe the IETFers will put up notices that educate users as to when they've been drafted as unwitting experimenters. That's the mechanism for feedback. The other is simply not using systems that make such decisions, which is where I stand. We're not king or judge or jury, but we are the 4th estate in this process. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/c6df13e2/signature.bin From huitema at windows.microsoft.com Fri Jan 4 15:43:39 2008 From: huitema at windows.microsoft.com (Christian Huitema) Date: Fri, 4 Jan 2008 15:43:39 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EC061.4080101@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> Message-ID: > Christian Huitema wrote: > >>> Has the IETF become the protocol police? > >> The IETF has not; members of the IETF have taken the task on, > though. > > > > Well, who made you king? > > One question is whether they were enabled to deliberately explore an > experimental protocol in a widely-deployed public distribution, or > whether they were enabled without that understanding. But who decides whether a protocol is experimental, or good enough for production use? -- Christian Huitema From touch at ISI.EDU Fri Jan 4 15:50:53 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 15:50:53 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> Message-ID: <477EC65D.1010606@isi.edu> Christian Huitema wrote: >> Christian Huitema wrote: >>>>> Has the IETF become the protocol police? >>>> The IETF has not; members of the IETF have taken the task on, >> though. >>> Well, who made you king? >> One question is whether they were enabled to deliberately explore an >> experimental protocol in a widely-deployed public distribution, or >> whether they were enabled without that understanding. > > But who decides whether a protocol is experimental, or good enough for production use? That's supposed to happen in the IETF. The protocol in question is being purported as experimental, not optional standards-track. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/59162a89/signature-0001.bin From gds at best.com Fri Jan 4 16:18:01 2008 From: gds at best.com (Greg Skinner) Date: Sat, 5 Jan 2008 00:18:01 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EC061.4080101@isi.edu>; from touch@ISI.EDU on Fri, Jan 04, 2008 at 03:25:21PM -0800 References: <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> Message-ID: <20080105001801.A88664@gds.best.vwh.net> On Fri, Jan 04, 2008 at 03:25:21PM -0800, Joe Touch wrote: > One question is whether they were enabled to deliberately explore an > experimental protocol in a widely-deployed public distribution, or > whether they were enabled without that understanding. > > Another question is whether Linux users should know when they are part > of such an experiment or not. > > If Linux doesn't tell users and/or didn't know this was experimental, > then maybe they should. Whether they will or not, maybe the IETFers will > put up notices that educate users as to when they've been drafted as > unwitting experimenters. Perhaps the folks in charge of creating these Linux distributions feel the "standard disclaimer" (the software is provided "as is" ...) justifies their release policies. --gregbo From slblake at petri-meat.com Fri Jan 4 16:45:41 2008 From: slblake at petri-meat.com (Steven Blake) Date: Fri, 04 Jan 2008 19:45:41 -0500 Subject: [e2e] patents on routing algorithms In-Reply-To: References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> <477D6109.9020701@reed.com> <477E37CF.5010707@reed.com> Message-ID: <1199493941.16877.56.camel@tachyon> On Fri, 2008-01-04 at 13:51 +0000, Jon Crowcroft wrote: > you're starting to sound like Richard Dawkin's who seems to think that > human consciousness is not amanable to emulation by machine because > of quantum mechaninics....an even great heresy > > description doesn't mean 100% prediction...:) Perhaps you mean Roger Penrose? http://en.wikipedia.org/wiki/The_Emperor%27s_New_Mind Regards, // Steve From huitema at windows.microsoft.com Fri Jan 4 16:44:44 2008 From: huitema at windows.microsoft.com (Christian Huitema) Date: Fri, 4 Jan 2008 16:44:44 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EC65D.1010606@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> Message-ID: > From: Joe Touch [mailto:touch at ISI.EDU] > Christian Huitema wrote: > >> Christian Huitema wrote: > >>>>> Has the IETF become the protocol police? > >>>> The IETF has not; members of the IETF have taken the task on, > >> though. > >>> Well, who made you king? > >> One question is whether they were enabled to deliberately explore an > >> experimental protocol in a widely-deployed public distribution, or > >> whether they were enabled without that understanding. > > > > But who decides whether a protocol is experimental, or good enough > for production use? > > That's supposed to happen in the IETF. The protocol in question is > being purported as experimental, not optional standards-track. But that means that the IETF would in practice be the judge of what can be deployed in the Internet. It could simply withdraw its stamp of approval and that the product would then, in theory, never be deployed. What if the developers are convinced that their spec is good, and the IETF is just being slow? Do you really expect that whoever needs the product will just wait forever? -- Christian Huitema From randy at psg.com Fri Jan 4 16:54:30 2008 From: randy at psg.com (Randy Bush) Date: Sat, 05 Jan 2008 09:54:30 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EC65D.1010606@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> Message-ID: <477ED546.6040005@psg.com> >> But who decides whether a protocol is experimental, or good enough >> for production use? > That's supposed to happen in the IETF. The protocol in question is > being purported as experimental, not optional standards-track. a protocol is experimental when someone is trying to convince us to try it and giving us the code to do so on common platform(s). (before then, it's just hot air) a protocol is production when customers want it and are willing to pay for at least the costs of deploying it. btw, what's "the IETF?" [0] randy --- [0] - http://rip.psg.com/~randy/051000.sigcomm-ivtf.pdf From dpreed at reed.com Fri Jan 4 18:23:31 2008 From: dpreed at reed.com (David P. Reed) Date: Fri, 04 Jan 2008 21:23:31 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477ED546.6040005@psg.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> Message-ID: <477EEA23.8070901@reed.com> So let me suggest that the nice thing about the Internet is that in general, the core of the network doesn't care about the details of the end-to-end protocols that users deploy in their machines. There is much anxiety about "congestion control" and "fairness", of course. But ultimately, the network , the IETF, and the access providers that provide the last 10 meters are not the arbiters of such things. (in fact, the point is that the end users collectively have much more knowledge about what they are trying to do than the network routers, owners, and standardizers ever can). Thus, the end users ultimately get involved in the definition of what's fair, once they've paid for the right to originate packets to each other. Yeah, if the end users decide to get in fights among themselves, they get into fights. It's simple as that. It's no different than Pakistan or Kenya today. If enough of the people decide that they want to have a civil war, the government is not going to stop them. Fortunately, people are generally sensible after a while. Companies like Microsoft and projects like Linux generally can help by not creating self-sustaining catastrophic protocol structures and disseminatng them. But generally they don't for long. Bluetooth and WiFi protocols were at risk of jamming each other. But realizing that that would not do anyone any good, they came up with a pragmatic set of ameliorations. Those were hardly "optimum", but in practice they worked well enough. If CUBIC turns out to be an actual nightmare, Linux has ways to distribute updates that ameliorate the problem. I doubt it will get that bad in practice - Linux users are still pretty thin, and they do tend to download and apply patches much more rapidly than any other class of system users on the planet. Randy Bush wrote: >>> But who decides whether a protocol is experimental, or good enough >>> for production use? >> That's supposed to happen in the IETF. The protocol in question is >> being purported as experimental, not optional standards-track. > > a protocol is experimental when someone is trying to convince us to > try it and giving us the code to do so on common platform(s). (before > then, it's just hot air) > > a protocol is production when customers want it and are willing to pay > for at least the costs of deploying it. > > btw, what's "the IETF?" [0] > > randy > > --- > > [0] - http://rip.psg.com/~randy/051000.sigcomm-ivtf.pdf > From randy at psg.com Fri Jan 4 18:33:57 2008 From: randy at psg.com (Randy Bush) Date: Sat, 05 Jan 2008 11:33:57 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EEA23.8070901@reed.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> Message-ID: <477EEC95.8050905@psg.com> generally agree except for two points > So let me suggest that the nice thing about the Internet is that in > general, the core of the network doesn't care about the details of the > end-to-end protocols that users deploy in their machines. > > There is much anxiety about "congestion control" and "fairness", of > course. But ultimately, the network , the IETF, and the access > providers that provide the last 10 meters are not the arbiters of such > things. (in fact, the point is that the end users collectively have much > more knowledge about what they are trying to do than the network > routers, owners, and standardizers ever can). Thus, the end users > ultimately get involved in the definition of what's fair, once they've > paid for the right to originate packets to each other. > > Yeah, if the end users decide to get in fights among themselves, they > get into fights. It's simple as that. It's no different than Pakistan > or Kenya today. If enough of the people decide that they want to have > a civil war, the government is not going to stop them. given that people are being murdered, i do not look at kenya, pakistan, iraq, ... as positive examples. > Fortunately, people are generally sensible after a while. Companies > like Microsoft and projects like Linux generally can help by not > creating self-sustaining catastrophic protocol structures and > disseminatng them. But generally they don't for long. as someone trying to get microsoft to fix their seriously show-stopping bug that winxp with v6 turned on refuses to use v6 for dns transport, this is not one of my more optimistic days on this front. "buy vista" my ass; we have O(10^6) winxp customer users out there. > Bluetooth and WiFi protocols were at risk of jamming each other. But > realizing that that would not do anyone any good, they came up with a > pragmatic set of ameliorations. Those were hardly "optimum", but in > practice they worked well enough. > > If CUBIC turns out to be an actual nightmare, Linux has ways to > distribute updates that ameliorate the problem. I doubt it will get > that bad in practice - Linux users are still pretty thin, and they do > tend to download and apply patches much more rapidly than any other > class of system users on the planet. randy From rhee at ncsu.edu Fri Jan 4 19:37:45 2008 From: rhee at ncsu.edu (Injong Rhee) Date: Sat, 5 Jan 2008 12:37:45 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EEA23.8070901@reed.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> Message-ID: <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> On Jan 5, 2008, at 11:23 AM, David P. Reed wrote: > > > If CUBIC turns out to be an actual nightmare, Linux has ways to > distribute updates that ameliorate the problem. I doubt it will > get that bad in practice - Linux users are still pretty thin, and > they do tend to download and apply patches much more rapidly than > any other class of system users on the planet. > > > Over 40% of Internet servers in the world are Linux-based. So the users may be thin, but my guess is that a significant share of Internet traffic is from Linux, and also from CUBIC these days. Note that much portion of these servers are P2P servers which are the main contributors of the Internet traffic. CUBIC/BIC has been enabled as the default for Linux for several years. I am not sure about the role of IETF at this stage even when the protocol is already out there and being used as a de facto standard that constitutes a major portion of the Internet traffic. What "bailing out" have IETF folks been performing for Linux-developers? I don't see the penalty that users, ISPs, academics and Mr. Joe next door have paid because of its use. I don't see the Internet is being crashed or crumbling down because of CUBIC. From touch at ISI.EDU Fri Jan 4 21:34:55 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 21:34:55 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> Message-ID: <477F16FF.9090405@isi.edu> Christian Huitema wrote: >> From: Joe Touch [mailto:touch at ISI.EDU] >> Christian Huitema wrote: >>>> Christian Huitema wrote: >>>>>>> Has the IETF become the protocol police? >>>>>> The IETF has not; members of the IETF have taken the task on, >>>> though. >>>>> Well, who made you king? >>>> One question is whether they were enabled to deliberately explore an >>>> experimental protocol in a widely-deployed public distribution, or >>>> whether they were enabled without that understanding. >>> But who decides whether a protocol is experimental, or good enough >> for production use? >> >> That's supposed to happen in the IETF. The protocol in question is >> being purported as experimental, not optional standards-track. > > But that means that the IETF would in practice be the judge of what > can be deployed in the Internet. In this case, it means that the people who came up with CUBIC consider it experimental. It's not like the IETF stamped that on *their* Internet Draft. You raise interesting questions in the general case, and yes, it's the standards community that defines the standards. Who else would? > What if the developers are convinced that their spec is good, and the > IETF is just being slow? Do you really expect that whoever needs the > product will just wait forever? There are plenty of protocols that never went through the IETF, or went through as Informational because they didn't *ask* to be standardized. Again, that's an interesting academic question, but not relevant to protocols that actually ask to be experimental by the developers. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/a0844fde/signature-0001.bin From touch at ISI.EDU Fri Jan 4 21:42:49 2008 From: touch at ISI.EDU (Joe Touch) Date: Fri, 04 Jan 2008 21:42:49 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> Message-ID: <477F18D9.30106@isi.edu> Injong Rhee wrote: ... > I don't see the > penalty that users, ISPs, academics and Mr. Joe next door have paid > because of its use. I don't see the Internet is being crashed or > crumbling down because of CUBIC. You don't see it because nobody is measuring it or even looking for it. Deploying a protocol and not seeing a problem isn't proof that it's not causing harm now, and it's not proof it won't cause harm in certain deployment scenarios. If "works most of the time for most people" were sufficient, we could pare the TCP state machine down by 1/3, and cut out all options including SACK. Yes, not causing harm right now is a start, but it's nowhere near the end. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080104/5395701e/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Sat Jan 5 01:45:00 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 05 Jan 2008 09:45:00 +0000 Subject: [e2e] patents on routing algorithms In-Reply-To: <1199493941.16877.56.camel@tachyon> References: <477C534D.3090206@reed.com> <477C7660.8020406@isi.edu> <477D55CF.5040704@isi.edu> <477D6109.9020701@reed.com> <477E37CF.5010707@reed.com> <1199493941.16877.56.camel@tachyon> Message-ID: oxford professors are very confusing - of course you are right - penrose was the chap and the emperors new mind the book - not anything to do with god, kings or ietf related patents or working code which might be a shared delusion In missive <1199493941.16877.56.camel at tachyon>, Steven Blake typed: >>On Fri, 2008-01-04 at 13:51 +0000, Jon Crowcroft wrote: >> >>> you're starting to sound like Richard Dawkin's who seems to think that >>> human consciousness is not amanable to emulation by machine because >>> of quantum mechaninics....an even great heresy >>> >>> description doesn't mean 100% prediction...:) >> >>Perhaps you mean Roger Penrose? >> >>http://en.wikipedia.org/wiki/The_Emperor%27s_New_Mind >> >> >>Regards, >> >>// Steve >> cheers jon From Jon.Crowcroft at cl.cam.ac.uk Sat Jan 5 01:55:08 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 05 Jan 2008 09:55:08 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> Message-ID: time was, there was an ecosystem made out of a bunch of identifiable pieces (researchers in labs in universities and companies, the irtf grousp, the acm sigcomm and related ieee comsoc groups, interop, and fringes, lots of small and large companies whose empployees implicitly understood that community) the community had no kings, but had a small number of visible touchstone pieces of code (whether bsd or linux or mit c code or later ones)... rough consensus in that community did two things... it allowed diversity (different implementations persisted in parallel, while evaluation happened) it allowed for convergence (when improvements were visible, they could be rapidly applied from publically visible implementations into provate ones - e..g bsd code ideas into solaris code, or linux code/ideas into router bgp tcp code just for examples)... the ietf might ratify it but it was largely irrelevent if it did or did not as it was really just recognizing that community... that time is gone - lots of reasons i) research engine behind the community is dead (moved on to other things ii) lots of the code aint visible (e.g. microsofts was invisible to lots of people, and linux code is invisible by lawyer dictat to lots of microsoft people - i'm not bashing microsoft - just pointing out that a large area of crossover is not mitigated through paper and text discussions, not through inspecting code that is operating). iii) after the mid 90s, a lot of people (yes, even academics) were more motivated by spinouts and startups than by working for the community, so competition rather than cooperation became the mode of play - this means that you dont often see free code releases of new ideas and you can't trust what thr authors' say about their code as they are prone to be exagerating the benefits and downplaying the negative sides, (yes, academics do this - its the most annoying feature of many internet-related papers in the last 10 years). one mistake we probably made was way back when (mid 90s) we discussed mearging ietf, sigcomm and interop (in terms of co-lo events) like sigraph, so that practioners, theory and standards all would meet 1 per year in the same place (usually las vegas as thats the only place that seems to be able to host 50,000 people events with hi tech stuff to show off:) - on the other hand, perhaps it wouldn't have made a difference so now we have divergence, no consensus, and we don't even know how things work any more or when they dont work or why In missive , Christian Huitema typed: >>> > Has the IETF become the protocol police? >>> >>> The IETF has not; members of the IETF have taken the task on, though. >> >>Well, who made you king? >> >>This is in fact a serious question, that goes well beyond the present discussion of CUBIC, or CTCP. I certainly respect the engineering talent of the people on this list, but we are speaking here of allowing or not some products to run on the Internet. I understand the feeling that improper use of some software might "harm the Internet". But where do we draw the line? Shall we ban Kazaa? BitTorrent? Skype? Video streaming over UDP? VoIP? Who draws that line? What are the checks and balances? >> >>Assuming that we can agree on who is the judge, who is the police? If there is a ban, how is that ban enforced? Do we rely on ISP to deploy some kind of firewalls? Do we ask the police to raid people's home and check that they are not using forbidden software? Do ask the department of commerce to ban the sale of some products? >> >>-- Christian Huitema >> >> >> >> >> cheers jon From rhee at ncsu.edu Sat Jan 5 03:16:20 2008 From: rhee at ncsu.edu (Injong Rhee) Date: Sat, 5 Jan 2008 20:16:20 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477F18D9.30106@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> Message-ID: <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> On Jan 5, 2008, at 2:42 PM, Joe Touch wrote: > > > Injong Rhee wrote: > ... >> I don't see the >> penalty that users, ISPs, academics and Mr. Joe next door have paid >> because of its use. I don't see the Internet is being crashed or >> crumbling down because of CUBIC. > > You don't see it because nobody is measuring it or even looking for > it. > Deploying a protocol and not seeing a problem isn't proof that it's > not > causing harm now, and it's not proof it won't cause harm in certain > deployment scenarios. > > If "works most of the time for most people" were sufficient, we could > pare the TCP state machine down by 1/3, and cut out all options > including SACK. > > Yes, not causing harm right now is a start, but it's nowhere near > the end. > > Joe > Yes. There are no reported cases of harm in real production networks. Just yet. But if you have seen my work on the evaluation of CUBIC/BIC (http:// netsrv.csc.ncsu.edu/twiki/bin/view/Main/BIC#Experimental_Results), they are quite extensive. Our emulation involves routers, packet capturing, monitoring, etc., and they also involve extensive background traffic generations. They only stop short of testing in the real production networks - which i can't since the testing requires overloading the production networks. You might argue that our topology is not diverse enough, but well, i don't have funds/tech support to make it more diverse. I am not sure whether those *IETF standard* TCP algorithms were tested as extensively as CUBIC/BIC. I doubt that the process taken at that time were as much rigorous as we are with CUBIC/BIC. I am not sure either whether it is the job of IETF to prove it is safe and harmless-- how do they know? When those "standard" algorithms are IETF standardized, had they more evaluation than CUBIC/BIC? At best, they had ns-2 simulation. Back then there is no definition of realistic traffic patterns. I agree that our tests may not be enough to satisfy the IETF champions, but what is enough and how do they know without muddling their hands with testing? From Michael.Welzl at uibk.ac.at Sat Jan 5 03:59:45 2008 From: Michael.Welzl at uibk.ac.at (Michael Welzl) Date: Sat, 5 Jan 2008 12:59:45 +0100 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477F18D9.30106@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> Message-ID: <1199534385.477f7131ef502@web-mail1.uibk.ac.at> > Joe Touch wrote: > > Injong Rhee wrote: > ... > > I don't see the > > penalty that users, ISPs, academics and Mr. Joe next door have paid > > because of its use. I don't see the Internet is being crashed or > > crumbling down because of CUBIC. > > You don't see it because nobody is measuring it or even looking for it. > Deploying a protocol and not seeing a problem isn't proof that it's not > causing harm now, and it's not proof it won't cause harm in certain > deployment scenarios. > > If "works most of the time for most people" were sufficient, we could > pare the TCP state machine down by 1/3, and cut out all options > including SACK. > > Yes, not causing harm right now is a start, but it's nowhere near the end. Indeed - and I'd like to connect this with the question that David asked previously: > Is that [using it in one's home system] any different > than running CUBIC between PlanetLab nodes and users > on PCs in academic computer networking research labs? Yes it probably is, but in both cases, it's not a very reasonable experiment. Case 1, your home: probably your access link will be the bottleneck, and the window will not be very large. In this situation, the difference between CUBIC and TCP will not be very significant because CUBIC is designed to behave like TCP in environments where the BDP or at least the RTT are small. If I'm wrong about the bottleneck in your home, it's the same as case 2 below... Case 2, PlanetLab: We sent TCP traffic to PlanetLab nodes from a Linux system with a Web 100 kernel and found that, even with standard TCP, the limitation is almost always from the receiver window. To conclude, IMO, we can't regard the use of CUBIC in Linux as a proper wide-scale experiment due to the lack of support and use of window scaling in the Internet. I know we discussed this point in the past, but really, I think that this is much more of an issue than everything else when we talk about TCP. After all, who cares whether end systems use Compound TCP, CUBIC or BIC, when all these systems are fair towards TCP by design when windows are small, and in fact windows never really get to be large? Then again, I don't know how to solve the problem. One possibility might be mapping a single TCP flow onto multiple TCPs (because the rwnd limit is per-flow) and dynamically switch between them... but I think that this doesn't make a lot of sense in the light of the underlying effort-vs-ugliness tradeoff. Cheers, Michael From touch at ISI.EDU Sat Jan 5 08:51:55 2008 From: touch at ISI.EDU (Joe Touch) Date: Sat, 05 Jan 2008 08:51:55 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> Message-ID: <477FB5AB.3090601@isi.edu> Injong Rhee wrote: >... >> Yes, not causing harm right now is a start, but it's nowhere near the >> end. >> >> Joe > > Yes. There are no reported cases of harm in real production networks. > Just yet. > > But if you have seen my work on the evaluation of CUBIC/BIC > (http://netsrv.csc.ncsu.edu/twiki/bin/view/Main/BIC#Experimental_Results), > they are quite extensive. I have also seen the cited reports of problems with CUBIC/BIC. ... > I am not sure whether those *IETF standard* TCP algorithms were tested > as extensively as CUBIC/BIC. Certainly. But the key is whether we need a new algorithm, whether there is a benefit, and whether the benefit warrants the risks. That may all have been proven sufficiently for a wide-scale test with volunteers aware that they're participating, but I don't like the idea of releasing this to unwitting users without making it clear they're part of such an experiment. IMO, the widescale volunteer test is the step that has been skipped here. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080105/a5ed3a3d/signature.bin From Jon.Crowcroft at cl.cam.ac.uk Sat Jan 5 09:36:11 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 05 Jan 2008 17:36:11 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477FB5AB.3090601@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> Message-ID: there were interesting discussions about the bittyrant work last year where a new torrent client was released and used to do experiments....informed consent from users was sort of fine printed somewhat:) on the other hand, if you want a proper control group and a distributed congestion control or any other resource manager scheme includes an element of user behaviour, then you haev a problem conducting science without having uninformed as well as informed users (and non users...) In missive <477FB5AB.3090601 at isi.edu>, Joe Touch typed: >>Certainly. But the key is whether we need a new algorithm, whether there >>is a benefit, and whether the benefit warrants the risks. That may all >>have been proven sufficiently for a wide-scale test with volunteers >>aware that they're participating, but I don't like the idea of releasing >>this to unwitting users without making it clear they're part of such an >>experiment. IMO, the widescale volunteer test is the step that has been >>skipped here. >> >>Joe >> >> >>--------------enig8E1133BA9230959A203A9B5E >>Content-Type: application/pgp-signature; name="signature.asc" >>Content-Description: OpenPGP digital signature >>Content-Disposition: attachment; filename="signature.asc" >> >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.7 (MingW32) >>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >>iD8DBQFHf7WsE5f5cImnZrsRAqtQAKDUWpkUF2pIQKs2S+UFQdR51GIKzQCeOSUu >>+VjslEfW6K4LFYUZytnSiBg= >>=ldzH >>-----END PGP SIGNATURE----- >> >>--------------enig8E1133BA9230959A203A9B5E-- cheers jon From rhee at ncsu.edu Sat Jan 5 16:36:16 2008 From: rhee at ncsu.edu (Injong Rhee) Date: Sun, 6 Jan 2008 09:36:16 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477FB5AB.3090601@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> Message-ID: There have been a lot of discussions even in this mailing list on why tcp-newreno fails in certain cases -- i don't want to go through that discussion again. I agree that the process could have been more diplomatic and it could have been improved. However, what's done is done. Wide-scale tests in some sense have been done for three to four years, as you said, unknowingly. If you don't trust that as a test, I am puzzled on what kind of wide-scale tests (with volunteers) we can do without causing disruption on the production networks. Could you suggest the kind of wide-scale tests we can do with proper measurement and real users involved in real Internet and without causing disruption? It seems almost unrealistic. Besides, were the same types of tests performed before their release of IETF TCPs? was it less disruptive then than now to introduce new algorithms without proper wide-scale tests? Injong On Jan 6, 2008, at 1:51 AM, Joe Touch wrote: > > Certainly. But the key is whether we need a new algorithm, whether > there > is a benefit, and whether the benefit warrants the risks. That may all > have been proven sufficiently for a wide-scale test with volunteers > aware that they're participating, but I don't like the idea of > releasing > this to unwitting users without making it clear they're part of > such an > experiment. IMO, the widescale volunteer test is the step that has > been > skipped here. > > Joe > From rhee at ncsu.edu Sat Jan 5 16:40:08 2008 From: rhee at ncsu.edu (Injong Rhee) Date: Sun, 6 Jan 2008 09:40:08 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> Message-ID: <20ED0D78-51ED-4D34-A4FB-4225B6A2C723@ncsu.edu> Good points! It is always difficult, if not impossible, to inform the entire users in the Internet in this regard because the Internet is shared. If you do this in an isolated networks only involving consent users, then the test may not be wide-scale enough or realistic. Injong On Jan 6, 2008, at 2:36 AM, Jon Crowcroft wrote: > there were interesting discussions about the bittyrant work last > year where a new > torrent client was released and used to do experiments....informed > consent from > users was sort of fine printed somewhat:) > > on the other hand, if you want a proper control group and a > distributed > congestion control or any other resource manager > scheme includes an element of user behaviour, then you haev a > problem conducting > science without having uninformed as well as informed users (and > non users...) > > In missive <477FB5AB.3090601 at isi.edu>, Joe Touch typed: > >>> Certainly. But the key is whether we need a new algorithm, >>> whether there >>> is a benefit, and whether the benefit warrants the risks. That >>> may all >>> have been proven sufficiently for a wide-scale test with volunteers >>> aware that they're participating, but I don't like the idea of >>> releasing >>> this to unwitting users without making it clear they're part of >>> such an >>> experiment. IMO, the widescale volunteer test is the step that >>> has been >>> skipped here. >>> >>> Joe >>> >>> >>> --------------enig8E1133BA9230959A203A9B5E >>> Content-Type: application/pgp-signature; name="signature.asc" >>> Content-Description: OpenPGP digital signature >>> Content-Disposition: attachment; filename="signature.asc" >>> >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.7 (MingW32) >>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>> >>> iD8DBQFHf7WsE5f5cImnZrsRAqtQAKDUWpkUF2pIQKs2S+UFQdR51GIKzQCeOSUu >>> +VjslEfW6K4LFYUZytnSiBg= >>> =ldzH >>> -----END PGP SIGNATURE----- >>> >>> --------------enig8E1133BA9230959A203A9B5E-- > > cheers > > jon > From rhee at ncsu.edu Sat Jan 5 16:51:32 2008 From: rhee at ncsu.edu (Injong Rhee) Date: Sun, 6 Jan 2008 09:51:32 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477FB5AB.3090601@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> Message-ID: <2FA84A86-D8C8-40B2-A5C0-972F256C4C7C@ncsu.edu> > > I have also seen the cited reports of problems with CUBIC/BIC. >> Sure. But I want folks to look at the tests and the reports carefully or even try them by themselves. I am sure you will know it works! But i see the attitude of people who are mad just because its default release in Linux rather than trying to understand it technically first. I am working on a congestion control public testbed where people can try for themselves without investing too much time if they do care and we are also working with a number of people (e.g., TMRG) to agree on benchmark test suites. Injong From touch at ISI.EDU Sat Jan 5 21:17:09 2008 From: touch at ISI.EDU (Joe Touch) Date: Sat, 05 Jan 2008 21:17:09 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> Message-ID: <47806455.8040508@isi.edu> Injong Rhee wrote: ... > I agree that the process could have been more diplomatic and it could > have been improved. However, what's done is done. Wide-scale tests in > some sense have been done for three to four years, as you said, > unknowingly. If you don't trust that as a test, I am puzzled on what > kind of wide-scale tests (with volunteers) we can do without causing > disruption on the production networks. For all you know there have been problems - either failure to provide benefit (which is otherwise harmless), or real problems - which you haven't bothered to detect or collect statistics on. Closing your eyes when you run an experiment doesn't declare it a success. > Could you suggest the kind of wide-scale tests we can do with proper > measurement and real users involved in real Internet and without causing > disruption? It seems almost unrealistic. Ask the same people at the IETF you did an end-run around by accepting Experimental status. > Besides, were the same types ofelow). > tests performed before their release of IETF TCPs? There was quite a bit of testing and peer review. If you really want to find out what everyone on this list thinks of how this evolved, why don't you tell them what you told me in a private email about why you chose experimental track rather than standards track. The rest of us have the guts to go through peer review when we muck with standards. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080105/32ada10f/signature.bin From touch at ISI.EDU Sat Jan 5 21:21:33 2008 From: touch at ISI.EDU (Joe Touch) Date: Sat, 05 Jan 2008 21:21:33 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <2FA84A86-D8C8-40B2-A5C0-972F256C4C7C@ncsu.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> <2FA84A86-D8C8-40B2-A5C0-972F256C4C7C@ncsu.edu> Message-ID: <4780655D.30009@isi.edu> Injong Rhee wrote: > >> >> I have also seen the cited reports of problems with CUBIC/BIC. >>> > > Sure. But I want folks to look at the tests and the reports carefully or > even try them by themselves. I am sure you will know it works! But i see > the attitude of people who are mad just because its default release in > Linux rather than trying to understand it technically first. People like me are mad because they ended up part of your experiment before we had a chance to review your results, understand it technically, and decide in the contents of an IETF standards track discussion whether it was useful. That's the point of the IETF standards track. > I am working on a congestion control public testbed where people can try > for themselves without investing too much time if they do care and we > are also working with a number of people (e.g., TMRG) to agree on > benchmark test suites. Why announce it? Why not just silently deploy it in Linux, omit the measurements because they'd be disruptive, and then declare it all works in a few years? Seriously, I'm not against new protocols in general. I'm just not in favor of silent deployment of new protocols to the unaware. Joe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 250 bytes Desc: OpenPGP digital signature Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080105/e48c7257/signature.bin From rhee at ncsu.edu Sat Jan 5 23:32:24 2008 From: rhee at ncsu.edu (Injong Rhee) Date: Sun, 6 Jan 2008 16:32:24 +0900 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <4780655D.30009@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> <2FA84A86-D8C8-40B2-A5C0-972F256C4C7C@ncsu.edu> <4780655D.30009@isi.edu> Message-ID: <3CDCACF9-ECE7-4682-8109-30AFF85B27DA@ncsu.edu> >> >> Sure. But I want folks to look at the tests and the reports >> carefully or >> even try them by themselves. I am sure you will know it works! But >> i see >> the attitude of people who are mad just because its default >> release in >> Linux rather than trying to understand it technically first. > > People like me are mad because they ended up part of your experiment > before we had a chance to review your results, understand it > technically, and decide in the contents of an IETF standards track > discussion whether it was useful. > > That's the point of the IETF standards track. 1. I publish the research results through peer-reviewed papers and perform my experiments in a safe way without involving you. Whether I should go through the standard process like IETF or not is purely based on political/business reasons. I personally don't do the experiment in public at others' expense. 2. I believe i have done justice in terms of conducting extensive experiments and publish them as much as I can. If you can, please let me know any references that have done more experiments for a standard TCP modification than we have done with CUBIC/BIC. I see some NS simulation results, but do you trust them? I have not got any satisfying answers for this. 3. The Internet allows end users to use any protocols they want. Those who use it will do so at their own risk/benefit analysis. What mechanisms other than IETF (gush!) do we have that prevent them from using a new protocol harming others unknowingly or not? IMO, it is due to the faults of the inherent business model of the Internet. > >> I am working on a congestion control public testbed where people >> can try >> for themselves without investing too much time if they do care and we >> are also working with a number of people (e.g., TMRG) to agree on >> benchmark test suites. > > Why announce it? Why not just silently deploy it in Linux, omit the > measurements because they'd be disruptive, and then declare it all > works > in a few years? Wait a minute. I am not a champion of this process either. It is unfortunate that it happened that way. If you are really looking for a "wide-scale" deployment test without involving any innocent bystanders like yourself, i wish you good luck. My point is that the reviewers may themselves try their own experiments (in a safe way not involving a bystander) if possible, and base their decisions on technical factors, rather than on other political ones, and I am trying to make it easier . > > Seriously, I'm not against new protocols in general. I'm just not in > favor of silent deployment of new protocols to the unaware. > > Joe > From lars.eggert at nokia.com Sun Jan 6 01:06:07 2008 From: lars.eggert at nokia.com (Lars Eggert) Date: Sun, 6 Jan 2008 11:06:07 +0200 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> Message-ID: <9FEC6AD5-9E11-4B65-BFA4-022D9D9EC79A@nokia.com> Hi, On 2008-1-5, at 13:16, ext Injong Rhee wrote: > I am not sure either whether it is the job of IETF to prove it is > safe and harmless-- how do they know? when the IETF publishes RFCs, it needs to classify them into Experimental or Standards tracks. (There are also BCPs and Informational RFCs, but those aren't quite appropriate here.) So it is the IETF that needs to decide whether something is "safe for experimentation" and under what conditions (Experimental RFC), or whether something is "recommended for production use" (Standards Track RFC.) Because congestion control is essential for the stable operation of the Internet, the transport area has a pretty high bar for declaring something "recommended for production use." I agree with you that what is needed to pass that bar isn't well-defined. I don't think it can be - different proposals will require different arguments based on different kinds of data in order to come to consensus in a WG on whether it is safe for experimentation or not, or can be recommended for production use or not. There are currently three TCP variants (CUBIC, C-TCP and HTCP) that have made the jump from research paper to preliminary specification as Internet Drafts. As you know, the transport area has asked the IRTF's congestion control research group to help evaluate which of these three should be published as Experimental RFCs. (See http://www.ietf.org/IESG/content/ions/ion-tsv-alt-cc.txt) I fully expect several of the three or even all of them to be published as Experimental RFCs. After there is some experience from that experimental deployment, we'll think about recommending one of the variants (or maybe a spinoff or merge of one or more variants) for production use. > When those "standard" algorithms are IETF standardized, had they > more evaluation than CUBIC/BIC? At best, they had ns-2 simulation. > Back then there is no definition of realistic traffic patterns. Well, the whole Internet was a small experimental testbed back then, and one with broken congestion control. That's very different from the current situation, where we have a commercial internetwork that has functioning congestion control (in the sense of preventing congestion collapse and establishing some sort of fairness) and there is a desire to deploy modifications that incrementally improve that congestion control under some conditions. Today, we need to be careful not to break something that works. Back then, people were fixing something that didn't work. Finally, I'm personally very happy to see new research work coming to the transport area! Although the IETF standardization process can be tedious and takes time, the in-depth review and implementation efforts that often go along with it do improve the quality of the result. Lars From lars.eggert at nokia.com Sun Jan 6 01:22:32 2008 From: lars.eggert at nokia.com (Lars Eggert) Date: Sun, 6 Jan 2008 11:22:32 +0200 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <47806455.8040508@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> <47806455.8040508@isi.edu> Message-ID: <6C616168-133B-4314-814A-33438C96E426@nokia.com> On 2008-1-6, at 7:17, ext Joe Touch wrote: > Injong Rhee wrote: > ... >> I agree that the process could have been more diplomatic and it could >> have been improved. However, what's done is done. Wide-scale tests in >> some sense have been done for three to four years, as you said, >> unknowingly. If you don't trust that as a test, I am puzzled on what >> kind of wide-scale tests (with volunteers) we can do without causing >> disruption on the production networks. > > For all you know there have been problems - either failure to provide > benefit (which is otherwise harmless), or real problems - which you > haven't bothered to detect or collect statistics on. Closing your eyes > when you run an experiment doesn't declare it a success. It's important to remember the two reasons for congestion control from Sally's RFC2914: preventing congestion collapse and establishing some degree of fairness. CUBIC has been out there and the Internet hasn't collapsed. That's good. It tells at that at least with the current mixture of traffic in the Internet, CUBIC in concert with whatever other congestion control is out there prevents collapse. (We don't know, however, if this remains true under all possible conditions, though. But it's very likely - preventing collapse is the relatively easy part of congestion control.) What the current unmonitored deployment of CUBIC isn't giving us is data about how it affects fairness. If fairness-related issues (low performance, stalls, etc.) happen to the CUBIC users, there is at least a chance that they'll notice this and draw the right conclusions - if they know they're using CUBIC. But if these issues happen to non- CUBIC users that happen to share a path with CUBIC users, how are they ever going to figure out that the problems they see are due to somebody else using CUBIC? That's the sort of issues I worry about. So while the current deployment of CUBIC gives us some useful data, it doesn't give us all the data we'd need to evaluate safety. (And I don't want to single out CUBIC here - the same is true for any deployment of a congestion control variant.) Lars From lars.eggert at nokia.com Sun Jan 6 05:43:30 2008 From: lars.eggert at nokia.com (Lars Eggert) Date: Sun, 6 Jan 2008 15:43:30 +0200 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <0079EA505DB7BF48BE3D565D16ED55F805AB38A7@xmb-sjc-225.amer.cisco.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com><477EEA23.8070901@reed.com><071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu><477F18D9.30106@isi.edu><700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <9FEC6AD5-9E11-4B65-BFA4-022D9D9EC79A@nokia.com> <0079EA505DB7BF48BE3D565D16ED55F805AB38A7@xmb-sjc-225.amer.cisco.com> Message-ID: <8812B130-FC59-42FB-843E-F4D8E5C9013C@nokia.com> Hi, Debo, On 2008-1-6, at 11:41, ext Debo Dutta (dedutta) wrote: > I had some simple questions regarding the process from papers --> > IETF: > What are some of the metrics that could be used during discussions to > decide whether a protocol crosses the bar? Does someone need to > validate > the protocol in very large networks with realistic background traffic > patterns? Are there some standard topologies and background traffic > patterns under which the protocol needs to perform well? If so, this > would be very useful as reference scenarios for everyone. Sally and the IRTF's TMRG have been active on this front. See http://tools.ietf.org/html/rfc5033 for "Specifying New Congestion Control Algorithms" and especially http://tools.ietf.org/html/draft-irtf-tmrg-metrics-11 for "Metrics for the Evaluation of Congestion Control Mechanisms". There's a related effort underway to define a suite of standardized test scenarios for the initial evaluation of new congestion control methods; a preliminary writeup is at http://people.nokia.net/~lars/papers/2008-pfldnet.pdf . Some of the people involved in this effort are planning to make an "implementation| of the test suite available for ns2. Lars From dpreed at reed.com Sun Jan 6 09:39:53 2008 From: dpreed at reed.com (David P. Reed) Date: Sun, 06 Jan 2008 12:39:53 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <4780655D.30009@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> <2FA84A86-D8C8-40B2-A5C0-972F256C4C7C@ncsu.edu> <4780655D.30009@isi.edu> Message-ID: <47811269.8000600@reed.com> We deploy new protocols all the time by using UDP, of course. Perhaps the whole flap could have been avoided by simply defining a TCP-like protocol using UDP framing. The network is supposed to treat UDP packets with the same algorithms as TCP packets. And of course Linux would be easily modified so that CUBIC TCP packets were actually transported in UDP wrappers. Joe Touch wrote: > > Seriously, I'm not against new protocols in general. I'm just not in > favor of silent deployment of new protocols to the unaware. > > > From dpreed at reed.com Sun Jan 6 11:05:15 2008 From: dpreed at reed.com (David P. Reed) Date: Sun, 06 Jan 2008 14:05:15 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <6C616168-133B-4314-814A-33438C96E426@nokia.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> <47806455.8040508@isi.edu> <6C616168-133B-4314-814A-33438C96E426@nokia.com> Message-ID: <4781266B.9010209@reed.com> Thinking deeply about "absence of congestion collapse" and "fairness" - it is clearly not possible for a protocol (or the network itself) to absolutely guarantee either property. This is the core of the argument we made in the paper called End-to-end arguments in system design". For a simple example by analogy: it is not possible to design a bridge that will not collapse when hundreds of thousands of people endeavor to stand on it with the purpose of collapsing it. You MAY be able to do such a design if you *assume* that the behavior of people is (for example) random, without coordination, and "normal". Similarly, telephone switches and sewage systems are not guaranteed to be either "fair" or to avoid under all circumstances violating the desirable properties. As long as the implementation of the Internet is finite and has a finite capacity, it would seem extremely likely that certain kinds of traffic patterns that would be "desirable" would also make the Internet vulnerable to congestion collapse and unfairness according to reasonable definitions of fairness as viewed by end users [Nick McKeown is known as an example of a radical who has written often that he thinks fairness is defined at each router in isolation - but such "router-eyed" views seem to me irrelevant, since fairness at a router can lead to very non-fair end-to-end behavior] It seems very likely that attempting to operate the Internet as a whole at very high loads (the goal of protocol optimizers seems to be to eliminate any slack time on any links that can be eliminated) create the very risk of "congestion collapse" that people fear. Systems operating at extreme points are often quite unstable and non-resilient. So the safest thing the network as a whole can do to insure lack of "congestion collapse" is to trade excess capacity for stability. This can be done, not by legislating end-to-end protocols, but by investing in new capacity well ahead of demand. Lars Eggert wrote: > > It's important to remember the two reasons for congestion control from > Sally's RFC2914: preventing congestion collapse and establishing some > degree of fairness. > > From dedutta at cisco.com Sun Jan 6 01:41:45 2008 From: dedutta at cisco.com (Debo Dutta (dedutta)) Date: Sun, 6 Jan 2008 01:41:45 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <9FEC6AD5-9E11-4B65-BFA4-022D9D9EC79A@nokia.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com><477EEA23.8070901@reed.com><071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu><477F18D9.30106@isi.edu><700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <9FEC6AD5-9E11-4B65-BFA4-022D9D9EC79A@nokia.com> Message-ID: <0079EA505DB7BF48BE3D565D16ED55F805AB38A7@xmb-sjc-225.amer.cisco.com> Hi Lars I had some simple questions regarding the process from papers --> IETF: What are some of the metrics that could be used during discussions to decide whether a protocol crosses the bar? Does someone need to validate the protocol in very large networks with realistic background traffic patterns? Are there some standard topologies and background traffic patterns under which the protocol needs to perform well? If so, this would be very useful as reference scenarios for everyone. Regards Debo -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Lars Eggert Sent: Sunday, January 06, 2008 1:06 AM To: ext Injong Rhee Cc: Randy Bush; David P. Reed; end2end-interest at postel.org; Joe Touch Subject: Re: [e2e] Are we doing sliding window in the Internet? Hi, On 2008-1-5, at 13:16, ext Injong Rhee wrote: > I am not sure either whether it is the job of IETF to prove it is > safe and harmless-- how do they know? when the IETF publishes RFCs, it needs to classify them into Experimental or Standards tracks. (There are also BCPs and Informational RFCs, but those aren't quite appropriate here.) So it is the IETF that needs to decide whether something is "safe for experimentation" and under what conditions (Experimental RFC), or whether something is "recommended for production use" (Standards Track RFC.) Because congestion control is essential for the stable operation of the Internet, the transport area has a pretty high bar for declaring something "recommended for production use." I agree with you that what is needed to pass that bar isn't well-defined. I don't think it can be - different proposals will require different arguments based on different kinds of data in order to come to consensus in a WG on whether it is safe for experimentation or not, or can be recommended for production use or not. There are currently three TCP variants (CUBIC, C-TCP and HTCP) that have made the jump from research paper to preliminary specification as Internet Drafts. As you know, the transport area has asked the IRTF's congestion control research group to help evaluate which of these three should be published as Experimental RFCs. (See http://www.ietf.org/IESG/content/ions/ion-tsv-alt-cc.txt) I fully expect several of the three or even all of them to be published as Experimental RFCs. After there is some experience from that experimental deployment, we'll think about recommending one of the variants (or maybe a spinoff or merge of one or more variants) for production use. > When those "standard" algorithms are IETF standardized, had they more > evaluation than CUBIC/BIC? At best, they had ns-2 simulation. > Back then there is no definition of realistic traffic patterns. Well, the whole Internet was a small experimental testbed back then, and one with broken congestion control. That's very different from the current situation, where we have a commercial internetwork that has functioning congestion control (in the sense of preventing congestion collapse and establishing some sort of fairness) and there is a desire to deploy modifications that incrementally improve that congestion control under some conditions. Today, we need to be careful not to break something that works. Back then, people were fixing something that didn't work. Finally, I'm personally very happy to see new research work coming to the transport area! Although the IETF standardization process can be tedious and takes time, the in-depth review and implementation efforts that often go along with it do improve the quality of the result. Lars From christos at CS.ColoState.EDU Sun Jan 6 06:50:59 2008 From: christos at CS.ColoState.EDU (Christos Papadopoulos) Date: Sun, 6 Jan 2008 07:50:59 -0700 Subject: [e2e] Call for Papers: INFOCOM 2008 Workshops Message-ID: <20080106145059.GA20057@mozart.cs.colostate.edu> CFP: INFOCOM 2008 WORKSHOPS http://www.ieee-infocom.org/workshops.html INFOCOM 2008 will host six workshops, collocated with the main event. These workshops address important emerging technologies. The purpose of the workshops is to stimulate early responses and experimentation on these areas. Submitted papers are typically 6 pages long. More information about submission deadlines and procedures can be found at the workshop webpages. Workshop on Mission Critical Networks (MCN) http://www.criticalnet.org/ Submission deadline: February 15, 2008 Global Internet Symposium (GI) http://netsec.colostate.edu/gi08/ Paper registration: February 1, 2008 Submision deadline: February 8, 2008 MObile Networking for Vehicular Environments (MOVE) http://infocom-move.org/ Submision deadline: January 31, 2008 Automated Network Management (ANM) http://www.ee.kth.se/lcn/anm08/ Abstract submision: February 15, 2008 Submision deadline: February 22, 2008 High-Speed Networks Workshop (HSN) http://www.arl.wustl.edu/~hsn2008/ Submission deadline: February 7, 2008 Student Workshop http://criticalnet.org/ws/ Submission deadline: February 15, 2008 You may contact the Infocom'08 workshop co-chairs for more information. Ehab Al-Shaer Mohamed Eltoweissy From huitema at windows.microsoft.com Sun Jan 6 11:51:10 2008 From: huitema at windows.microsoft.com (Christian Huitema) Date: Sun, 6 Jan 2008 11:51:10 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <6C616168-133B-4314-814A-33438C96E426@nokia.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> <47806455.8040508@isi.edu> <6C616168-133B-4314-814A-33438C96E426@nokia.com> Message-ID: > It's important to remember the two reasons for congestion control from > Sally's RFC2914: preventing congestion collapse and establishing some > degree of fairness. Wait a minute. This is equivalent to saying that continuous stability of the Internet depends on the benevolent cooperation of all Internet users. The implementation of slow start in TCP did indeed prevent the Internet to collapse at a crucial time in its evolution. But that was then. I don't think we can extrapolate the 1988 fix into an everlasting principle, not with a billion hosts on the Internet. In that research on "network based" mechanisms, we should accept that end systems will be primarily motivated by their self interest. They are certainly not motivated by a desire to be fair with others. The desire of fairness is a social contract, and I don't think we can assume such a contract when the Internet covers the entire world. If we could, that would indeed be a good thing, we would also have worldwide peace and all that kind of thing. So, we have better assume that end system will try to maximize their individual satisfaction, rather than looking for the common good. If we cannot rely on the benevolent sum of individual behaviors, we need to build mechanisms in the network that help it guarantee its stability. In fact, ISP are already attempting to build this "stabilization tools" in their networks. We see various forms of traffic shaping implemented at bottleneck points. We see various tools used to perform "traffic engineering". ISP need to do that if they have any hope of providing some kind of guarantees of service. Many on this list will find those tools crude, or possibly harmful. Fine, but the reaction cannot be to retreat in the ivory tower and leer at those lowly network engineers. Instead of clinging to the illusion that we can entirely solve the problem in an end to end fashion, that all end systems will follow the dictate of the E2E group, maybe we should actually address the problem. What is the best mechanisms to deploy in the Internet to make it immune to variations in end to end algorithms? -- Christian Huitema From L.Wood at surrey.ac.uk Sun Jan 6 15:58:15 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Sun, 06 Jan 2008 23:58:15 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <477EAEB8.2070207@isi.edu> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <200801041747.RAA01412@cisco.com> <477E74E3.3050501@isi.edu> <477E9A69.5030705@reed.com> <477EAEB8.2070207@isi.edu> Message-ID: <200801062358.XAA29183@cisco.com> At Friday 04/01/2008 14:10 -0800, Joe Touch wrote: >This sounds a lot like you're interested in participating in an >experiment where you don't know the impact. Does that seem like a good >idea to you? Yes. It's called 'life', and I participate in it every day. I'd like to put off the alternative as long as possible, thankyouverymuch. >> Is that any different than running CUBIC between PlanetLab nodes and >> users on PCs in academic computer networking research labs? > >Those users knew they were running experiments, and knew when they were >over. Deploying CUBIC in public distributions lets the experiment out >into thw wild, and is no longer a controlled, voluntary participation >experiment. Wow, you must have been really steamed about the development and release of rlogin and the rtools. L. From lars.eggert at nokia.com Mon Jan 7 02:46:47 2008 From: lars.eggert at nokia.com (Lars Eggert) Date: Mon, 7 Jan 2008 12:46:47 +0200 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: Message-ID: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> References: <003801c73448$713c10c0$6e8944c6 at telemuse.net> <45A4D230.5020105 at web.de> <477D6A3E.7080900 at isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2 at EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809 at reed.com> <477DC5DA.6070800 at isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035 at mail.gmail.com> <477E5677.6010808 at isi.edu> <200801041713.RAA29230 at cisco.com> <477E6D30.1080905 at isi.edu> <477E96B2.3000600 at reed.com> <477EAEBE.9080906 at isi.edu> <477EC061.4080101 at isi.edu> <477EC65D.1010606 at isi.edu> <477ED546.6040005 at psg.com> <477EEA23.8070901 at reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4 at ncsu.edu> <477F18D9.30106 at isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027 at ncsu.edu> <477FB5AB.3090601 at isi.edu> <47806455.8040508 at isi.edu> <6C616168-133B-4314-81! 4A-33438C96E426 at nokia.com> X-Mailer: Apple Mail (2.915) Return-Path: lars.eggert at nokia.com X-OriginalArrivalTime: 07 Jan 2008 10:46:49.0657 (UTC) FILETIME=[9B4CF290:01C8511A] Hi, On 2008-1-6, at 21:51, ext Christian Huitema wrote: >> It's important to remember the two reasons for congestion control >> from >> Sally's RFC2914: preventing congestion collapse and establishing some >> degree of fairness. > > Wait a minute. This is equivalent to saying that continuous > stability of the Internet depends on the benevolent cooperation of > all Internet users. The implementation of slow start in TCP did > indeed prevent the Internet to collapse at a crucial time in its > evolution. But that was then. I don't think we can extrapolate the > 1988 fix into an everlasting principle, not with a billion hosts on > the Internet. this is taking us pretty far away from the context in which I made the statement you quoted above (what we learn from the current CUBIC deployment), but anyway: I'm not saying that end system transport-layer congestion control is all that we'll ever need, especially when end systems become selfish. But I do think that the stable operation of the Internet has been depending and probably is still depending on the majority of the traffic being sent over congestion-controlled transport protocols. If that changes (and my nightmare scenario is that the BitTorrent guys realize that they don't need to use the in-kernel TCP stack, all they need to use is the TCP packet format), yes, then we do need something else, as you say below. > In that research on "network based" mechanisms, we should accept > that end systems will be primarily motivated by their self interest. > They are certainly not motivated by a desire to be fair with others. > The desire of fairness is a social contract, and I don't think we > can assume such a contract when the Internet covers the entire > world. If we could, that would indeed be a good thing, we would also > have worldwide peace and all that kind of thing. So, we have better > assume that end system will try to maximize their individual > satisfaction, rather than looking for the common good. If we cannot > rely on the benevolent sum of individual behaviors, we need to build > mechanisms in the network that help it guarantee its stability. > > In fact, ISP are already attempting to build this "stabilization > tools" in their networks. We see various forms of traffic shaping > implemented at bottleneck points. We see various tools used to > perform "traffic engineering". ISP need to do that if they have any > hope of providing some kind of guarantees of service. Many on this > list will find those tools crude, or possibly harmful. Fine, but the > reaction cannot be to retreat in the ivory tower and leer at those > lowly network engineers. Instead of clinging to the illusion that we > can entirely solve the problem in an end to end fashion, that all > end systems will follow the dictate of the E2E group, maybe we > should actually address the problem. What is the best mechanisms to > deploy in the Internet to make it immune to variations in end to end > algorithms? I agree with you that there'll need to be something that protects the network and other users from selfish end systems, and it will need to be a mechanism that doesn't only rely on the cooperation of those end systems. But I'm also not convinced that this functionality should completely move into the network, which is what I think ISPs are currently attempting to do. An architecture that gives incentives to the end systems to behave correctly, rather than controlling everything network-side, appears more viable to me. (And we've just gotten some EU money over the next three years to look at how such a system would look in detail.) Lars From detlef.bosau at web.de Mon Jan 7 03:21:55 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 07 Jan 2008 12:21:55 +0100 Subject: [e2e] Once again: Detlef and Latencies :-) Message-ID: <47820B53.5050305@web.de> Same procedure as every year :-) During the last days I made some simulations on HSDPA packet latencies. I used the EURANE packet for this purpose. An overview of some results, which is still under construction, can be found here: http://www.detlef-bosau.de/eurane_results.html What I?m curious about are the latencies. 1.: The latencies seem to be independent of the scheduler in use. This is in strong contradiction to the results given in http://www.ikr.uni-stuttgart.de/Content/Publications/View/Standalone/FullRecord.html?36518 And particularly, it does not make sense. The intention of opportunistic scheduling is to send a packet when channel conditions are favourite - and so decrease the number of necessary retransmissions. So the result should be that the transport latency decreases. Therefore, it simply appears to be nonsense that a round robin scheduler yields the same latency distribution as a proportional fair scheduler. 2.: The latency distributions are extremely asymmteric. There is some constant bias due do wireline latencies in my simulation script, however the distributions appear to be extremely heavy tailed. And this perfectly fits into the e2e discussion. According to my results, which particurly differe from those by the IKR guys in this respect which makes the question even more important, the vast majority of delays is_below_ say 50 ms. And there are quite some few _extreme_ outliers which are not depicted due to the width of the diagram but are sometimes even larger than 100 seconds. So, the questions are: 1: Which results are true? Shall I believe the IKR results or the EURANE results? 2: Are the latency distributions really that extreme that, say, a 0.5 quantile is 30 ms, a 0.8 quantile is 50 ms and a 0.99 quantile is one hour or more? 3: If the former is true: What is the reason for this behaviour? (O.k., I will read the EURANE sources once more quite carefully, that?s in fact the best documentation available ;-)) Is this due to the algorithms themselves or due to the implementation? And if the distribution is in fact that extreme, I tend to say: This does not really make sense. I tend to modify the L2 code that way that anything, what is delivered from the base station to the terminal within, say, 50 ms should be delivered and we hare happy with this. And anything, what cannot be delivered within that period of time simply shall be dropped. My concern is that extreme outlieres in transport latencies cause more grief to upper layers (RTO determination, spurious timeouts and retransmits, if we do loss detection my multiple ACKs we would need extremely large congestion windows etc.) than any benefit. So, in this particular case, I would tend to follow our "the" paper on end to end system design which suggests to spend not too much effort on local error recovery. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From dpreed at reed.com Mon Jan 7 06:46:10 2008 From: dpreed at reed.com (David P. Reed) Date: Mon, 07 Jan 2008 09:46:10 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> References: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> Message-ID: <47823B32.2070508@reed.com> 99% of the effect of the original TCP congestion control "innovation" was due to a simple and robust principle: when a packet is lost, cut the traffic being sent *drastically*. This converted a tendency of the community to turn packet losses into a positive feedback loop of retransmission into a shared understanding that "positive feedback loops are bad". That was a community-scale learning that was useful. I would argue that the idea that TCP is now "near perfect" as a standard that *must be enforced lest the Internet enter congestion collapse* has almost no real-world evidence. In fact, very little of the traffic on the network today comes in the form of end-to-end unbounded-rate-demanding streams. TCP's congestion control (and the definition of "TCP compatible" fairness, too!) is "tested" only for such a trivial case. No One At All tests TCP congestion control in a world of HTTP, VoIP, streaming video from YouTube, Skype, etc. The "gurus" of the IETF that study protocol *documents* have intuitions that are seriously flawed, if only because they don't actually have any data about the traffic ANYWHERE in the damn network. (kc claffy would die to have such data). So it seems that a bunch of self-elected high-priests of IETF have taken it upon themselves to claim God-like, experiment-free knowledge of the Internet as it really is, and to use that knowledge to claim that TCP is the Gold Standard that must be obeyed lest the network finally do what Bob Metcalfe erroneously said it would do and ate whatever piece of clothing he ate as a result. Do science and real engineering, please. Yeah, the AIMD algorithm in TCP saved the Internet's ass. But it is not Holy Writ. > From jg at laptop.org Mon Jan 7 07:47:34 2008 From: jg at laptop.org (Jim Gettys) Date: Mon, 07 Jan 2008 10:47:34 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <47823B32.2070508@reed.com> References: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> <47823B32.2070508@reed.com> Message-ID: <1199720854.5731.8.camel@localhost> > Bob Metcalfe erroneously said it would do and ate whatever piece of > clothing he ate as a result. > Bob said he'd "eat his words".... He tried to get out of it by wheeling a cake out with his words in icing on the top in front of the web conference plenary session. He was booed down by the audience. He then took the page from the magazine, put it in a blender, added some water, turned it into paper pulp, and drank it down. Bob looked pretty green afterwords when I saw him. He does have guts, Metcalfe does... - Jim -- Jim Gettys One Laptop Per Child From lars.eggert at nokia.com Mon Jan 7 07:11:31 2008 From: lars.eggert at nokia.com (Lars Eggert) Date: Mon, 7 Jan 2008 17:11:31 +0200 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <47823B32.2070508@reed.com> References: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> <47823B32.2070508@reed.com> Message-ID: Hi, David, since your message has me in the "To" field, I'm guessing it was triggered by one of my earlier emails. If that's the case, either I'm not expressing my points clearly enough, or you're significantly over-interpreting them. Or both. Usually, I'd try to clarify things at this point, but reading the rest of your email somehow doesn't leave me with the impression that such an attempt would be fruitful. Lars On 2008-1-7, at 16:46, ext David P. Reed wrote: > 99% of the effect of the original TCP congestion control > "innovation" was due to a simple and robust principle: when a packet > is lost, cut the traffic being sent *drastically*. This converted > a tendency of the community to turn packet losses into a positive > feedback loop of retransmission into a shared understanding that > "positive feedback loops are bad". > > That was a community-scale learning that was useful. > > I would argue that the idea that TCP is now "near perfect" as a > standard that *must be enforced lest the Internet enter congestion > collapse* has almost no real-world evidence. > > In fact, very little of the traffic on the network today comes in > the form of end-to-end unbounded-rate-demanding streams. TCP's > congestion control (and the definition of "TCP compatible" fairness, > too!) is "tested" only for such a trivial case. No One At All > tests TCP congestion control in a world of HTTP, VoIP, streaming > video from YouTube, Skype, etc. The "gurus" of the IETF that study > protocol *documents* have intuitions that are seriously flawed, if > only because they don't actually have any data about the traffic > ANYWHERE in the damn network. (kc claffy would die to have such > data). > > So it seems that a bunch of self-elected high-priests of IETF have > taken it upon themselves to claim God-like, experiment-free > knowledge of the Internet as it really is, and to use that knowledge > to claim that TCP is the Gold Standard that must be obeyed lest the > network finally do what Bob Metcalfe erroneously said it would do > and ate whatever piece of clothing he ate as a result. > > Do science and real engineering, please. Yeah, the AIMD algorithm > in TCP saved the Internet's ass. But it is not Holy Writ. >> From dpreed at reed.com Mon Jan 7 07:22:29 2008 From: dpreed at reed.com (David P. Reed) Date: Mon, 07 Jan 2008 10:22:29 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> <47823B32.2070508@reed.com> Message-ID: <478243B5.5030806@reed.com> Lars - I'm always interested in learning new things. Such an attempt would be fruitful - I have been wrong in the past, and can admit I am wrong. Sorry if my expression of general frustration with the sociology of the IETF and research communities was too "hot-headed". If I had stated it in less spicy terms, there would still be a strong argument that others could choose to rebut. It was not triggered specifically by any one person's views - more an integration of a set of views that have been bugging me for years. Which is why I did not include any quoted text. Perhaps my spiciness discourages discussion. I would hope it would do the opposite, perhaps encouraging people to marshal real arguments, real data to disprove what I argue for. Lars Eggert wrote: > Hi, David, > > since your message has me in the "To" field, I'm guessing it was > triggered by one of my earlier emails. > > If that's the case, either I'm not expressing my points clearly > enough, or you're significantly over-interpreting them. Or both. > Usually, I'd try to clarify things at this point, but reading the rest > of your email somehow doesn't leave me with the impression that such > an attempt would be fruitful. > > Lars > > On 2008-1-7, at 16:46, ext David P. Reed wrote: >> 99% of the effect of the original TCP congestion control "innovation" >> was due to a simple and robust principle: when a packet is lost, cut >> the traffic being sent *drastically*. This converted a tendency of >> the community to turn packet losses into a positive feedback loop of >> retransmission into a shared understanding that "positive feedback >> loops are bad". >> >> That was a community-scale learning that was useful. >> >> I would argue that the idea that TCP is now "near perfect" as a >> standard that *must be enforced lest the Internet enter congestion >> collapse* has almost no real-world evidence. >> >> In fact, very little of the traffic on the network today comes in the >> form of end-to-end unbounded-rate-demanding streams. TCP's >> congestion control (and the definition of "TCP compatible" fairness, >> too!) is "tested" only for such a trivial case. No One At All tests >> TCP congestion control in a world of HTTP, VoIP, streaming video from >> YouTube, Skype, etc. The "gurus" of the IETF that study protocol >> *documents* have intuitions that are seriously flawed, if only >> because they don't actually have any data about the traffic ANYWHERE >> in the damn network. (kc claffy would die to have such data). >> >> So it seems that a bunch of self-elected high-priests of IETF have >> taken it upon themselves to claim God-like, experiment-free knowledge >> of the Internet as it really is, and to use that knowledge to claim >> that TCP is the Gold Standard that must be obeyed lest the network >> finally do what Bob Metcalfe erroneously said it would do and ate >> whatever piece of clothing he ate as a result. >> >> Do science and real engineering, please. Yeah, the AIMD algorithm >> in TCP saved the Internet's ass. But it is not Holy Writ. >>> > > From craig at aland.bbn.com Mon Jan 7 08:19:38 2008 From: craig at aland.bbn.com (Craig Partridge) Date: Mon, 07 Jan 2008 11:19:38 -0500 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: Your message of "Mon, 07 Jan 2008 09:46:10 EST." <47823B32.2070508@reed.com> Message-ID: <20080107161938.B9C2A123842@aland.bbn.com> Hi Dave: I think you're understating the TCP innovation/intuition in important ways. The starting point of the TCP innovations was to view a TCP connection as a control loop and to ask what the correct behavior of the control loop was under certain impulses. As you observe, this approach rapidly led to the conclusion that for the impulse of loss due to congestion, the answer was "send less" rather than "send more." In that light, when someone shows up and says "hey, I've got a TCP innovation" in the absence of understanding they are dealing with a control loop, there's justified skepticism. At the same time, I agree with you that in the current world (where we have little understanding of what is flowing over our networks), we have only a primitive guess about what new kinds of impulses our TCP control loops are experiencing and what they should do. This observation, of course, applies to lots of other network traffic too (much of which also can be modeled as some kind of control theory structure). Thanks! Craig From david.borman at windriver.com Mon Jan 7 08:57:25 2008 From: david.borman at windriver.com (David Borman) Date: Mon, 7 Jan 2008 10:57:25 -0600 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> References: <50FFD42B-0E41-41C5-BAD7-E9E1988B34B4@nokia.com> Message-ID: On Jan 7, 2008, at 4:46 AM, Lars Eggert wrote: > On 2008-1-6, at 21:51, ext Christian Huitema wrote: ... > >>> In that research on "network based" mechanisms, we should accept >>> that end systems will be primarily motivated by their self >>> interest. They are certainly not motivated by a desire to be fair >>> with others. The desire of fairness is a social contract, and I >>> don't think we can assume such a contract when the Internet covers >>> the entire world. If we could, that would indeed be a good thing, >>> we would also have worldwide peace and all that kind of thing. So, >>> we have better assume that end system will try to maximize their >>> individual satisfaction, rather than looking for the common good. >>> If we cannot rely on the benevolent sum of individual behaviors, >>> we need to build mechanisms in the network that help it guarantee >>> its stability. >> >> In fact, ISP are already attempting to build this "stabilization >> tools" in their networks. We see various forms of traffic shaping >> implemented at bottleneck points. We see various tools used to >> perform "traffic engineering". ISP need to do that if they have any >> hope of providing some kind of guarantees of service. Many on this >> list will find those tools crude, or possibly harmful. Fine, but >> the reaction cannot be to retreat in the ivory tower and leer at >> those lowly network engineers. Instead of clinging to the illusion >> that we can entirely solve the problem in an end to end fashion, >> that all end systems will follow the dictate of the E2E group, >> maybe we should actually address the problem. What is the best >> mechanisms to deploy in the Internet to make it immune to >> variations in end to end algorithms? > > I agree with you that there'll need to be something that protects > the network and other users from selfish end systems, and it will > need to be a mechanism that doesn't only rely on the cooperation of > those end systems. > > But I'm also not convinced that this functionality should completely > move into the network, which is what I think ISPs are currently > attempting to do. An architecture that gives incentives to the end > systems to behave correctly, rather than controlling everything > network-side, appears more viable to me. (And we've just gotten some > EU money over the next three years to look at how such a system > would look in detail.) The incentive to the end system will always be there: to get useful data through to the other side. "Traffic engineering" can address how flows interact/affect each other to avoid network congestion collapse, but it is still up to the end system to decide how to make use of whatever bandwidth it can get. There will always be self-interest by the end system to avoid having packets lost, and to react sanely when there is packet loss to minimize the number of retransmissions. So I think there will always be a need for both "network engineering" and end-to-end solutions. -David Borman From padhye at microsoft.com Sun Jan 6 13:37:38 2008 From: padhye at microsoft.com (Jitu Padhye) Date: Sun, 6 Jan 2008 13:37:38 -0800 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: <0079EA505DB7BF48BE3D565D16ED55F805AB38A7@xmb-sjc-225.amer.cisco.com> References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com><477EEA23.8070901@reed.com><071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu><477F18D9.30106@isi.edu><700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <9FEC6AD5-9E11-4B65-BFA4-022D9D9EC79A@nokia.com> <0079EA505DB7BF48BE3D565D16ED55F805AB38A7@xmb-sjc-225.amer.cisco.com> Message-ID: This is a starting point: http://www.ietf.org/rfc/rfc5033.txt -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Debo Dutta (dedutta) Sent: Sunday, January 06, 2008 1:42 AM To: Lars Eggert; ext Injong Rhee Cc: Randy Bush; David P. Reed; end2end-interest at postel.org; Joe Touch Subject: Re: [e2e] Are we doing sliding window in the Internet? Hi Lars I had some simple questions regarding the process from papers --> IETF: What are some of the metrics that could be used during discussions to decide whether a protocol crosses the bar? Does someone need to validate the protocol in very large networks with realistic background traffic patterns? Are there some standard topologies and background traffic patterns under which the protocol needs to perform well? If so, this would be very useful as reference scenarios for everyone. Regards Debo -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Lars Eggert Sent: Sunday, January 06, 2008 1:06 AM To: ext Injong Rhee Cc: Randy Bush; David P. Reed; end2end-interest at postel.org; Joe Touch Subject: Re: [e2e] Are we doing sliding window in the Internet? Hi, On 2008-1-5, at 13:16, ext Injong Rhee wrote: > I am not sure either whether it is the job of IETF to prove it is > safe and harmless-- how do they know? when the IETF publishes RFCs, it needs to classify them into Experimental or Standards tracks. (There are also BCPs and Informational RFCs, but those aren't quite appropriate here.) So it is the IETF that needs to decide whether something is "safe for experimentation" and under what conditions (Experimental RFC), or whether something is "recommended for production use" (Standards Track RFC.) Because congestion control is essential for the stable operation of the Internet, the transport area has a pretty high bar for declaring something "recommended for production use." I agree with you that what is needed to pass that bar isn't well-defined. I don't think it can be - different proposals will require different arguments based on different kinds of data in order to come to consensus in a WG on whether it is safe for experimentation or not, or can be recommended for production use or not. There are currently three TCP variants (CUBIC, C-TCP and HTCP) that have made the jump from research paper to preliminary specification as Internet Drafts. As you know, the transport area has asked the IRTF's congestion control research group to help evaluate which of these three should be published as Experimental RFCs. (See http://www.ietf.org/IESG/content/ions/ion-tsv-alt-cc.txt) I fully expect several of the three or even all of them to be published as Experimental RFCs. After there is some experience from that experimental deployment, we'll think about recommending one of the variants (or maybe a spinoff or merge of one or more variants) for production use. > When those "standard" algorithms are IETF standardized, had they more > evaluation than CUBIC/BIC? At best, they had ns-2 simulation. > Back then there is no definition of realistic traffic patterns. Well, the whole Internet was a small experimental testbed back then, and one with broken congestion control. That's very different from the current situation, where we have a commercial internetwork that has functioning congestion control (in the sense of preventing congestion collapse and establishing some sort of fairness) and there is a desire to deploy modifications that incrementally improve that congestion control under some conditions. Today, we need to be careful not to break something that works. Back then, people were fixing something that didn't work. Finally, I'm personally very happy to see new research work coming to the transport area! Although the IETF standardization process can be tedious and takes time, the in-depth review and implementation efforts that often go along with it do improve the quality of the result. Lars From Jon.Crowcroft at cl.cam.ac.uk Sun Jan 6 15:12:45 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 06 Jan 2008 23:12:45 +0000 Subject: [e2e] Are we doing sliding window in the Internet? In-Reply-To: References: <003801c73448$713c10c0$6e8944c6@telemuse.net> <45A4D230.5020105@web.de> <477D6A3E.7080900@isi.edu> <603BF90EB2E7EB46BF8C226539DFC20701316AE2@EVS-EC1-NODE1.surrey.ac.uk> <477DA1D1.50809@reed.com> <477DC5DA.6070800@isi.edu> <5640c7e00801032220h1fa945b9k61a01c70235fb035@mail.gmail.com> <477E5677.6010808@isi.edu> <200801041713.RAA29230@cisco.com> <477E6D30.1080905@isi.edu> <477E96B2.3000600@reed.com> <477EAEBE.9080906@isi.edu> <477EC061.4080101@isi.edu> <477EC65D.1010606@isi.edu> <477ED546.6040005@psg.com> <477EEA23.8070901@reed.com> <071424AB-2FEB-418E-AEDA-849913F9D0B4@ncsu.edu> <477F18D9.30106@isi.edu> <700B57DF-259E-45F0-8234-AE1D504D8027@ncsu.edu> <477FB5AB.3090601@isi.edu> <47806455.8040508@isi.edu> <6C616168-133B-4314-814A-33438C96E426@nokia.com> Message-ID: indeed. most email is unwanted; if most IP packets were unwanted, tcp would be irrelevant... luckily other mechanisms on other scopes, scales and timeframes are used to stop this. e2e congestion control is a) a microeconomic solution b) not (repeat NOT) a mechanism for fairness enforcement.... like, doh, a) speed limits dont stop people speeding and b) dont stop traffic jams you want a different internet, go do FIND/GENI research you wanna play here, stay with the ground rules:) In missive , Christian Huit ema typed: >>> It's important to remember the two reasons for congestion control from >>> Sally's RFC2914: preventing congestion collapse and establishing some >>> degree of fairness. >> >>Wait a minute. This is equivalent to saying that continuous stability of the Internet depends on the benevolent cooperation of all Internet users. The implementation of slow start in TCP did indeed prevent the Internet to collapse at a crucial time in its evolution. But that was then. I don't think we can extrapolate the 1988 fix into an everlasting principle, not with a billion hosts on the Internet. >> >>In that research on "network based" mechanisms, we should accept that end systems will be primarily motivated by their self interest. They are certainly not motivated by a desire to be fair with others. The desire of fairness is a social contract, and I don't think we can assume such a contract when the Internet covers the entire world. If we could, that would indeed be a good thing, we would also have worldwide peace and all that kind of thing. So, we have better assume that end system will try to maximize their individual satisfaction, rather than looking for the common good. If we cannot rely on the benevolent sum of individual behaviors, we need to build mechanisms in the network that help it guarantee its stability. >> >>In fact, ISP are already attempting to build this "stabilization tools" in their networks. We see various forms of traffic shaping implemented at bottleneck points. We see various tools used to perform "traffic engineering". ISP need to do that if they have any hope of providing some kind of guarantees of service. Many on this list will find those tools crude, or possibly harmful. Fine, but the reaction cannot be to retreat in the ivory tower and leer at those lowly network engineers. Instead of clinging to the illusion that we can entirely solve the problem in an end to end fashion, that all end systems will follow the dictate of the E2E group, maybe we should actually address the problem. What is the best mechanisms to deploy in the Internet to make it immune to variations in end to end algorithms? >> >>-- Christian Huitema >> >> >> cheers jon From detlef.bosau at web.de Tue Jan 8 03:35:24 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 08 Jan 2008 12:35:24 +0100 Subject: [e2e] My fault..... Re: Once again: Detlef and Latencies :-) In-Reply-To: <47820B53.5050305@web.de> References: <47820B53.5050305@web.de> Message-ID: <47835FFC.9020008@web.de> I?m sorry for the confustion - yesterday in the evening I noticed a severe bug in the Perl script which runs my simulation. After having this fixed, the results were much more reasonable. I updated the traces on my website. Thanks. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From michael.welzl at uibk.ac.at Thu Jan 10 05:03:57 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 14:03:57 +0100 Subject: [e2e] A message to authors of PFLDNet papers Message-ID: <1199970237.3801.95.camel@pc105-c703.uibk.ac.at> Dear all, I am writing this email in the function of Pfldnet TPC co-chair, assuming that there is some overlap between potential authors for the PFLDNet workshop and the readers of this list. This year, based on the explanation on the PFLDNet website: http://www.hep.man.ac.uk/PFLDnet2008/ it was required to submit papers via email. We now have a concern that some submissions might not have been received by us due to spam filters. Maybe email submission was not the best idea... Anyway, in an effort to restrain any damage, we would like to inform you that authors of papers who submitted to Pfldnet'08 should have received a confirmation email. If you submitted a paper but never received a confirmation email, by all means resubmit it please - or just send it to one of us organizers, who will confirm reception to you. We apologize for the trouble. Best regards, Michael Welzl From Jon.Crowcroft at cl.cam.ac.uk Thu Jan 10 06:18:03 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 10 Jan 2008 14:18:03 +0000 Subject: [e2e] was Re: A message to authors - nsdi Message-ID: Michael, and others we had several problems with NSDI this year due to silent failure of email. Many of us have taken for granted that e-mail had become somewhat of a atomic building block for delivery of notifications of various things, but this is (alas) simply incorrect and things are getting worse - I hate to say this, but we may find ourselves pushing responsibility around in future (e.g. authors must poll a site to check on status, rather than (or as well as) expecting an event reporting phase changes such as submission received, pdf checked, paper in review, accept/reject notification etc obviously one can leave in place the e-mail systems, but it is simply not working - some of the bayesian rule based filters do not even give consistent results over the same pair of sender/recipient, or over a sequence of messages with the same content...but (and of course for a spam filter, this is "correct" since teling a bad guy anything is deemed self-defeating) there's no SMTP error notification so end2end delivery is assumed to have occurred.... users with white listing technologies should consider adding conference submission sites to the white list but it aint as simple as that of course... j. p.s. we were even stymied partly by our own mail system anti-spam measures which include rate-limiting automatic mail outbound from our site... argh!!! From michael.welzl at uibk.ac.at Thu Jan 10 06:37:01 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 15:37:01 +0100 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: References: Message-ID: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> Yeah... Silent loss of email is one of the real problems that the Internet is facing today. Much more real, and much more severe, than many of the other issues that people like myself deal with on a daily basis. I've been looking into the problem a bit - there's a neat suggested solution from MS research called SureMail: http://research.microsoft.com/netres/projects/SureMail/ (hm, maybe it was *you* who once pointed me to it?! sorry for sending it back to you in this case :-) ), and I considered just adding a reliability loop between my outgoing SMTP server and your POP server (because these are the entities between which reliability is assumed - if your *personal* spam folder delete's stuff, you usually accept that it's your fault), where I would get my emails marked in my "sent" folder when they reached your POP ... this way I know that some definitely made it, and several others *might* have made it to the other end - that would already be helpful I guess Turns out that there's a standard in place for doing that SMTP-POP loop described above, but it isn't normally used, no idea why ... I had to stop looking deeper at some point because all the other work pulled the carpet from under my feet, but I'm still quite interested in that Bottom line: email is badly broken, and one of the most heavily used Internet services, someone should truly fix it (and while I think that the SureMal approaches (actually multiple - the first and second papers are quite different, one has a DHT and one doesn't) area quite nice, they only partially solve the problem). Cheers, Michael On Thu, 2008-01-10 at 14:18 +0000, Jon Crowcroft wrote: > Michael, and others > > we had several problems with NSDI this year > due to silent failure of email. Many of us > have taken for granted that e-mail had become > somewhat of a atomic building block for > delivery of notifications of various things, > but this is (alas) simply incorrect and things > are getting worse - I hate to say this, but we > may find ourselves pushing responsibility > around in future (e.g. authors must poll a > site to check on status, rather than (or as > well as) expecting an event reporting phase > changes such as submission received, > pdf checked, paper in review, accept/reject > notification etc > > obviously one can leave in place the e-mail > systems, but it is simply not working - some > of the bayesian rule based filters do not even > give consistent results over the same pair of > sender/recipient, or over a sequence of > messages with the same content...but (and of > course for a spam filter, this is "correct" > since teling a bad guy anything is deemed > self-defeating) > there's no SMTP error notification so end2end > delivery is assumed to have occurred.... > > users with white listing technologies should > consider adding conference submission sites to > the white list but it aint as simple as that > of course... > > j. > > p.s. we were even stymied partly by our own > mail system anti-spam measures which include > rate-limiting automatic mail outbound from our > site... > > argh!!! From Jon.Crowcroft at cl.cam.ac.uk Thu Jan 10 06:42:12 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 10 Jan 2008 14:42:12 +0000 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> Message-ID: so google do application layer retries in a lot of things the problem with that approach is that automatic systems above the network layer have no meaningful equivalent to the RTT estimation process that drives the retransmit timer process, and packet conservation mechanisms in transport that is a part of the congestion control loop, so we could end up either clobbering the net and the end system, or using incredily conservative timers for the retries... with silent failure, we need to require positive acknowledgement in the application layer as you say- but i dont want to automate it:) there's problably some wonderful ways such a loop could interact with a vacation mail trigger too.....(can u say feature interaction? :-) hey, TCP on SMTP, anyone? In missive <1199975821.3801.119.camel at pc105-c703.uibk.a c.at>, Michael Welzl typed: >>Yeah... >> >>Silent loss of email is one of the real problems that the >>Internet is facing today. Much more real, and much more >>severe, than many of the other issues that people like >>myself deal with on a daily basis. >> >>I've been looking into the problem a bit - there's a neat >>suggested solution from MS research called SureMail: >>http://research.microsoft.com/netres/projects/SureMail/ >>(hm, maybe it was *you* who once pointed me to it?! sorry >>for sending it back to you in this case :-) ), and >>I considered just adding a reliability loop between my >>outgoing SMTP server and your POP server (because these >>are the entities between which reliability is assumed - if >>your *personal* spam folder delete's stuff, you usually >>accept that it's your fault), where I would get my emails >>marked in my "sent" folder when they reached your POP ... >>this way I know that some definitely made it, and several >>others *might* have made it to the other end - that would >>already be helpful I guess >> >>Turns out that there's a standard in place for doing that >>SMTP-POP loop described above, but it isn't normally used, >>no idea why ... I had to stop looking deeper at some point >>because all the other work pulled the carpet from under >>my feet, but I'm still quite interested in that >> >>Bottom line: email is badly broken, and one of the most >>heavily used Internet services, someone should truly >>fix it (and while I think that the SureMal approaches >>(actually multiple - the first and second papers >>are quite different, one has a DHT and one doesn't) area >>quite nice, they only partially solve the problem). >> >>Cheers, >>Michael >> >> >>On Thu, 2008-01-10 at 14:18 +0000, Jon Crowcroft wrote: >>> Michael, and others >>> >>> we had several problems with NSDI this year >>> due to silent failure of email. Many of us >>> have taken for granted that e-mail had become >>> somewhat of a atomic building block for >>> delivery of notifications of various things, >>> but this is (alas) simply incorrect and things >>> are getting worse - I hate to say this, but we >>> may find ourselves pushing responsibility >>> around in future (e.g. authors must poll a >>> site to check on status, rather than (or as >>> well as) expecting an event reporting phase >>> changes such as submission received, >>> pdf checked, paper in review, accept/reject >>> notification etc >>> >>> obviously one can leave in place the e-mail >>> systems, but it is simply not working - some >>> of the bayesian rule based filters do not even >>> give consistent results over the same pair of >>> sender/recipient, or over a sequence of >>> messages with the same content...but (and of >>> course for a spam filter, this is "correct" >>> since teling a bad guy anything is deemed >>> self-defeating) >>> there's no SMTP error notification so end2end >>> delivery is assumed to have occurred.... >>> >>> users with white listing technologies should >>> consider adding conference submission sites to >>> the white list but it aint as simple as that >>> of course... >>> >>> j. >>> >>> p.s. we were even stymied partly by our own >>> mail system anti-spam measures which include >>> rate-limiting automatic mail outbound from our >>> site... >>> >>> argh!!! >> cheers jon From michael.welzl at uibk.ac.at Thu Jan 10 06:56:33 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 15:56:33 +0100 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> Message-ID: <1199976993.3801.128.camel@pc105-c703.uibk.ac.at> On Thu, 2008-01-10 at 14:42 +0000, Jon Crowcroft wrote: > so google do application layer retries in a > lot of things > > the problem with that approach > is that automatic systems above > the network layer have no meaningful > equivalent to the RTT estimation process that > drives the retransmit timer process, and > packet conservation mechanisms in transport > that is a part of the congestion control > loop, so we could end up either clobbering the > net and the end system, or using incredily > conservative timers for the retries... IMO, incredibly conservative timers would do the trick for email. > with silent failure, we need to require > positive acknowledgement in the application > layer as you say- but i dont want to automate > it:) there's problably some wonderful ways > such a loop could interact with a vacation > mail trigger too.....(can u say feature > interaction? :-) There are already special messages for that kind of app-layer ACK, and I doubt ( = hope not :-) ) that reasonably implemented automated vacation messaging systems would react to them - as they could already get them today. I was just looking for the information that I once dug up - I'm sure I had it in an email somewhere, but it seems I lost it (ah, the irony :-) ). Seriously, let's assume that I'm wrong and no such message exists: then we could still use messages like the message-disposition-notification for the ACK from the POP or IMAP server back to my SMTP, and such a response would typically be ignored by current automated answering systems. Also, let's say that you only request that service by including a special header - it's not a default method then, but something that you choose if you want to be totally sure that the message was reliably delivered (like marking an important email with a "!" as most current mail clients allow you to do). > hey, TCP on SMTP, anyone? Count me in - I dig layers :-) Cheers, Michael From lars.eggert at nokia.com Thu Jan 10 08:19:01 2008 From: lars.eggert at nokia.com (Lars Eggert) Date: Thu, 10 Jan 2008 18:19:01 +0200 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <1199976993.3801.128.camel@pc105-c703.uibk.ac.at> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199976993.3801.128.camel@pc105-c703.uibk.ac.at> Message-ID: <3BB70D17-1B08-40F4-AB67-9D1431B29C1D@nokia.com> On 2008-1-10, at 16:56, ext Michael Welzl wrote: > On Thu, 2008-01-10 at 14:42 +0000, Jon Crowcroft wrote: >> hey, TCP on SMTP, anyone? > > Count me in - I dig layers :-) http://tools.ietf.org/html/draft-eastlake-ip-mime Lars From michael.welzl at uibk.ac.at Thu Jan 10 09:16:55 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 18:16:55 +0100 Subject: [e2e] was Re: A message to authors - nsdi References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at><1199976993.3801.128.camel@pc105-c703.uibk.ac.at> <3BB70D17-1B08-40F4-AB67-9D1431B29C1D@nokia.com> Message-ID: <028901c853ac$99df55d0$0200a8c0@fun> > On 2008-1-10, at 16:56, ext Michael Welzl wrote: > > On Thu, 2008-01-10 at 14:42 +0000, Jon Crowcroft wrote: > >> hey, TCP on SMTP, anyone? > > > > Count me in - I dig layers :-) > > http://tools.ietf.org/html/draft-eastlake-ip-mime > > Lars ouch! hm ... can I send SMTP over that? ;-) I guess that we could start playing the "over" game in this list: somebody names two protocols, with the word "over" in between, and the task is to answer with a pointer to an RFC or draft... (or write it instead!) on a more serious note, I really really believe that this email work should be done. Should someone suggest an IRTF group for doing that? I was going to start some discussion about this in the ASRG, as this seems to be closest to email, although it's not an anti-spam idea ... but I never found the time, as I wanted to properly read through the standards first But is there interest in such a thing? Do people agree with me that developing solutions here would be 1) useful, and 2) feasible? Personally, I'm deeply annoyed when emails are silently lost, and it's hard for me to accept that we have no means to properly repair it. Sure, we also have no such means for Spam, but people are at least trying - but the increasingly significant reliability problem appears to remain undealt with Cheers, Michael From jg at laptop.org Thu Jan 10 09:35:32 2008 From: jg at laptop.org (Jim Gettys) Date: Thu, 10 Jan 2008 12:35:32 -0500 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> Message-ID: <1199986532.5843.45.camel@localhost> On Thu, 2008-01-10 at 14:42 +0000, Jon Crowcroft wrote: > so google do application layer retries in a > lot of things > > the problem with that approach > is that automatic systems above > the network layer have no meaningful > equivalent to the RTT estimation process that > drives the retransmit timer process, and > packet conservation mechanisms in transport > that is a part of the congestion control > loop, so we could end up either clobbering the > net and the end system, or using incredily > conservative timers for the retries... > And since the kernel interfaces are lacking to RTT and/or other information such as the delay/bandwidth product, I've seen multiple application developers have to kludge their own estimates.... One might think it would be wise to expose some of the information already available to TCP to application programmers; not all of them are clueless, contrary to popular opinions I've sometime seen echoed by some on this list. - Jim -- Jim Gettys One Laptop Per Child From stiemerling at netlab.nec.de Thu Jan 10 06:29:13 2008 From: stiemerling at netlab.nec.de (Martin Stiemerling) Date: Thu, 10 Jan 2008 15:29:13 +0100 Subject: [e2e] CFP: IEEE Network Special Issue on Implications and Control of Middleboxes in the Internet Message-ID: Our apologies if you receive multiple copies of the CFP. -------------------------------------------------------- Call for Papers IEEE Network Magazine Special Issue on Implications and Control of Middleboxes in the Internet Important Data ============== Manuscript Submission Due: March 1, 2008 Acceptance Notification: June 1, 2008 Final Manuscript Due: July 15, 2008 Special Issue Publication Date: September/October 2008 Call for Papers =============== Network Address Translators (NAT) and IP firewalls have been introduced to the Internet some time ago, and over the time become an integral part of the Internet architecture. Moreover, there are also other types of middleboxes, such as Virtual Private Network (VPN) gateways, Application Layer Gateways (ALG), Performance Enhancing Proxies (PEP) and web proxies. These intermediary boxes perform functions different from normal IP packet treatment, which can even change the content of packets or do rerouting of IP packets. There have been diverse views on the value of middleboxes. Some believe that middleboxes introduce problems for network applications as well as challenges to the traditional end-to-end Internet architecture. These issues range, for instance, but not limited to, from naming and addressing of nodes behind NATs, directionality of communication establishment, and performance impairments. On the other hand, many administrators and operators see the middleboxes represent an important part for their network operations. For example, firewalls are widely deployed with the intention of securing enterprise, campus and home networks, so as to block attacks to nodes or keep nodes from sending malicious traffic. The Internet community has acknowledged the emergence of the middleboxes and developed middlebox control and coordination protocols that allow end hosts (or application proxies) to learn about the presence of middleboxes and communicate their needs (i.e. required packet treatment) to those devices. A number of middlebox control protocols, such as UPnP, MIDCOM and STUN, have been developed over the years and are partially used in current deployments. The papers in this special issue will focus on the state-of-the-art research in various aspects of middleboxes and middlebox control mechanisms, which help to understand their impact to the Internet architecture and network operations, and how they can be further integrated, or leveraged for different purposes, such as load balancing and mobile network environments, among the others. Specifically, within the aforementioned context in Internet middleboxes and their control mechanisms, the special issue will present tutorials, surveys and original research articles (written in a tutorial manner readable by non-specialists) that cover the following subjects, but not limited to: * Middlebox-supported network architectures vs. other Internet evolution alternatives (e.g., IPv6) * Design and/or performance evaluation of middlebox software architectures * Control and coordination across middleboxes and their traversal mechanisms * Security, including authentication, authorization and accounting issues with middlebox control/traversal mechanisms * Scalability and performance studies of middlebox control/traversal mechanisms * Deployment scenarios and case studies (corporate, ISP, content providers, mobile environments etc.) based on middleboxes * Interaction and implications with other network protocols and components * Interaction and implications with end-to-end applications and services * Related standardization efforts Manuscript Submission ===================== With regard to both the content and formatting style of the submissions, prospective contributors must follow the IEEE Network guidelines for authors that can be found at http://www.comsoc.org/pubs/net/ntwrk/authors.html. Submitted papers must be original and must not be under current consideration for publication in other venues. Authors should submit a PDF format of their complete papers via http://www.edas.info/newPaper.php?c=6198. Guest Editors ============= Prof. Xiaoming Fu Institute for Computer Science University of Goettingen Goettingen Germany Email: fu at cs.uni-goettingen.de Martin Stiemerling NEC Europe Laboratories Network Research Division Heidelberg Germany Email: stiemerling at netlab.nec.de Prof. Henning Schulzrinne Department of Computer Science Columbia University New York, NY USA Email: hgs at cs.columbia.edu stiemerling at netlab.nec.de NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080110/7384f32d/attachment-0001.html From dpreed at reed.com Thu Jan 10 10:45:53 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 10 Jan 2008 13:45:53 -0500 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <1199986532.5843.45.camel@localhost> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> Message-ID: <478667E1.4020902@reed.com> Wow! we have gone from a problem with conference management to invention of new APIs for the Berkeley Sockets layer. I'm not sure how RTT and B*RTT/2 are related to silent email filtering, but may I suggest that we formulate this as a well-defined problem to be solved rather than the invention of generalized answers to even more general hypotheticals? The road of systems research (operating systems and others) is littered with people who have fallen in love with arcane solutions to non-problems. Many of them cruft up the systems we use today. Windows, for example, but also Linux and OS X. And you can find lots of non-working things in network standards, too. IEEE 802.11 Ad hoc mode, for example - especially multicast. And the "TOS" field in IPv4. ANd the duration of port reuse intervals in NAT "standards". If you posit that a proposal actually "solves" a problem, you won't mind having the end-to-end argument posed - does it completely solve it, or must the endpoints be involved. If they must be involved, why is your "in the guts of the system" solution needed? If it is an optimization, does it also have bad cases that wouldn't have been there if the solution hadn't been invented in the first place? Email, like paper mail before it, does NOT guarantee delivery. The fault is not with email or the US post office. The fault is with the users (in this case the program committees). From dpreed at reed.com Thu Jan 10 10:51:11 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 10 Jan 2008 13:51:11 -0500 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <1199986532.5843.45.camel@localhost> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> Message-ID: <4786691F.6010206@reed.com> The simplest possible answer to program committee stuff is for the committee to say: you will recieve a response by date A to acknowledge your submission and date X to accept or reject. If you don't get responses by those dates, send inquiries to Y. We will endeavor to reply by mail within one day. Note that all of the timeouts above are not "automagic". They are protocol specifications. They don't require guesses, but embed the timeout in the end-to-end protocol def. There is no need for generic solutions. From Sharad.Agarwal at microsoft.com Thu Jan 10 10:51:45 2008 From: Sharad.Agarwal at microsoft.com (Sharad Agarwal) Date: Thu, 10 Jan 2008 10:51:45 -0800 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <66F5DB2A9E206A498B5AE59E3E42B02D2CD3AE761E@NA-EXMSG-C113.redmond.corp.microsoft.com> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <66F5DB2A9E206A498B5AE59E3E42B02D2CD3AE761E@NA-EXMSG-C113.redmond.corp.microsoft.com> Message-ID: <3883BDABDBD09C499A2493B70E4859B83198CB4FCB@NA-EXMSG-C113.redmond.corp.microsoft.com> Attempting a re-send since it's been 30 minutes and it still didn't go through... ironic given the subject matter... -----Original Message----- From: Sharad Agarwal Sent: Thursday, January 10, 2008 10:13 AM To: end2end-interest at postel.org Subject: RE: [e2e] was Re: A message to authors - nsdi > I was just looking for the information that I once dug up - I'm > sure I had it in an email somewhere, but it seems I lost it > (ah, the irony :-) ). Seriously, let's assume that I'm > wrong and no such message exists: then we could still use > messages like the message-disposition-notification for the > ACK from the POP or IMAP server back to my SMTP, and such > a response would typically be ignored by current automated > answering systems. > Also, let's say that you only request that service by including > a special header - it's not a default method then, but something > that you choose if you want to be totally sure that the message > was reliably delivered (like marking an important email with a > "!" as most current mail clients allow you to do). But as a spammer, wouldn't I mark all my emails as ! and then I'd get positive confirmation about whether my spam was successful in making it past the spam filter? If successful, I continue using that text to spam; if no confirmation, then it's time to change my text and try again. I suspect this is partly why MDN / DSN messages are not fashionable. An underlying problem is how to separate legitimate senders from other senders. For legitimate senders, you could allow such an ACK service to be used (or better yet, apply different spam rules); but the traditional way of recognizing legitimate senders by their email address isn't foolproof since the from address can easily be forged. So a better way of doing end2end "authentication" (without using heavyweight key exchange & signing) could help. In SureMail we relied on the user context of an email thread to validate a sender to a receiver in future emails, which works fine in that system but may not be scalable for applying to spam filters. From michael.welzl at uibk.ac.at Thu Jan 10 11:00:32 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 20:00:32 +0100 Subject: [e2e] was Re: A message to authors - nsdi References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <478667E1.4020902@reed.com> Message-ID: <000501c853bb$13960e10$0200a8c0@fun> > If you posit that a proposal actually "solves" a problem, you won't mind > having the end-to-end argument posed - does it completely solve it, or > must the endpoints be involved. If they must be involved, why is your > "in the guts of the system" solution needed? If it is an optimization, > does it also have bad cases that wouldn't have been there if the > solution hadn't been invented in the first place? We need to think about what the endpoints are in the email scenario... > Email, like paper mail before it, does NOT guarantee delivery. The > fault is not with email or the US post office. The fault is with the > users (in this case the program committees). Well - even if email doesn't guarantee delivery, the general public's expectation is that it does. It's not just program committees :-) it's a fact of the world which I have personally encountered on several occasions, just like (I assume) many of us: people believe email to be reliable. So, in order to give people the desired (even expected!) service, we should make it reliable. The end points, however, should be my outgoing SMTP server and your incoming POP or IMAP server. This is the communication that we assume to be trustworthy and reliable - not the communication between your email client and mine. If my personal email client's spam filter deletes emails, it's my fault and I would be inclined to accept it. If I didn't configure that filter, I'd assume that it's the client developer's fault, and complain to them (or someone else would). It's the same thing with the post office - people assume the communication path from my post office to yours to be reliable, or at least *quite* reliable. If the US post office would start losing 50% of your letters (I know, email isn't doing that, but it's getting worse, and we ought to pull the break before it's too late), people would get heavily annoyed, and misunderstandings would happen. Hmm, didn't the UK just give us an example of that? :-) Cheers, Michael From michael.welzl at uibk.ac.at Thu Jan 10 11:03:31 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 20:03:31 +0100 Subject: [e2e] was Re: A message to authors - nsdi References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <4786691F.6010206@reed.com> Message-ID: <001301c853bb$7e1eda00$0200a8c0@fun> > The simplest possible answer to program committee stuff is for the > committee to say: you will recieve a response by date A to acknowledge > your submission and date X to accept or reject. If you don't get > responses by those dates, send inquiries to Y. We will endeavor to > reply by mail within one day. That's a nice idea, but... > Note that all of the timeouts above are not "automagic". They are > protocol specifications. They don't require guesses, but embed the > timeout in the end-to-end protocol def. There is no need for generic > solutions. I disagree that there's no need for generic solutions, because of the mismatch between people's expectations about the service they get from email, and the service that the system offers (as well as the work involved in personally checking! Note that your solution above involves people typing stuff on keyboards - as the reliability declines, the scalability of that system will become limited by the hours that people can devote to that kind of solution). Cheers, Michael From ian.mcdonald at jandi.co.nz Thu Jan 10 11:27:56 2008 From: ian.mcdonald at jandi.co.nz (Ian McDonald) Date: Fri, 11 Jan 2008 08:27:56 +1300 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <4786691F.6010206@reed.com> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <4786691F.6010206@reed.com> Message-ID: <5640c7e00801101127k2d43610dtbfa531ae4dedb4b6@mail.gmail.com> On Jan 11, 2008 7:51 AM, David P. Reed wrote: > The simplest possible answer to program committee stuff is for the > committee to say: you will recieve a response by date A to acknowledge > your submission and date X to accept or reject. If you don't get > responses by those dates, send inquiries to Y. We will endeavor to > reply by mail within one day. > At the risk of untying the Gordian knot [1] why not use a conference service such as Edas [2]. This works for many conferences I've submitted to. E-mail as a medium is no longer a reliable medium. It is worthwhile to debate how to make it reliable but it won't solve any short term measures. [1] http://en.wikipedia.org/wiki/Gordian_Knot [2] http://edas.info Ian -- Web: http://wand.net.nz/~iam4/ Blog: http://iansblog.jandi.co.nz From dpreed at reed.com Thu Jan 10 13:04:17 2008 From: dpreed at reed.com (David P. Reed) Date: Thu, 10 Jan 2008 16:04:17 -0500 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <001301c853bb$7e1eda00$0200a8c0@fun> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <4786691F.6010206@reed.com> <001301c853bb$7e1eda00$0200a8c0@fun> Message-ID: <47868851.6070906@reed.com> Putting "features" in the Berkeley Sockets interface doesn't solve the problem generically. The problem has nothing to do with the lack of features "in the network". Papering over that fact by positing that "there exists a generic solution" doesn't actually prove that there really is a generic *solution*. Just a pile of crappy new features justified by a questionable claim of relevance. The same logic justifies scanning airport passengers for Arabic names and presuming that contributes to "security". Michael Welzl wrote: >> The simplest possible answer to program committee stuff is for the >> committee to say: you will recieve a response by date A to acknowledge >> your submission and date X to accept or reject. If you don't get >> responses by those dates, send inquiries to Y. We will endeavor to >> reply by mail within one day. >> > > That's a nice idea, but... > > > >> Note that all of the timeouts above are not "automagic". They are >> protocol specifications. They don't require guesses, but embed the >> timeout in the end-to-end protocol def. There is no need for generic >> solutions. >> > > I disagree that there's no need for generic solutions, because of the > mismatch between people's expectations about the service they get > from email, and the service that the system offers (as well as the > work involved in personally checking! Note that your solution above > involves people typing stuff on keyboards - as the reliability declines, > the scalability of that system will become limited by the hours that > people can devote to that kind of solution). > > Cheers, > Michael > > > From michael.welzl at uibk.ac.at Thu Jan 10 13:32:07 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 22:32:07 +0100 Subject: [e2e] was Re: A message to authors - nsdi References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at><1199986532.5843.45.camel@localhost><66F5DB2A9E206A498B5AE59E3E42B02D2CD3AE761E@NA-EXMSG-C113.redmond.corp.microsoft.com> <3883BDABDBD09C499A2493B70E4859B83198CB4FCB@NA-EXMSG-C113.redmond.corp.microsoft.com> Message-ID: <001101c853d0$4043fe80$0200a8c0@fun> > But as a spammer, wouldn't I mark all my emails as ! and then I'd get positive confirmation about whether my spam was successful in making it past the spam filter? If successful, I continue using that text to spam; if no confirmation, then it's time to change my text and try again. I suspect this is partly why MDN / DSN messages are not fashionable. But couldn't that kind of process also be applied now, just with a NACK (because, being a spammer, I'm the sender and receiver)? I get some free email accounts and send spam everywhere, and check (maybe automatically) if it made it - if it didn't, I'll know. If I'm right about that, then there's no harm in adding an ACK to email. > An underlying problem is how to separate legitimate senders from other senders. For legitimate senders, you could allow such an ACK service to be used (or better yet, apply different spam rules); but the traditional way of recognizing legitimate senders by their email address isn't foolproof since the from address can easily be forged. So a better way of doing end2end "authentication" (without using heavyweight key exchange & signing) could help. In SureMail we relied on the user context of an email thread to validate a sender to a receiver in future emails, which works fine in that system but may not be scalable for applying to spam filters. That's not necessary if I'm right in what I say above: if that system doesn't give spammers a mechanism that they now don't have, there's probably no point in disallowing its use for certain people. Cheers, Michael From michael.welzl at uibk.ac.at Thu Jan 10 13:41:51 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Thu, 10 Jan 2008 22:41:51 +0100 Subject: [e2e] was Re: A message to authors - nsdi References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <4786691F.6010206@reed.com> <001301c853bb$7e1eda00$0200a8c0@fun> <47868851.6070906@reed.com> Message-ID: <001701c853d1$9cb5f5a0$0200a8c0@fun> > Putting "features" in the Berkeley Sockets interface doesn't solve the > problem generically. The problem has nothing to do with the lack of > features "in the network". Papering over that fact by positing that > "there exists a generic solution" doesn't actually prove that there > really is a generic *solution*. Just a pile of crappy new features > justified by a questionable claim of relevance. I'm not saying that there *has* to be a generic solution (that might just not be exist), I just said that I disagree that there's no need (or maybe better: demand) for it. There can be partial solutions like SureMail which actually make sense. The way you refer to "features in the network" above indicates to me that you're taking a "pro end-to-end" position here, whereas mine is "anti end-to-end". - but I don't think that this is the right way to see it. The end systems that we are talking about here are humans, and I'm not sure if we can take e2e as a guiding principle when that is the case - after all, the goal seems to be to build a system that's convenient for people to use. We don't require people to be involved in TCP ACKs, right? Just because SMTP and POP/IMAP servers aren't built in end hosts like TCP is, that doesn't mean that they are not the communication endpoints that people interact with. You seem to say that they are "in the network". I say they are the end systems that we must consider, because they are the entities that we (as human users of the system) expect a certain service from. > The same logic justifies scanning airport passengers for Arabic names > and presuming that contributes to "security". I don't get that analogy. Cheers, Michael From Sharad.Agarwal at microsoft.com Thu Jan 10 14:07:37 2008 From: Sharad.Agarwal at microsoft.com (Sharad Agarwal) Date: Thu, 10 Jan 2008 14:07:37 -0800 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <001101c853d0$4043fe80$0200a8c0@fun> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at><1199986532.5843.45.camel@localhost><66F5DB2A9E206A498B5AE59E3E42B02D2CD3AE761E@NA-EXMSG-C113.redmond.corp.microsoft.com> <3883BDABDBD09C499A2493B70E4859B83198CB4FCB@NA-EXMSG-C113.redmond.corp.microsoft.com> <001101c853d0$4043fe80$0200a8c0@fun> Message-ID: <3883BDABDBD09C499A2493B70E4859B83198CB5190@NA-EXMSG-C113.redmond.corp.microsoft.com> > But couldn't that kind of process also be applied now, just with a NACK > (because, being a spammer, I'm the sender and receiver)? > I get some free email accounts and send spam everywhere, and check > (maybe automatically) if it made it - if it didn't, I'll know. True, you can do that. But only to the Hotmails and Yahoos of the world. You wouldn't be able to do that to say the microsoft.com or eecs.berkeley.edu mail systems. With the ACK or NACK system, then you could test any email domain that implements it. From Jon.Crowcroft at cl.cam.ac.uk Thu Jan 10 14:54:23 2008 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 10 Jan 2008 22:54:23 +0000 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <001701c853d1$9cb5f5a0$0200a8c0@fun> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <4786691F.6010206@reed.com> <001301c853bb$7e1eda00$0200a8c0@fun> <47868851.6070906@reed.com> <001701c853d1$9cb5f5a0$0200a8c0@fun> Message-ID: in response to various comments... 1. we did an asynch interface to conference managemet (i.e. email) because people wanted it (as well as web interfaces) because a lot of people on PCs have tasks that stretch over months and many journeys and want to work on things offline and then submit online, ....pure web/synch/online only systems are a pain. 2. conf PCs aren't wrong - the email problem changes - email USED to be designed (ask steve kille, one of the serious gurus of email) to be absoltuely the most reliable app you could find on any net whether it was x.25, uucp/dialup, tcp, whatever - now it isn't - the reason it isnt relaible (in the sense of succed of error notification if it doesnt) is NEW and denying this, or claiming users are wrong is incorrect interpretation of the problem which is a CHANGE in semantics - silinet failure was NOT part of the design space. 3. people used email for a lot of thigns (sys admin for example) on the basis that the smtp delivery semantics (and x.400) were good - and so it was a useful building block for scripting lots of things even pre (yech) web 2.0 - now it isnt any more - this is a surprise. (actually it isnt if you go back to uucp days, but it is if you only go back to , say, late 80s) - 4. if you want to design a useful building block , you need to consider a lot of clever tricks about tiemrs - email people did that - but you also need to cope with what telco folks used to call "signaled" and "unsignaled" errors - fail silent errors are fine so long as thy are part of the spec - i could break most TCPs out there if i built a thign that did cummulative acks for seqno above the packets that were missing....what would happen to lots of programms like rsynch or network backup?... 5. changing the socket API wasn't my goal (since the RTT for email delivery is not something tcp data/ack roudn trip time has much to do with....but having an open API (like SysV layer 4 api ) might be useful - actually lots of systems had hacks like it....in the same way giving applications access to routing tables is also useful - actually all hosts should have access to all routeing info inclding link and path metrics...even my cell phone has more memory than the average campus router now....just in case it would be useful...in the words of 10000 maniacs, you never no... In missive <001701c853d1$9cb5f5a0$0200a8c0 at fun>, "Michael Welzl" typed: >>> Putting "features" in the Berkeley Sockets interface doesn't solve the >>> problem generically. The problem has nothing to do with the lack of >>> features "in the network". Papering over that fact by positing that >>> "there exists a generic solution" doesn't actually prove that there >>> really is a generic *solution*. Just a pile of crappy new features >>> justified by a questionable claim of relevance. >> >>I'm not saying that there *has* to be a generic solution (that >>might just not be exist), I just said that I disagree that there's >>no need (or maybe better: demand) for it. There can be partial >>solutions like SureMail which actually make sense. >> >>The way you refer to "features in the network" above indicates >>to me that you're taking a "pro end-to-end" position here, >>whereas mine is "anti end-to-end". >> >>- but I don't think that this is the right way to see it. The end >>systems that we are talking about here are humans, and I'm >>not sure if we can take e2e as a guiding principle when that >>is the case - after all, the goal seems to be to build a system >>that's convenient for people to use. >> >>We don't require people to be involved in TCP ACKs, right? >> >>Just because SMTP and POP/IMAP servers aren't built in >>end hosts like TCP is, that doesn't mean that they are not the >>communication endpoints that people interact with. You seem >>to say that they are "in the network". I say they are the end >>systems that we must consider, because they are the entities that >>we (as human users of the system) expect a certain service from. >> >> >>> The same logic justifies scanning airport passengers for Arabic names >>> and presuming that contributes to "security". >> >>I don't get that analogy. >> >>Cheers, >>Michael >> cheers jon From michael.welzl at uibk.ac.at Thu Jan 10 23:36:34 2008 From: michael.welzl at uibk.ac.at (Michael Welzl) Date: Fri, 11 Jan 2008 08:36:34 +0100 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <3883BDABDBD09C499A2493B70E4859B83198CB5190@NA-EXMSG-C113.redmond.corp.microsoft.com> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <66F5DB2A9E206A498B5AE59E3E42B02D2CD3AE761E@NA-EXMSG-C113.redmond.corp.microsoft.com> <3883BDABDBD09C499A2493B70E4859B83198CB4FCB@NA-EXMSG-C113.redmond.corp.microsoft.com> <001101c853d0$4043fe80$0200a8c0@fun> <3883BDABDBD09C499A2493B70E4859B83198CB5190@NA-EXMSG-C113.redmond.corp.microsoft.com> Message-ID: <1200036994.3691.34.camel@pc105-c703.uibk.ac.at> On Thu, 2008-01-10 at 14:07 -0800, Sharad Agarwal wrote: > > But couldn't that kind of process also be applied now, just with a NACK > > (because, being a spammer, I'm the sender and receiver)? > > I get some free email accounts and send spam everywhere, and check > > (maybe automatically) if it made it - if it didn't, I'll know. > > True, you can do that. But only to the Hotmails and Yahoos of the world. You wouldn't be able to do that to say the microsoft.com or eecs.berkeley.edu mail systems. With the ACK or NACK system, then you could test any email domain that implements it. But if spammers really want to do this, say, to microsoft.com, surely they could find an automated response system somewhere at microsoft.com which they could use for the same purpose? Or, alternatively, send enough pointless emails to people working at microsoft.com until they get a vacation message - so they get addresses which they could use to get an autoresponse anyway for doing this kind of test. What if it's not Microsoft but company XY which is too small for this kind of thing to work? Well, then we could simply flood them instead of doing this test - after all the reason for doing the test instead of simply flooding is probably to reduce the required number of messages, which will only be a problem if the company is really big. I'm making wild guesses at this point, though... Cheers, Michael From detlef.bosau at web.de Fri Jan 11 05:06:48 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 11 Jan 2008 14:06:48 +0100 Subject: [e2e] Detlef and Opportunistic Scheudling. was: Re: Once again: Detlef and Latencies :-) In-Reply-To: <47820B53.5050305@web.de> References: <47820B53.5050305@web.de> Message-ID: <478769E8.7090605@web.de> Hi. There were lots of mistakes in my plots, but I think finally got it fixed. For my system model, I refer to the Eurane website http://www.ti-wmc.nl/eurane/ I don?t only use their system model but their code as well and in case, I tell anything about my system modell and the Eurane programmers tell something else, they are presumably correct :-) The Eurane code provides a simplified HSDPA simulator and therefore should be suitable to investigate algorithms for opportunistic scheduling. What I did are simulations with one sending node and eight mobile receivers in one common HSDPA cell. All the users move with velocity 3 meters per second (pedestrian) on a circular path with 500 meters distance between BS and UE. As some nasty complication, I changed the transmission power for the lines 1 to 4 to 32 dBm, whereas the lines 5 to 8 send with 38 dBm. I simply wanted to simulate a constant shading for a number of lines. This scenario is particularly interesting because Thomas Bonald pointed out that Proportional Fair Scheduling, which is state of the art to my knowledge, does not behave well in scenarios with asymmetric scheduling. Now, let?s have a look at http://www.detlef-bosau.de/eurane_results.html I did simuations with 500 seconds transmission time. The plots in the first column show the achieved TCP goodput. You find 1. a round robin scheduler (at least, it is called that way within the Eurane package. In fact, it is a "last recently served" scheduler, which behaves more or less identical to round robin.) 2. a C/I scheduler (sometimes refered to as "maximum SNR scheduler") which schedules the line with the best channel conditions in the whole set of channels. 3. a "Fair Channel" scheduler, which is part of the Eurane package and addresses the problem of PF scheduling metrics being not comparable for different flows. So, we expect that this scheduler at least alleviates the PF weaknesses in case of asymmteric fading. 4. the score based scheduler by Thomas Bonald (the code was provided by Thomas Bonald and Luca Muscariello), 5. a Proportinal Fair scheduler and the 6. PF flavour proposed by Kolding. The code for both schedulers, PF and Kolding, was provided by Abdulmohsen Mutairi. 7., 8. an Elastic RR scheduler, which is not yet published and proposed by me ;-). (If there is any interest in this scheduler, I would well write a paper about it. But if not, I can spend the time on other things. ;-)) (BTW: If there is someone experienced with octave and could help me to have the flows 1 to 4 printed with circles and the rest with asterisks and both done as it can be done in gnuplot so that only every 10 samples a circle or asterisk is plotted, I would be glad. And the plots would be much more clear.) If we compare the achieved goodput, we immediately see the benefits of exploiting multi user diversity: With respect to the achieved goodput, nearly everything is better than round robin scheduling. However, the goodput is not always good for all lines. E.g., with PF scheduling http://www.detlef-bosau.de/eurane_results/goodput_s_9_t_0.1.eps.gz there are flows with quite impressive goodput (flow 1) while others hardly achieve anything (the rest). This is not surprising. Particularly with asymmetric fading, "noisy" lines have to wait for intervals where "low noise lines" experience extremly low noise to get a time slot assigned. When we use a C/I scheduler, the noisy lines (1 to 4) hardly achieve any goodput at all. However, even the different goodput for the different lines with PF schedulers is, in my opinion, not really convincing and not adequate for any practical implementation. The situation is alleviated with the Fair Channel Scheduler and with Bonald?s Scheduler. Both achieve fair goodput at least within a group of equal channel conditions (line 1 to 4 being the one group, line 5 to 8 beign the other) and quite acceptable ressource fairness when we look at the time slot allocations: Fair Channel: http://www.detlef-bosau.de/eurane_results/allocated_slots_s_3_t_0.1.eps.gz Bonald, Score Based: http://www.detlef-bosau.de/eurane_results/allocated_slots_s_8_t_0.1.eps.gz Surprisingly, the fair channel scheduler achieves a better ressource fairness than the score based scheduler. To my understanding, both schedulers attempt to normalize a scheduling priority statistic by normalizing location parameters. The fair channel scheduler uses mean and variance, while the sore based scheduler relies upon an estimate for an upper and lower limit for a sample of SNR values. (In his paper, Thomas Bonald talks about a "ranking", however in fact this is nothing else than finding such limits and making sample sets comparable with these.) AFAIK, an empirical average statistic and an empirical variance statistic are quite robust, presumably more stable than estimates for an upper and / or lower limit, so it?s perhaps not that suruprising that the fair channel scheduler achieves a better fairness than the score based scheduler in this scenario. There is also a plot for the ressource allocation achieved with the PF scheduler: http://www.detlef-bosau.de/eurane_results/allocated_slots_s_9_t_0.1.eps.gz I think, there?s no need for a detailed discussion ;-) What I did not add so far is an implementation of Thierry Klein?s modifications to the PF scheduler. If there is interest in that, I will add these in the future, because in that case, we had traces for all availabe PF flavours. However, I do not expect better ressource fairness here, because the problem addressed by Thierry was (same als Kolding) to cope with buffer underruns in TCP flows which can cause severe delay spikes. Now, a general weakness of all schedulers using a "scheduling priority", i.e. C/I, and PF flavours, is that there is hardly a limit for a packet delay because we cannot predict when a channel will have favourite conditions. We particularly enjoy the packet delays (from BS to UE, i.e the time a packet needs to travel through the recovery layer) achieved with Proportional Fair scheduling: http://www.detlef-bosau.de/eurane_results/delay_s_9_t_0.1.eps.gz (Can somebody please tell me, where I can complain about the totally inadequate paper format? The lines 5 and 6 appear somewhat, say, horizontally challenged here. In case of any publication, I have to find a plot which is more politcal correct.) The round robin scheduler http://www.detlef-bosau.de/eurane_results/delay_s_1_t_0.1.eps.gz gives an expectation what _can_ be achieved here. However, please bear in mind that retransmits needed for Chase combining are not subject to the scheduling algorihtm in the EURANE code, but are done immediately after a failed transmission. I do not yet know whether this is the case in real HSDPA implementations as well or whether this is an EURANE specific artifact. I woul particularly appreciate any commonts on this one. The elastic Round Robin scheuler however controls the actual slot rate _with_ consideration of retransmits, so that http://www.detlef-bosau.de/eurane_results/delay_s_11_t_0.01.eps.gz might be somewhat confusing here. However, the delays achieved with elastic RR are that small and limited, that I could imagine using this even for streaming applications. Which are not reasonable with PF scheduling. The goodput achieved with elastic RR is comparable to that of Fair Channel scheduling and the fairness is slightly better. Elastic RR is based upon a rate based round robin scheme which primarily enforces identical slotrate to all flows and allows to violate this slotrate within given limits (defined by the tolerance parameter). Only when _all_ slotrates of _all_ competing flows stay within this predefined limit, a scheduling decision is made based upon an opportunistic scheduling priority (actually, I used a fair channel scheduler for that purpose). In any other case, the line with the actually smallest rate is assigned a time slot. As a general lesson, we learn that we can well exloit multi user diversity and achieve reasonable high goodput for all competing flows with only _little_ violation of a traditional round robin scheme and good ressource fairness. O.k. The code is available at http://www.detlef-bosau.de/eurane.html which of course only contains the changed EURANE files. And now, I would be glad for any kind of questions, comments and discussion. -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From pars.mutaf at int-evry.fr Fri Jan 11 05:24:39 2008 From: pars.mutaf at int-evry.fr (Pars Mutaf) Date: Fri, 11 Jan 2008 14:24:39 +0100 Subject: [e2e] Fighting SPIT on a cell phone Message-ID: <1200057879.20475.14.camel@lor-maknavic3.int-evry.fr> Hello, I want to leave my cell phone number (SIP URI) on a discussion forum, or web page, blog, craigslist, phonebook, facebook etc. But wish to avoid SPIT (SPam over Internet Telephony). A solution is presented below (with variations called weak, strong). Looked like acceptable end2end-interest topic (sorry if not). Comments are appreciated. Regards, Pars Mutaf 1. Weak solution I leave the IP address of my cell phone but not a SIP URI. Interested party sends a request to my phone. My phone generates a random SIP URI and returns a different SIP URI to each querier. If I receive SPIT to the SIP URI 'x', then I can cancel it. Since each requestor is returned a different SIP URI, legitimate parties can continue to call me or send SMS. Since the SIP URI 'x' was canceled, a SPITer can request another one and still send me SPIT. To avoid this attack, the querier can be requested to solve a hard challenge e.g. a CAPTCHA. A SIP URI will be returned only after the querier user provided the solution. The difficulty of the CAPTCHA can be adaptively tuned by the target host. When done, i.e. the desired phone call is received, the target user can stop receiving requests to the indicated IP address. 2. Strong solution I leave the IP address of my phone but not a SIP URI. I want to receive phone calls or SMS only from people that I know. Interested party sends a request to my phone. My phone displays a message with the requestor's name e.g.: "Alice Collins requested phone number. Accept? [YES/NO]" If I accept, my phone generates a random SIP URI and returns it to the querier. This solution requires human name certification. An attacker can send continuous bogus requests to the target IP address and make the target phone continuously display the above message, annoying the target user. This attack can be defeated by requesting the querier user to solve a hard CAPTCHA before his request can be displayed at the target host's screen. The difficulty of the CAPTCHA can be adaptively tuned by the target host. == Comments are appreciated either here or please subscribe to: https://www1.ietf.org/mailman/listinfo/humanresolvers If you find the problem interesting but have another solution you are also welcome of course. From bmanning at vacation.karoshi.com Fri Jan 11 07:25:09 2008 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Fri, 11 Jan 2008 15:25:09 +0000 Subject: [e2e] Fighting SPIT on a cell phone In-Reply-To: <1200057879.20475.14.camel@lor-maknavic3.int-evry.fr> References: <1200057879.20475.14.camel@lor-maknavic3.int-evry.fr> Message-ID: <20080111152509.GA4151@vacation.karoshi.com.> you are making an assumption about the persistance of the binding between an IP address and a given interface. you seem to be making an assumption about the ability to algorithmically determine unwanted content ... which is a much harder problem and not (IMHO) something usually done at the transport layer. --bill On Fri, Jan 11, 2008 at 02:24:39PM +0100, Pars Mutaf wrote: > Hello, > > I want to leave my cell phone number (SIP URI) on a discussion > forum, or web page, blog, craigslist, phonebook, facebook etc. > But wish to avoid SPIT (SPam over Internet Telephony). A solution > is presented below (with variations called weak, strong). > > Looked like acceptable end2end-interest topic (sorry if not). > Comments are appreciated. > > Regards, > Pars Mutaf > > > 1. Weak solution > > I leave the IP address of my cell phone but not a SIP URI. Interested > party sends a request to my phone. My phone generates a random SIP URI > and returns a different SIP URI to each querier. > > If I receive SPIT to the SIP URI 'x', then I can cancel it. Since > each requestor is returned a different SIP URI, legitimate parties can > continue to call me or send SMS. > > Since the SIP URI 'x' was canceled, a SPITer can request another one > and still send me SPIT. To avoid this attack, the querier can be > requested to solve a hard challenge e.g. a CAPTCHA. A SIP URI will be > returned only after the querier user provided the solution. The > difficulty of the CAPTCHA can be adaptively tuned by the target host. > > When done, i.e. the desired phone call is received, the target user > can stop receiving requests to the indicated IP address. > > > 2. Strong solution > > I leave the IP address of my phone but not a SIP URI. I want to > receive phone calls or SMS only from people that I know. Interested > party sends a request to my phone. My phone displays a message with > the requestor's name e.g.: > > "Alice Collins requested phone number. Accept? [YES/NO]" > > If I accept, my phone generates a random SIP URI and returns it to the > querier. > > This solution requires human name certification. > > An attacker can send continuous bogus requests to the target IP > address and make the target phone continuously display the above > message, annoying the target user. This attack can be defeated by > requesting the querier user to solve a hard CAPTCHA before his request > can be displayed at the target host's screen. The difficulty of the > CAPTCHA can be adaptively tuned by the target host. > > == > Comments are appreciated either here or please subscribe to: > https://www1.ietf.org/mailman/listinfo/humanresolvers > > If you find the problem interesting but have another solution > you are also welcome of course. From pars.mutaf at int-evry.fr Fri Jan 11 07:57:23 2008 From: pars.mutaf at int-evry.fr (Pars Mutaf) Date: Fri, 11 Jan 2008 16:57:23 +0100 Subject: [e2e] Fighting SPIT on a cell phone In-Reply-To: <20080111152509.GA4151@vacation.karoshi.com.> References: <1200057879.20475.14.camel@lor-maknavic3.int-evry.fr> <20080111152509.GA4151@vacation.karoshi.com.> Message-ID: <1200067043.21338.26.camel@lor-maknavic3.int-evry.fr> Hi, On Fri, 2008-01-11 at 15:25 +0000, bmanning at vacation.karoshi.com wrote: > you are making an assumption about the persistance > of the binding between an IP address and a given interface. The IP address can be a mobile IP address for example. But other solutions are certainly possible. > you seem to be making an assumption about the ability to > algorithmically determine unwanted content ... In my vision, if Mr. X who was given the SIP URI 'x' starts to SPIT on my phone, I (the user) can cancel the SIP URI 'x'. Mr. Y can still call me because he was returned another SIP URI. This idea of "disposable cell phone number" is already in use today. We are proposing a protocol for distributing disposable SIP URIs from the cell phone, on an on-demand basis. > which is > a much harder problem and not (IMHO) something usually > done at the transport layer. Why transport layer? Thanks! pars > --bill > > > On Fri, Jan 11, 2008 at 02:24:39PM +0100, Pars Mutaf wrote: > > Hello, > > > > I want to leave my cell phone number (SIP URI) on a discussion > > forum, or web page, blog, craigslist, phonebook, facebook etc. > > But wish to avoid SPIT (SPam over Internet Telephony). A solution > > is presented below (with variations called weak, strong). > > > > Looked like acceptable end2end-interest topic (sorry if not). > > Comments are appreciated. > > > > Regards, > > Pars Mutaf > > > > > > 1. Weak solution > > > > I leave the IP address of my cell phone but not a SIP URI. Interested > > party sends a request to my phone. My phone generates a random SIP URI > > and returns a different SIP URI to each querier. > > > > If I receive SPIT to the SIP URI 'x', then I can cancel it. Since > > each requestor is returned a different SIP URI, legitimate parties can > > continue to call me or send SMS. > > > > Since the SIP URI 'x' was canceled, a SPITer can request another one > > and still send me SPIT. To avoid this attack, the querier can be > > requested to solve a hard challenge e.g. a CAPTCHA. A SIP URI will be > > returned only after the querier user provided the solution. The > > difficulty of the CAPTCHA can be adaptively tuned by the target host. > > > > When done, i.e. the desired phone call is received, the target user > > can stop receiving requests to the indicated IP address. > > > > > > 2. Strong solution > > > > I leave the IP address of my phone but not a SIP URI. I want to > > receive phone calls or SMS only from people that I know. Interested > > party sends a request to my phone. My phone displays a message with > > the requestor's name e.g.: > > > > "Alice Collins requested phone number. Accept? [YES/NO]" > > > > If I accept, my phone generates a random SIP URI and returns it to the > > querier. > > > > This solution requires human name certification. > > > > An attacker can send continuous bogus requests to the target IP > > address and make the target phone continuously display the above > > message, annoying the target user. This attack can be defeated by > > requesting the querier user to solve a hard CAPTCHA before his request > > can be displayed at the target host's screen. The difficulty of the > > CAPTCHA can be adaptively tuned by the target host. > > > > == > > Comments are appreciated either here or please subscribe to: > > https://www1.ietf.org/mailman/listinfo/humanresolvers > > > > If you find the problem interesting but have another solution > > you are also welcome of course. From bmanning at vacation.karoshi.com Fri Jan 11 08:05:33 2008 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Fri, 11 Jan 2008 16:05:33 +0000 Subject: [e2e] Fighting SPIT on a cell phone In-Reply-To: <1200067043.21338.26.camel@lor-maknavic3.int-evry.fr> References: <1200057879.20475.14.camel@lor-maknavic3.int-evry.fr> <20080111152509.GA4151@vacation.karoshi.com.> <1200067043.21338.26.camel@lor-maknavic3.int-evry.fr> Message-ID: <20080111160533.GA4500@vacation.karoshi.com.> On Fri, Jan 11, 2008 at 04:57:23PM +0100, Pars Mutaf wrote: > Hi, > > On Fri, 2008-01-11 at 15:25 +0000, bmanning at vacation.karoshi.com wrote: > > you are making an assumption about the persistance > > of the binding between an IP address and a given interface. > > The IP address can be a mobile IP address for example. But > other solutions are certainly possible. 3ff3:0:478::42 - is this mobile or fixed? what is the lease time? the point i was trying to make was that an IP address is WHERE you are in a topology, not WHO you are. > > you seem to be making an assumption about the ability to > > algorithmically determine unwanted content ... > > In my vision, if Mr. X who was given the SIP URI 'x' starts > to SPIT on my phone, I (the user) can cancel the SIP URI 'x'. > Mr. Y can still call me because he was returned another SIP > URI. let me try and be more clear. who or what makes the determination that Mr.X is "spit"ing on your telephone? > > This idea of "disposable cell phone number" is already in > use today. > We are proposing a protocol for distributing disposable > SIP URIs from the cell phone, on an on-demand basis. ah ... you are proposing to augment SIP call establishment w/ a challange/response ... > > > which is > > a much harder problem and not (IMHO) something usually > > done at the transport layer. > > Why transport layer? the e2e list was focused on IP end 2 end, not application layer end 2 end. SIP is (by definition) an application that runs on top of IP. > > Thanks! > pars > > > > > --bill > > > > > > On Fri, Jan 11, 2008 at 02:24:39PM +0100, Pars Mutaf wrote: > > > Hello, > > > > > > I want to leave my cell phone number (SIP URI) on a discussion > > > forum, or web page, blog, craigslist, phonebook, facebook etc. > > > But wish to avoid SPIT (SPam over Internet Telephony). A solution > > > is presented below (with variations called weak, strong). > > > > > > Looked like acceptable end2end-interest topic (sorry if not). > > > Comments are appreciated. > > > > > > Regards, > > > Pars Mutaf > > > > > > > > > 1. Weak solution > > > > > > I leave the IP address of my cell phone but not a SIP URI. Interested > > > party sends a request to my phone. My phone generates a random SIP URI > > > and returns a different SIP URI to each querier. > > > > > > If I receive SPIT to the SIP URI 'x', then I can cancel it. Since > > > each requestor is returned a different SIP URI, legitimate parties can > > > continue to call me or send SMS. > > > > > > Since the SIP URI 'x' was canceled, a SPITer can request another one > > > and still send me SPIT. To avoid this attack, the querier can be > > > requested to solve a hard challenge e.g. a CAPTCHA. A SIP URI will be > > > returned only after the querier user provided the solution. The > > > difficulty of the CAPTCHA can be adaptively tuned by the target host. > > > > > > When done, i.e. the desired phone call is received, the target user > > > can stop receiving requests to the indicated IP address. > > > > > > > > > 2. Strong solution > > > > > > I leave the IP address of my phone but not a SIP URI. I want to > > > receive phone calls or SMS only from people that I know. Interested > > > party sends a request to my phone. My phone displays a message with > > > the requestor's name e.g.: > > > > > > "Alice Collins requested phone number. Accept? [YES/NO]" > > > > > > If I accept, my phone generates a random SIP URI and returns it to the > > > querier. > > > > > > This solution requires human name certification. > > > > > > An attacker can send continuous bogus requests to the target IP > > > address and make the target phone continuously display the above > > > message, annoying the target user. This attack can be defeated by > > > requesting the querier user to solve a hard CAPTCHA before his request > > > can be displayed at the target host's screen. The difficulty of the > > > CAPTCHA can be adaptively tuned by the target host. > > > > > > == > > > Comments are appreciated either here or please subscribe to: > > > https://www1.ietf.org/mailman/listinfo/humanresolvers > > > > > > If you find the problem interesting but have another solution > > > you are also welcome of course. From pars.mutaf at int-evry.fr Fri Jan 11 08:44:41 2008 From: pars.mutaf at int-evry.fr (Pars Mutaf) Date: Fri, 11 Jan 2008 17:44:41 +0100 Subject: [e2e] Fighting SPIT on a cell phone In-Reply-To: <20080111160533.GA4500@vacation.karoshi.com.> References: <1200057879.20475.14.camel@lor-maknavic3.int-evry.fr> <20080111152509.GA4151@vacation.karoshi.com.> <1200067043.21338.26.camel@lor-maknavic3.int-evry.fr> <20080111160533.GA4500@vacation.karoshi.com.> Message-ID: <1200069881.21494.11.camel@lor-maknavic3.int-evry.fr> On Fri, 2008-01-11 at 16:05 +0000, bmanning at vacation.karoshi.com wrote: > On Fri, Jan 11, 2008 at 04:57:23PM +0100, Pars Mutaf wrote: > > Hi, > > > > On Fri, 2008-01-11 at 15:25 +0000, bmanning at vacation.karoshi.com wrote: > > > you are making an assumption about the persistance > > > of the binding between an IP address and a given interface. > > > > The IP address can be a mobile IP address for example. But > > other solutions are certainly possible. > > 3ff3:0:478::42 - is this mobile or fixed? what is the > lease time? the point i was trying to make > was that an IP address is WHERE you are in a > topology, not WHO you are. The IP address will be attached to a vCARD found somewhere. > > > you seem to be making an assumption about the ability to > > > algorithmically determine unwanted content ... > > > > In my vision, if Mr. X who was given the SIP URI 'x' starts > > to SPIT on my phone, I (the user) can cancel the SIP URI 'x'. > > Mr. Y can still call me because he was returned another SIP > > URI. > > let me try and be more clear. who or what makes > the determination that Mr.X is "spit"ing on your > telephone? Me. When I receive SPAM I can tell that it is SPAM (in general). > > This idea of "disposable cell phone number" is already in > > use today. > > We are proposing a protocol for distributing disposable > > SIP URIs from the cell phone, on an on-demand basis. > > ah ... you are proposing to augment SIP call > establishment w/ a challange/response ... > This is independent from SIP IMO. We can distribute other types of identifiers as well. pars > > > which is > > > a much harder problem and not (IMHO) something usually > > > done at the transport layer. > > > > Why transport layer? > > the e2e list was focused on IP end 2 end, not application > layer end 2 end. SIP is (by definition) an application > that runs on top of IP. > > > > > Thanks! > > pars > > > > > > > > > --bill > > > > > > > > > On Fri, Jan 11, 2008 at 02:24:39PM +0100, Pars Mutaf wrote: > > > > Hello, > > > > > > > > I want to leave my cell phone number (SIP URI) on a discussion > > > > forum, or web page, blog, craigslist, phonebook, facebook etc. > > > > But wish to avoid SPIT (SPam over Internet Telephony). A solution > > > > is presented below (with variations called weak, strong). > > > > > > > > Looked like acceptable end2end-interest topic (sorry if not). > > > > Comments are appreciated. > > > > > > > > Regards, > > > > Pars Mutaf > > > > > > > > > > > > 1. Weak solution > > > > > > > > I leave the IP address of my cell phone but not a SIP URI. Interested > > > > party sends a request to my phone. My phone generates a random SIP URI > > > > and returns a different SIP URI to each querier. > > > > > > > > If I receive SPIT to the SIP URI 'x', then I can cancel it. Since > > > > each requestor is returned a different SIP URI, legitimate parties can > > > > continue to call me or send SMS. > > > > > > > > Since the SIP URI 'x' was canceled, a SPITer can request another one > > > > and still send me SPIT. To avoid this attack, the querier can be > > > > requested to solve a hard challenge e.g. a CAPTCHA. A SIP URI will be > > > > returned only after the querier user provided the solution. The > > > > difficulty of the CAPTCHA can be adaptively tuned by the target host. > > > > > > > > When done, i.e. the desired phone call is received, the target user > > > > can stop receiving requests to the indicated IP address. > > > > > > > > > > > > 2. Strong solution > > > > > > > > I leave the IP address of my phone but not a SIP URI. I want to > > > > receive phone calls or SMS only from people that I know. Interested > > > > party sends a request to my phone. My phone displays a message with > > > > the requestor's name e.g.: > > > > > > > > "Alice Collins requested phone number. Accept? [YES/NO]" > > > > > > > > If I accept, my phone generates a random SIP URI and returns it to the > > > > querier. > > > > > > > > This solution requires human name certification. > > > > > > > > An attacker can send continuous bogus requests to the target IP > > > > address and make the target phone continuously display the above > > > > message, annoying the target user. This attack can be defeated by > > > > requesting the querier user to solve a hard CAPTCHA before his request > > > > can be displayed at the target host's screen. The difficulty of the > > > > CAPTCHA can be adaptively tuned by the target host. > > > > > > > > == > > > > Comments are appreciated either here or please subscribe to: > > > > https://www1.ietf.org/mailman/listinfo/humanresolvers > > > > > > > > If you find the problem interesting but have another solution > > > > you are also welcome of course. From L.Wood at surrey.ac.uk Fri Jan 11 08:59:00 2008 From: L.Wood at surrey.ac.uk (Lloyd Wood) Date: Fri, 11 Jan 2008 16:59:00 +0000 Subject: [e2e] Detlef and Opportunistic Scheudling. was: Re: Once again: Detlef and Latencies :-) In-Reply-To: <478769E8.7090605@web.de> References: <47820B53.5050305@web.de> <478769E8.7090605@web.de> Message-ID: <200801111659.QAA05945@cisco.com> Can't you just write up a paper like everyone else and submit it for publication? At Friday 11/01/2008 14:06 +0100, Detlef Bosau wrote: >Hi. > >There were lots of mistakes in my plots, but I think finally got it fixed. > >For my system model, I refer to the Eurane website http://www.ti-wmc.nl/eurane/ >I don?t only use their system model but their code as well and in case, I tell anything about my system modell and the Eurane programmers tell something else, they are presumably correct :-) > >The Eurane code provides a simplified HSDPA simulator and therefore should be suitable to investigate algorithms for opportunistic scheduling. > >What I did are simulations with one sending node and eight mobile receivers in one common HSDPA cell. >All the users move with velocity 3 meters per second (pedestrian) on a circular path with 500 meters distance between BS and UE. >As some nasty complication, I changed the transmission power for the lines 1 to 4 to 32 dBm, whereas the lines 5 to 8 send with 38 dBm. >I simply wanted to simulate a constant shading for a number of lines. > >This scenario is particularly interesting because Thomas Bonald pointed out that Proportional Fair Scheduling, which is state of the art to my knowledge, does not behave well in scenarios with asymmetric scheduling. > >Now, let?s have a look at http://www.detlef-bosau.de/eurane_results.html > >I did simuations with 500 seconds transmission time. > >The plots in the first column show the achieved TCP goodput. >You find >1. a round robin scheduler (at least, it is called that way within the Eurane package. In fact, it is a "last recently served" scheduler, which behaves more or less identical to round robin.) >2. a C/I scheduler (sometimes refered to as "maximum SNR scheduler") which schedules the line with the best channel conditions in the whole set of channels. >3. a "Fair Channel" scheduler, which is part of the Eurane package and addresses the problem of PF scheduling metrics being not comparable for different flows. So, we expect that this scheduler at least alleviates the PF weaknesses in case of asymmteric fading. >4. the score based scheduler by Thomas Bonald (the code was provided by Thomas Bonald and Luca Muscariello), >5. a Proportinal Fair scheduler and the >6. PF flavour proposed by Kolding. The code for both schedulers, PF and Kolding, was provided by Abdulmohsen Mutairi. >7., 8. an Elastic RR scheduler, which is not yet published and proposed by me ;-). (If there is any interest in this scheduler, I would well write a paper about it. But if not, I can spend the time on other things. ;-)) > >(BTW: If there is someone experienced with octave and could help me to have the flows 1 to 4 printed with circles and the rest with asterisks and both done as it can be done in gnuplot so that only every 10 samples a circle or asterisk is plotted, I would be glad. >And the plots would be much more clear.) > > >If we compare the achieved goodput, we immediately see the benefits of exploiting multi user diversity: With respect to the achieved goodput, nearly everything is better than round robin scheduling. > >However, the goodput is not always good for all lines. E.g., with PF scheduling http://www.detlef-bosau.de/eurane_results/goodput_s_9_t_0.1.eps.gz >there are flows with quite impressive goodput (flow 1) while others hardly achieve anything (the rest). > >This is not surprising. Particularly with asymmetric fading, "noisy" lines have to wait for intervals where "low noise lines" experience extremly low noise to get a time slot assigned. > >When we use a C/I scheduler, the noisy lines (1 to 4) hardly achieve any goodput at all. > >However, even the different goodput for the different lines with PF schedulers is, in my opinion, not really convincing and not adequate for any practical implementation. > >The situation is alleviated with the Fair Channel Scheduler and with Bonald?s Scheduler. > >Both achieve fair goodput at least within a group of equal channel conditions (line 1 to 4 being the one group, line 5 to 8 beign the other) and quite acceptable ressource fairness when we look at the time slot allocations: > >Fair Channel: http://www.detlef-bosau.de/eurane_results/allocated_slots_s_3_t_0.1.eps.gz >Bonald, Score Based: http://www.detlef-bosau.de/eurane_results/allocated_slots_s_8_t_0.1.eps.gz > >Surprisingly, the fair channel scheduler achieves a better ressource fairness than the score based scheduler. >To my understanding, both schedulers attempt to normalize a scheduling priority statistic by normalizing location parameters. >The fair channel scheduler uses mean and variance, while the sore based scheduler relies upon an estimate for an upper and lower limit for a sample of SNR values. (In his paper, Thomas Bonald talks about a "ranking", however in fact this is nothing else than finding such limits and making sample sets comparable with these.) > >AFAIK, an empirical average statistic and an empirical variance statistic are quite robust, presumably more stable than estimates for an upper and / or lower limit, so it?s perhaps not that suruprising that the fair channel scheduler achieves a better fairness than the score based scheduler in this scenario. > >There is also a plot for the ressource allocation achieved with the PF scheduler: http://www.detlef-bosau.de/eurane_results/allocated_slots_s_9_t_0.1.eps.gz > >I think, there?s no need for a detailed discussion ;-) > >What I did not add so far is an implementation of Thierry Klein?s modifications to the PF scheduler. If there is interest in that, I will add these in the future, because in that case, we had traces for all availabe PF flavours. However, I do not expect better ressource fairness here, because the problem addressed by Thierry was (same als Kolding) to cope with buffer underruns in TCP flows which can cause severe delay spikes. > >Now, a general weakness of all schedulers using a "scheduling priority", i.e. C/I, and PF flavours, is that there is hardly a limit for a packet delay because we cannot predict when a channel will have favourite conditions. >We particularly enjoy the packet delays (from BS to UE, i.e the time a packet needs to travel through the recovery layer) achieved with Proportional Fair scheduling: >http://www.detlef-bosau.de/eurane_results/delay_s_9_t_0.1.eps.gz >(Can somebody please tell me, where I can complain about the totally inadequate paper format? The lines 5 and 6 appear somewhat, say, horizontally challenged here. In case of any publication, I have to find a plot which is more politcal correct.) > >The round robin scheduler >http://www.detlef-bosau.de/eurane_results/delay_s_1_t_0.1.eps.gz >gives an expectation what _can_ be achieved here. > >However, please bear in mind that retransmits needed for Chase combining are not subject to the scheduling algorihtm in the EURANE code, but are done immediately after a failed transmission. I do not yet know whether this is the case in real HSDPA implementations as well or whether this is an EURANE specific artifact. I woul particularly appreciate any commonts on this one. > >The elastic Round Robin scheuler however controls the actual slot rate _with_ consideration of retransmits, so that >http://www.detlef-bosau.de/eurane_results/delay_s_11_t_0.01.eps.gz >might be somewhat confusing here. > >However, the delays achieved with elastic RR are that small and limited, that I could imagine using this even for streaming applications. Which are not reasonable with PF scheduling. > >The goodput achieved with elastic RR is comparable to that of Fair Channel scheduling and the fairness is slightly better. > >Elastic RR is based upon a rate based round robin scheme which primarily enforces identical slotrate to all flows and allows to violate this slotrate within given limits (defined by the tolerance parameter). > >Only when _all_ slotrates of _all_ competing flows stay within this predefined limit, a scheduling decision is made based upon an opportunistic scheduling priority (actually, I used a fair channel scheduler for that purpose). > >In any other case, the line with the actually smallest rate is assigned a time slot. > >As a general lesson, we learn that we can well exloit multi user diversity and achieve reasonable high goodput for all competing flows with only _little_ violation of a traditional round robin scheme and good ressource fairness. > >O.k. > >The code is available at >http://www.detlef-bosau.de/eurane.html >which of course only contains the changed EURANE files. > > >And now, I would be glad for any kind of questions, comments and discussion. > > > >-- >Detlef Bosau Mail: detlef.bosau at web.de >Galileistrasse 30 Web: http://www.detlef-bosau.de >70565 Stuttgart Skype: detlef.bosau >Mobile: +49 172 681 9937 > > > From bmanning at vacation.karoshi.com Fri Jan 11 09:01:38 2008 From: bmanning at vacation.karoshi.com (bmanning@vacation.karoshi.com) Date: Fri, 11 Jan 2008 17:01:38 +0000 Subject: [e2e] Fighting SPIT on a cell phone In-Reply-To: <1200069881.21494.11.camel@lor-maknavic3.int-evry.fr> References: <1200057879.20475.14.camel@lor-maknavic3.int-evry.fr> <20080111152509.GA4151@vacation.karoshi.com.> <1200067043.21338.26.camel@lor-maknavic3.int-evry.fr> <20080111160533.GA4500@vacation.karoshi.com.> <1200069881.21494.11.camel@lor-maknavic3.int-evry.fr> Message-ID: <20080111170138.GA5091@vacation.karoshi.com.> On Fri, Jan 11, 2008 at 05:44:41PM +0100, Pars Mutaf wrote: > On Fri, 2008-01-11 at 16:05 +0000, bmanning at vacation.karoshi.com wrote: > > On Fri, Jan 11, 2008 at 04:57:23PM +0100, Pars Mutaf wrote: > > > Hi, > > > > > > On Fri, 2008-01-11 at 15:25 +0000, bmanning at vacation.karoshi.com wrote: > > > > you are making an assumption about the persistance > > > > of the binding between an IP address and a given interface. > > > > > > The IP address can be a mobile IP address for example. But > > > other solutions are certainly possible. > > > > 3ff3:0:478::42 - is this mobile or fixed? what is the > > lease time? the point i was trying to make > > was that an IP address is WHERE you are in a > > topology, not WHO you are. > > > The IP address will be attached to a vCARD found somewhere. and the address/card binding will change how frequently? > > > > > you seem to be making an assumption about the ability to > > > > algorithmically determine unwanted content ... > > > > > > In my vision, if Mr. X who was given the SIP URI 'x' starts > > > to SPIT on my phone, I (the user) can cancel the SIP URI 'x'. > > > Mr. Y can still call me because he was returned another SIP > > > URI. > > > > let me try and be more clear. who or what makes > > the determination that Mr.X is "spit"ing on your > > telephone? > > Me. When I receive SPAM I can tell that it is SPAM (in general). i see, so Mr.X can and will have established at least one and perhaps multiple end2end conversations between his device(s) and your(s) -BEFORE- you decide to shun him ... > > > > This idea of "disposable cell phone number" is already in > > > use today. > > > We are proposing a protocol for distributing disposable > > > SIP URIs from the cell phone, on an on-demand basis. > > > > ah ... you are proposing to augment SIP call > > establishment w/ a challange/response ... > > > > This is independent from SIP IMO. We can distribute other > types of identifiers as well. then, imho, this is not an e2e topic. > > pars > > > > > which is > > > > a much harder problem and not (IMHO) something usually > > > > done at the transport layer. > > > > > > Why transport layer? > > > > the e2e list was focused on IP end 2 end, not application > > layer end 2 end. SIP is (by definition) an application > > that runs on top of IP. > > > > > > > > Thanks! > > > pars > > > > > > > > > > > > > --bill > > > > > > > > > > > > On Fri, Jan 11, 2008 at 02:24:39PM +0100, Pars Mutaf wrote: > > > > > Hello, > > > > > > > > > > I want to leave my cell phone number (SIP URI) on a discussion > > > > > forum, or web page, blog, craigslist, phonebook, facebook etc. > > > > > But wish to avoid SPIT (SPam over Internet Telephony). A solution > > > > > is presented below (with variations called weak, strong). > > > > > > > > > > Looked like acceptable end2end-interest topic (sorry if not). > > > > > Comments are appreciated. > > > > > > > > > > Regards, > > > > > Pars Mutaf > > > > > > > > > > > > > > > 1. Weak solution > > > > > > > > > > I leave the IP address of my cell phone but not a SIP URI. Interested > > > > > party sends a request to my phone. My phone generates a random SIP URI > > > > > and returns a different SIP URI to each querier. > > > > > > > > > > If I receive SPIT to the SIP URI 'x', then I can cancel it. Since > > > > > each requestor is returned a different SIP URI, legitimate parties can > > > > > continue to call me or send SMS. > > > > > > > > > > Since the SIP URI 'x' was canceled, a SPITer can request another one > > > > > and still send me SPIT. To avoid this attack, the querier can be > > > > > requested to solve a hard challenge e.g. a CAPTCHA. A SIP URI will be > > > > > returned only after the querier user provided the solution. The > > > > > difficulty of the CAPTCHA can be adaptively tuned by the target host. > > > > > > > > > > When done, i.e. the desired phone call is received, the target user > > > > > can stop receiving requests to the indicated IP address. > > > > > > > > > > > > > > > 2. Strong solution > > > > > > > > > > I leave the IP address of my phone but not a SIP URI. I want to > > > > > receive phone calls or SMS only from people that I know. Interested > > > > > party sends a request to my phone. My phone displays a message with > > > > > the requestor's name e.g.: > > > > > > > > > > "Alice Collins requested phone number. Accept? [YES/NO]" > > > > > > > > > > If I accept, my phone generates a random SIP URI and returns it to the > > > > > querier. > > > > > > > > > > This solution requires human name certification. > > > > > > > > > > An attacker can send continuous bogus requests to the target IP > > > > > address and make the target phone continuously display the above > > > > > message, annoying the target user. This attack can be defeated by > > > > > requesting the querier user to solve a hard CAPTCHA before his request > > > > > can be displayed at the target host's screen. The difficulty of the > > > > > CAPTCHA can be adaptively tuned by the target host. > > > > > > > > > > == > > > > > Comments are appreciated either here or please subscribe to: > > > > > https://www1.ietf.org/mailman/listinfo/humanresolvers > > > > > > > > > > If you find the problem interesting but have another solution > > > > > you are also welcome of course. From detlef.bosau at web.de Fri Jan 11 09:14:46 2008 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 11 Jan 2008 18:14:46 +0100 Subject: [e2e] Detlef and Opportunistic Scheudling. was: Re: Once again: Detlef and Latencies :-) In-Reply-To: <200801111659.QAA05945@cisco.com> References: <47820B53.5050305@web.de> <478769E8.7090605@web.de> <200801111659.QAA05945@cisco.com> Message-ID: <4787A406.4090709@web.de> Lloyd Wood wrote: > Can't you just write up a paper like everyone else and submit it for publication? > > Certainly I can. But despite of the fact, that I actually don?t know where to publish it (I cannot afford a conference paper because I simply don?t have the money) I would like to get some feedback whether anybody is interested in this work. However, I got the first feedback just some minutes ago. I will not quote this here in the public, because it was extremely frustrating. I don?t have the privilege to discuss my work with anybody. And therefore, before I submit a paper, wait a quarteer of a year for the feedback, which is most likely a "reject" because I?m not an experienced writer, I dared to talk about my work here. And if there are questions or criticism, I can consider it and correct my work. Perhaps, it would be accepted then. And if someone thinks, I can submit it to a journal, I would appreciate a hint which journal would be appropriate. As you perhaps remember, I?m just an unemployed guy with hardly any contact to the academic world and not very experienced in writing. So, if your intention was to encouage a paper: You perfectly managed to hide it ;-) I?m looking for an opportunity to talk about my work. And I hoped, it would be not too much "off topic" here. If I was wrong, I apologize. Detlef -- Detlef Bosau Mail: detlef.bosau at web.de Galileistrasse 30 Web: http://www.detlef-bosau.de 70565 Stuttgart Skype: detlef.bosau Mobile: +49 172 681 9937 From weddy at grc.nasa.gov Fri Jan 11 09:20:12 2008 From: weddy at grc.nasa.gov (weddy@grc.nasa.gov) Date: Fri, 11 Jan 2008 12:20:12 -0500 Subject: [e2e] Fighting SPIT on a cell phone In-Reply-To: <20080111160533.GA4500@vacation.karoshi.com.> References: <1200067043.21338.26.camel@lor-maknavic3.int-evry.fr> <20080111160533.GA4500@vacation.karoshi.com.> Message-ID: <20080111172011.GA20323@grc.nasa.gov> On Fri, Jan 11, 2008 at 04:05:33PM +0000, bmanning at vacation.karoshi.com wrote: > the point i was trying to make > was that an IP address is WHERE you are in a > topology, not WHO you are. That hasn't been true since about 1996: http://tools.ietf.org/html/rfc2002 :) From Sharad.Agarwal at microsoft.com Fri Jan 11 10:35:23 2008 From: Sharad.Agarwal at microsoft.com (Sharad Agarwal) Date: Fri, 11 Jan 2008 10:35:23 -0800 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <1200036994.3691.34.camel@pc105-c703.uibk.ac.at> References: <1199975821.3801.119.camel@pc105-c703.uibk.ac.at> <1199986532.5843.45.camel@localhost> <66F5DB2A9E206A498B5AE59E3E42B02D2CD3AE761E@NA-EXMSG-C113.redmond.corp.microsoft.com> <3883BDABDBD09C499A2493B70E4859B83198CB4FCB@NA-EXMSG-C113.redmond.corp.microsoft.com> <001101c853d0$4043fe80$0200a8c0@fun> <3883BDABDBD09C499A2493B70E4859B83198CB5190@NA-EXMSG-C113.redmond.corp.microsoft.com> <1200036994.3691.34.camel@pc105-c703.uibk.ac.at> Message-ID: <3883BDABDBD09C499A2493B70E4859B83198CB55FF@NA-EXMSG-C113.redmond.corp.microsoft.com> > But if spammers really want to do this, say, to microsoft.com, > surely they could find an automated response system somewhere > at microsoft.com which they could use for the same purpose? > > Or, alternatively, send enough pointless emails to people working > at microsoft.com until they get a vacation message - so they get > addresses which they could use to get an autoresponse anyway > for doing this kind of test. The spammer would need to know valid email aliases at microsoft.com, which isn't easy to figure out from the outside. If the domain does send bouncecbacks on invalid aliases, then you could launch a search for common names, but I believe many domains don't send bouncebacks or rate limit them for this reason (Afergan & Beverly in "The State of the Email Address" in CCR Jan 05 found that only 25% of the domains they tested responded with bouncebacks). I know that some vacation message response systems by default only send a vacation response to those in the same email domain as you. Again, possibly for the same reason. From sollins at csail.mit.edu Thu Jan 10 11:35:19 2008 From: sollins at csail.mit.edu (Karen R. Sollins) Date: Thu, 10 Jan 2008 11:35:19 -0800 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: References: Message-ID: Michael, Jon, et al., If you are interested in documentation and analysis of email lossage see the following CCR paper (Jan. 2005) by Mike Afergan and Rob Beverly for one approach: http://portal.acm.org/citation.cfm?id=1052812.1052822 and the emailtester website at: http://www.emailtester.net From mascolo at poliba.it Tue Jan 22 10:28:11 2008 From: mascolo at poliba.it (Saverio Mascolo) Date: Tue, 22 Jan 2008 19:28:11 +0100 Subject: [e2e] Implementation of XCP and similar feedback from routers ... Message-ID: <01b901c85d24$a97804c0$723bccc1@HPSM> dear all, i would like to ask who knows on the state of implementation, in commercial routers, of mechanisms to provide feedback to improve e2e congestion control such as XCP and similar. thanks for the attention, Saverio Mascolo, Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20080122/6b0887db/attachment.html From mallman at icir.org Mon Jan 28 09:15:27 2008 From: mallman at icir.org (Mark Allman) Date: Mon, 28 Jan 2008 12:15:27 -0500 Subject: [e2e] was Re: A message to authors - nsdi In-Reply-To: <3883BDABDBD09C499A2493B70E4859B83198CB4FCB@NA-EXMSG-C113.redmond.corp.microsoft.com> Message-ID: <20080128171527.AF10B356DE6@lawyers.icir.org> [chiming in late] > An underlying problem is how to separate legitimate senders from other > senders. For legitimate senders, you could allow such an ACK service > to be used (or better yet, apply different spam rules); but the > traditional way of recognizing legitimate senders by their email > address isn't foolproof since the from address can easily be > forged. So a better way of doing end2end "authentication" (without > using heavyweight key exchange & signing) could help. Just to flog something, we sketch a system in the following paper whereby key exchange and usage is used, but abstracted away from the user by considering some activity to be a proxy for key management. E.g., if an email is signed by some public key then a user replying to that message indicates---with high probability---that future emails signed by the same key are likely legit and so perhaps should not be subjected to spam filtering. Mark Allman, Christian Kreibich, Vern Paxson, Robin Sommer, Nicholas Weaver. The Strengths of Weaker Identities: Opportunistic Personas. USENIX Workshop on Hot Topics in Security (HotSec), August 2007. http://www.icir.org/mallman/papers/opp-personas-hotsec07.pdf FWIW. allman -- Mark Allman -- ICSI -- http://www.icir.org/mallman/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20080128/3d07a485/attachment.bin From Detlef.Bosau at web.de Thu Jan 31 04:17:11 2008 From: Detlef.Bosau at web.de (Detlef Bosau) Date: Thu, 31 Jan 2008 13:17:11 +0100 Subject: [e2e] =?iso-8859-15?q?Detlef_and_Opportunistic_Scheudling=2E_was?= =?iso-8859-15?q?=3A_Re=3A_Once_again=3A_Detlef_and_Latencies_=3A-=29?= Message-ID: <678222444@web.de> I apologize to return to this topic, and I?m not going to steel anyone?s time with a long post here. I put my work on my homepage: http://www.detlef-bosau.de/opportunistic_scheduling/index.html I would be glad if there were an opportunity to get something published based upon this work. So, anybody is welcome to read it and to provide some comments or questions. I would particularly appreciate any feedback from Germany, because sometimes it is helpful to discuss some questions in my mother tongue. Thank you. Detlef