Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
- Original Message - From: "Cameron Byrne" To: "Brian E Carpenter" Cc: ; "IETF-Discussion" ; "Dearlove, Christopher (UK)" ; "t.p." Sent: Wednesday, March 06, 2013 4:12 PM > On Mar 6, 2013 1:03 AM, "Brian E Carpenter" > wrote: > > > > On 06/03/2013 08:36, t.p. wrote: > > ... > > > Interesting, there is more life in Congestion Control than I might have > > > thought. But it begs the question, is this something that the IETF > > > should be involved with or is it better handled by those who are > > > developping LTE etc? > > > > From the little I know about TCP proxies, they are horrible beasts > > that can impact application layer semantics. Figuring out how to deal > > with mixed e2e paths (partly lossy, partly congested) seems to me > > very much an IRTF/IETF topic, even if we don't have an AD who is > > a subject matter expert. > > > >Brian > > There is a huge cross layer optimization issue between 3gpp and the ietf. > It is worse than you can imagine, highly akin to how the industry moved > passed the ietf with Nat. The same thing is happening with tcp. Tcp is > simply not fit for these high latency high jitter low loss networks. Reading this reminds me that my first experience with TCP was over a high latency high jitter network with 0% error and 0% loss (to my ability to measure it) with retransmission rates of 50%, because the TCP algorithms were totally unsuited to such a network. It was, of course, X.25. Did anyone find a solution back then, or did we just wait for X.25 to be superseded? (I am back on my thesis that there is nothing new in Congestion Control, that the principles and practices that we need have been around for many years and that we just need to find them). Tom Petch > Google is a player in the e2e space for various business reasons and it > appears they are now in an arms race with these horrible mobile carrier > proxies (which in many cases do on the fly transcoding of video). > > There are 2 fronts. 1 is quic as linked above. Another is their own > transcoding https proxy > https://developers.google.com/chrome/mobile/docs/data-compression > > This is not novel. Opera mini has been doing this for years, otherwise know > as opera turbo. Oh, and Nokia has been doing it too. They even help by > bypassing pki and any sense of internet security. > > http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the -middle-attacks-103799 > > Hold on to your hats. > > CB >
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Tue, Mar 05, 2013 at 07:52:56AM +, Eggert, Lars wrote: > On Mar 4, 2013, at 19:44, Michael Richardson wrote: > > The Transport Area has all of the groups that deal with transport > > protocols that need to do congestion control. Further, the (current) > > split of work means that all of the groups that need congestion > > oversight would be cared for by the position that is currently becoming > > empty as Wes leaves. > > Also, other areas frequently build protocols that need review from a > congestion control perspective (do they back of under loss, can they even > detect loss, etc.) > > Inside the area, there is typically enough CC clue applied by the TSV > community as a whole. It's outside the area where the TSV AD as a person gets > involved a lot. > > Lars Sure, but that could equally well be seen as a problem of the way how the IESG chooses to perform its business. There are enough experts that could consult whether its in role of directorates or else. They may just not want to take on an AD role. And there are a lot more TSV friction points with whats going on in the IETF than just CC.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Martin, An article like this is the best reason why we should never finally resolve the buffer bloat issue: Doing that would take away the opportunity for generations of researcher to over and over regurgitate the same proposed improvements and gain PhDs in the process. I mean the Internet wold be like math without fermats last theorem. Have you seen how disenfranchised mathematicians are now ? Its worse than the mood at Kennedy Space center without a shuttle program (to bring the discussion back to relevant aspects of IETF Orlando). Sorry. could'nt resist. I was actually happy about using some of those UDP based flow control reliable transports in past years when i couldn't figure out how to fix the TCP stack of my OSs. Alas, the beginning of the end of TCP is near now anyhow with RTCweb deciding to use browser/user-level based SCTP over UDP stacks instead of OS-level TCP. On Tue, Mar 05, 2013 at 01:41:35AM +0100, Martin Rex wrote: > Bob Braden wrote: > > On 3/4/2013 10:20 AM, Roger Jørgensen wrote: > > > I'll ask a rather basic question and hope someone will answer in an > > > educational way - Why is congestion control so important? And where > > > does it apply? ... :-) > > > > Ouch. Because without it (as we learned the hard way in the late 1980s) \ > > the Internet may collapse and provide essentially no service. > > It is PR like this one: > > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html > > That gets me worried about folks might try to "fix" the internet > mostly due to the fact that they really haven't understood what > is already there any why. > > -Martin -- --- Toerless Eckert, eck...@cisco.com Cisco NSSTG Systems & Technology Architecture SDN: Let me play with the network, mommy!
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
John E Drake wrote: > See also: > http://www.akamai.com/html/about/press/releases/2012/press_091312.html It seems to me that Akamai is doing things which must be banned by IETF. Akamai IP Application Accelerator http://www.atoll.gr/media/brosures/FS_IPA.pdf Packet Loss Reduction Application performance is also affected by packet loss, which may be particularly troublesome when traffic traverses international network paths. IP Application ^^ Accelerator uses a variety of advanced ^^ packet loss reduction techniques, including ^^^ forward error correction and optional packet replication to eliminate packet loss. Masataka Ohta
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
> From: t.p. > is this something that the IETF should be involved with or is it better > handled by those who are developping LTE etc? I would _like_ to think it's better done by the IETF, since congestion control/response more or less has to be done on an end-end basis, so trying to do it in any particular link technology is not necessarily useful (unless the entire connection path is across that technology). But... > From: Cameron Byrne > There is a huge cross layer optimization issue between 3gpp and the > ietf. It is worse than you can imagine, highly akin to how the industry > moved passed the ietf with Nat. Well, I sort of see the analogy with NAT. But rather than rathole on a non-productive discussion of similarities and causes, I think it's more useful/fruitful to examine your point that people are doing all sorts of localized hacks in an attempt to gain competitive advantage. Sometimes this is not a problem, and they are (rightly) responding to places where the IETF isn't meeting needs (one good example is traffic directors in front of large multi-machine web servers). But how much good going it alone will do in this particular case (since congestion control is necessarily end-end) is unclear, although I guess the 'terminate (effectively) the end-end connection near the border of the provider's system, and do a new one to the terminal at the user's device' model works. But there definitely is a risk of layers clashing, both trying to do one thing... Noel
RE: congestion control? - (was Re: Appointment of a Transport AreaDirector)
See also: http://www.akamai.com/html/about/press/releases/2012/press_091312.html Irrespectively Yours, John From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cameron Byrne Sent: Wednesday, March 06, 2013 8:12 AM To: Brian E Carpenter Cc: bra...@isi.edu; IETF-Discussion Subject: Re: congestion control? - (was Re: Appointment of a Transport AreaDirector) On Mar 6, 2013 1:03 AM, "Brian E Carpenter" mailto:brian.e.carpen...@gmail.com>> wrote: > > On 06/03/2013 08:36, t.p. wrote: > ... > > Interesting, there is more life in Congestion Control than I might have > > thought. But it begs the question, is this something that the IETF > > should be involved with or is it better handled by those who are > > developping LTE etc? > > From the little I know about TCP proxies, they are horrible beasts > that can impact application layer semantics. Figuring out how to deal > with mixed e2e paths (partly lossy, partly congested) seems to me > very much an IRTF/IETF topic, even if we don't have an AD who is > a subject matter expert. > >Brian There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp. Tcp is simply not fit for these high latency high jitter low loss networks. Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video). There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too. They even help by bypassing pki and any sense of internet security. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799 Hold on to your hats. CB
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
On Mar 6, 2013 1:03 AM, "Brian E Carpenter" wrote: > > On 06/03/2013 08:36, t.p. wrote: > ... > > Interesting, there is more life in Congestion Control than I might have > > thought. But it begs the question, is this something that the IETF > > should be involved with or is it better handled by those who are > > developping LTE etc? > > From the little I know about TCP proxies, they are horrible beasts > that can impact application layer semantics. Figuring out how to deal > with mixed e2e paths (partly lossy, partly congested) seems to me > very much an IRTF/IETF topic, even if we don't have an AD who is > a subject matter expert. > >Brian There is a huge cross layer optimization issue between 3gpp and the ietf. It is worse than you can imagine, highly akin to how the industry moved passed the ietf with Nat. The same thing is happening with tcp. Tcp is simply not fit for these high latency high jitter low loss networks. Google is a player in the e2e space for various business reasons and it appears they are now in an arms race with these horrible mobile carrier proxies (which in many cases do on the fly transcoding of video). There are 2 fronts. 1 is quic as linked above. Another is their own transcoding https proxy https://developers.google.com/chrome/mobile/docs/data-compression This is not novel. Opera mini has been doing this for years, otherwise know as opera turbo. Oh, and Nokia has been doing it too. They even help by bypassing pki and any sense of internet security. http://www.techweekeurope.co.uk/news/nokia-decrypting-traffic-man-in-the-middle-attacks-103799 Hold on to your hats. CB
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
l.w...@surrey.ac.uk wrote: > 3GPP has to never drop a packet because it's doing zero-header > compression. "has to never"? Even though it must, when it goes down. > Lose a bit, lose everything. You totally deny FEC. Wow!!! > And ROHC is an IETF product. > > I'm pretty sure the saving on headers is more than made up for in > FEC, delay, etc. Not the engineering tradeoff one might want. It has nothing to do with congestion, not at all. Masataka Ohta
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
3GPP has to never drop a packet because it's doing zero-header compression. Lose a bit, lose everything. And ROHC is an IETF product. I'm pretty sure the saving on headers is more than made up for in FEC, delay, etc. Not the engineering tradeoff one might want. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Masataka Ohta [mo...@necom830.hpcl.titech.ac.jp] Sent: 06 March 2013 11:37 To: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Cameron Byrne wrote: > In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop > the packet, by design. According to the end to end argument, that's simply impossible, because intermediate equipments holding packets not confirmed by the next hop may corrupt the packets or suddenly goes down. > It will just delay the packet as it gets > resent through various checkpoints and goes through various rounds of > FEC. The result is delay, Even with moderate packet drop probability, it means *A LOT OF* delay or connection oriented communication, either of which makes 3GPP mostly unusable. Masataka Ohta
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Cameron Byrne wrote: In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. According to the end to end argument, that's simply impossible, because intermediate equipments holding packets not confirmed by the next hop may corrupt the packets or suddenly goes down. > It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, Even with moderate packet drop probability, it means *A LOT OF* delay or connection oriented communication, either of which makes 3GPP mostly unusable. Masataka Ohta
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
On 06/03/2013 08:36, t.p. wrote: ... > Interesting, there is more life in Congestion Control than I might have > thought. But it begs the question, is this something that the IETF > should be involved with or is it better handled by those who are > developping LTE etc? >From the little I know about TCP proxies, they are horrible beasts that can impact application layer semantics. Figuring out how to deal with mixed e2e paths (partly lossy, partly congested) seems to me very much an IRTF/IETF topic, even if we don't have an AD who is a subject matter expert. Brian
Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
- Original Message - From: "Cameron Byrne" To: "Dearlove, Christopher (UK)" Cc: ; Sent: Tuesday, March 05, 2013 8:01 PM On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) wrote: > I've no idea about the example quoted, but I can see some of their motivation. In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as "tcp optmization" or "WAN acceleration", both murky terms. Interesting, there is more life in Congestion Control than I might have thought. But it begs the question, is this something that the IETF should be involved with or is it better handled by those who are developping LTE etc? (It is true that the IETF did TCP without any skin in X.25, 802.3 and so on but this sounds different). Alternatively, when the ICCRG was looking for things to do, I did raise the question of how true it was that (presumed) packet loss was due to congestion (a fundamental assumption of the IETF) and got the impression that that was regarded as an answered question and not a topic for research. From what you say, it sounds more as if the ICCRG should have been looking at it. Tom Petch The issues in CC result is the re-invention of congestion control at higher layers like http://en.wikipedia.org/wiki/QUIC And, fun things like draft-ietf-rtcweb-data-channel CB > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearl...@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex > Sent: 05 March 2013 00:42 > To: bra...@isi.edu > Cc: ietf@ietf.org > Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) > > Bob Braden wrote: >> On 3/4/2013 10:20 AM, Roger Jørgensen wrote: >> > I'll ask a rather basic question and hope someone will answer in an >> > educational way - Why is congestion control so important? And where >> > does it apply? ... :-) >> >> Ouch. Because without it (as we learned the hard way in the late 1980s) \ >> the Internet may collapse and provide essentially no service. > > It is PR like this one: > > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.ht ml > > That gets me worried about folks might try to "fix" the internet > mostly due to the fact that they really haven't understood what > is already there any why. > > -Martin > > > > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > >
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 3:01 PM, Cameron Byrne wrote: > > In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop > the packet, by design. It will just delay the packet as it gets > resent through various checkpoints and goes through various rounds of > FEC. The result is delay, TCP penalties that assume delay is loss, > ... the end result is that every 3GPP network in the world (guessing) > has proxies in place to manipulate TCP so that when you go to > speedtest.net your $serviceprovider looks good. Is this good > cross-layer optimization, no... but this is how it is. > > So, fundamentals of CC and TCP have resulted in commercial need for > middleboxes in the core of the fastest growing part of the internet. > This is sometimes known as "tcp optmization" or "WAN acceleration", > both murky terms. > There may be some things the IETF can do to improve this. It's not clear yet, but some of the relevant vendors are participating in a non-WG mailing list, focused on one aspect of the situation (TCP option numbers), but recently more ambitious work was suggested: http://www.ietf.org/mail-archive/web/middisc/current/msg00121.html People who are interested in this, should *definitely* self-organize a bit and think about a BoF, in my opinion. -- Wes Eddy MTI Systems
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) wrote: > I've no idea about the example quoted, but I can see some of their motivation. > > TCP's assumptions (really simplified) that loss of packet = congestion => > backoff > aren't necessarily so in a wireless network, where packets can be lost without > congestion. This means that TCP into, out of, or across, a MANET using TCP > can be > bad. It then tends to happen that the MANET people don't fully understand TCP, > and the TCP people don't fully understand MANETs. > > I don't have a single good reference for what I say above, in particular have > things got better (or worse) as TCP evolves, and therefore which references > are still valid? But the obvious Google search (TCP MANET) throws up various > discussions. > In the 3GPP case of GSM/UMTS/LTE, the wireless network will never drop the packet, by design. It will just delay the packet as it gets resent through various checkpoints and goes through various rounds of FEC. The result is delay, TCP penalties that assume delay is loss, ... the end result is that every 3GPP network in the world (guessing) has proxies in place to manipulate TCP so that when you go to speedtest.net your $serviceprovider looks good. Is this good cross-layer optimization, no... but this is how it is. So, fundamentals of CC and TCP have resulted in commercial need for middleboxes in the core of the fastest growing part of the internet. This is sometimes known as "tcp optmization" or "WAN acceleration", both murky terms. The issues in CC result is the re-invention of congestion control at higher layers like http://en.wikipedia.org/wiki/QUIC And, fun things like draft-ietf-rtcweb-data-channel CB > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearl...@baesystems.com | http://www.baesystems.com > > BAE Systems (Operations) Limited > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, > Farnborough, Hants, GU14 6YU, UK > Registered in England & Wales No: 1996687 > > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > Martin Rex > Sent: 05 March 2013 00:42 > To: bra...@isi.edu > Cc: ietf@ietf.org > Subject: Re: congestion control? - (was Re: Appointment of a Transport Area > Director) > > Bob Braden wrote: >> On 3/4/2013 10:20 AM, Roger Jørgensen wrote: >> > I'll ask a rather basic question and hope someone will answer in an >> > educational way - Why is congestion control so important? And where >> > does it apply? ... :-) >> >> Ouch. Because without it (as we learned the hard way in the late 1980s) \ >> the Internet may collapse and provide essentially no service. > > It is PR like this one: > > http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html > > That gets me worried about folks might try to "fix" the internet > mostly due to the fact that they really haven't understood what > is already there any why. > > -Martin > > > > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > >
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 10:40 AM, Spencer Dawkins wrote: > On 3/5/2013 8:15 AM, Brian E Carpenter wrote: >> On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: >>> I've no idea about the example quoted, but I can see some of their >>> motivation. >>> >>> TCP's assumptions (really simplified) that loss of packet = >>> congestion => backoff >>> aren't necessarily so in a wireless network, where packets can be >>> lost without >>> congestion. This means that TCP into, out of, or across, a MANET >>> using TCP can be >>> bad. It then tends to happen that the MANET people don't fully >>> understand TCP, >>> and the TCP people don't fully understand MANETs. >> >> The effects you mention were definitely discussed in PILC. >> http://www.ietf.org/wg/concluded/pilc.html >> Maybe the PILC documents need revision? >> >> Brian > > TRIGTRAN tried to nail this down in more detail after PILC concluded (I > co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 > minutes pretty much captured where that ended up: > > > Spencer summarized a private conversation with Mark Allman as, "Gee, > maybe TCP does pretty well often times on its own. You may be able to > find cases where you could do better with notifications, but by the time > you make sure the response to a notification doesn't have undesirable > side effects in other cases, TCP doesn't look so bad" > > > If we had to have all the TCP responding-to-loss mechanisms in an > implementation anyway, and we could tell a sender to slow down, but not > to speed up, it wasn't clear that additional mechanisms would buy you much. > > References are at > http://www.ietf.org/proceedings/55/239.htm and > http://www.ietf.org/proceedings/56/251.htm > > The high order bit on this may have been that TRIGTRAN wasn't IETF-ready > and should have gone off to visit IRTF-land, but in the early 2000s, I > (at least) had no idea how to make that happen. > Later on, there was also a proposed TERNLI BoF and mailing list, and bar BoF that resulted in: http://tools.ietf.org/id/draft-sarolahti-tsvwg-crosslayer-01.txt But didn't go any farther, that I'm aware of. Section 6 actually puts into context TRIGTRAN and other attempts to do something in this space. There's quite a bit of history just in the IETF. RFC 4907 (IAB's "Architectural Implications of Link Indications") is also a good snapshot of the thinking at that time. -- Wes Eddy MTI Systems
Fwd: [e2e] Why do we need congestion control?
Begin forwarded message: > From: Srinivasan Keshav > Subject: [e2e] Why do we need congestion control? > Date: March 5, 2013 15:04:48 GMT+01:00 > To: "" > > To answer this question, I put together some slides for a presentation at the > IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we always size > a shared resource (such as a link or a router) smaller than the sum of peak > demands. This can result in transient or persistent overloads, reducing > user-perceived performance. Transient overloads are easily relieved by a > buffer, but persistent overload requires reductions of source loads, which is > the role of congestion control. Lacking congestion control, or worse, with an > inappropriate response to a performance problem (such as by increasing the > load), shared network resources are always overloaded leading to delays, > losses, and eventually collapse, where every packet that is sent is a > retransmission and no source makes progress. A more detailed description can > also be found in chapter 1 of my PhD thesis [2]. > > Incidentally, the distributed optimization approach that Jon mentioned is > described beautifully in [3]. > > hope this helps, > keshav > > [1] Congestion and Congestion Control, Presentation at IRTF ICCRG Workshop, > PFLDnet, 2007, Los Angeles (California), USA, February 2007. > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf > > [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, published > as UC Berkeley TR-654, September 1991 > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf > > [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition methods > for network utility maximization." Selected Areas in Communications, IEEE > Journal on 24.8 (2006): 1439-1451. > http://www.princeton.edu/~chiangm/decomptutorial.pdf > >
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/5/2013 8:15 AM, Brian E Carpenter wrote: On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion => backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian TRIGTRAN tried to nail this down in more detail after PILC concluded (I co-chaired both PILC and the TRGTRAN BOFs). This quote from the IETF 56 minutes pretty much captured where that ended up: Spencer summarized a private conversation with Mark Allman as, "Gee, maybe TCP does pretty well often times on its own. You may be able to find cases where you could do better with notifications, but by the time you make sure the response to a notification doesn't have undesirable side effects in other cases, TCP doesn't look so bad" If we had to have all the TCP responding-to-loss mechanisms in an implementation anyway, and we could tell a sender to slow down, but not to speed up, it wasn't clear that additional mechanisms would buy you much. References are at http://www.ietf.org/proceedings/55/239.htm and http://www.ietf.org/proceedings/56/251.htm The high order bit on this may have been that TRIGTRAN wasn't IETF-ready and should have gone off to visit IRTF-land, but in the early 2000s, I (at least) had no idea how to make that happen. Spencer I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 05/03/2013 11:55, Dearlove, Christopher (UK) wrote: > I've no idea about the example quoted, but I can see some of their motivation. > > TCP's assumptions (really simplified) that loss of packet = congestion => > backoff > aren't necessarily so in a wireless network, where packets can be lost without > congestion. This means that TCP into, out of, or across, a MANET using TCP > can be > bad. It then tends to happen that the MANET people don't fully understand TCP, > and the TCP people don't fully understand MANETs. The effects you mention were definitely discussed in PILC. http://www.ietf.org/wg/concluded/pilc.html Maybe the PILC documents need revision? Brian > > I don't have a single good reference for what I say above, in particular have > things got better (or worse) as TCP evolves, and therefore which references > are still valid? But the obvious Google search (TCP MANET) throws up various > discussions. >
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
The problem with the congestion/interference and corruption problem is that error notification does not percolate up the stack. If a MAC driver could say 'this frame is corrupt, failed CRC' and that information percolated up the layers into the flow to the endpoints, TCP or similar might have more to go on. But that information is hard to convey, multiple links may be affected, it gets lost... first hops benefit most. in other words, Explicit Corruption Notification would fail for the same reasons that Explicit Congestion Notification does. And this is presuming that enough of the frame is recoverable to know which higher-layer flow it is associated with reliably, ie some header check passes, but overall frame check fails so there's a discard, and state is around to signal the right flow. And to make the header checks pass with a chance of decoding the headers have to be coded better than the payloads - and this applies at each layer, recursively. um. But there's a paucity of cross-layer signalling, and a paucity of higher layers even sanity-checking their header with checksums. And a paucity of available state to track and associate with flows. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Dearlove, Christopher (UK) [chris.dearl...@baesystems.com] Sent: 05 March 2013 11:55 To: m...@sap.com; bra...@isi.edu Cc: ietf@ietf.org Subject: RE: congestion control? - (was Re: Appointment of a Transport Area Director) I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion => backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: > On 3/4/2013 10:20 AM, Roger Jørgensen wrote: > > I'll ask a rather basic question and hope someone will answer in an > > educational way - Why is congestion control so important? And where > > does it apply? ... :-) > > Ouch. Because without it (as we learned the hard way in the late 1980s) \ > the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to "fix" the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
RE: congestion control? - (was Re: Appointment of a Transport Area Director)
I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion => backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: bra...@isi.edu Cc: ietf@ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: > On 3/4/2013 10:20 AM, Roger Jørgensen wrote: > > I'll ask a rather basic question and hope someone will answer in an > > educational way - Why is congestion control so important? And where > > does it apply? ... :-) > > Ouch. Because without it (as we learned the hard way in the late 1980s) \ > the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to "fix" the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Roger, On 3/4/13 7:20 PM, Roger Jørgensen wrote: > I'll ask a rather basic question and hope someone will answer in an > educational way - Why is congestion control so important? And where > does it apply? ... :-) That basic question is a very important one to ask from time to time. Others have already answered, and I will simply add one addition: the way one implements congestion control (or not) has impact not only on the party or parties with whom your computer is speaking, but on every communication that shares the links between your computer and those parties. So: get it wrong and you can hurt others. And it's easy to get wrong. Eliot
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Mar 4, 2013, at 19:44, Michael Richardson wrote: > The Transport Area has all of the groups that deal with transport > protocols that need to do congestion control. Further, the (current) > split of work means that all of the groups that need congestion > oversight would be cared for by the position that is currently becoming > empty as Wes leaves. Also, other areas frequently build protocols that need review from a congestion control perspective (do they back of under loss, can they even detect loss, etc.) Inside the area, there is typically enough CC clue applied by the TSV community as a whole. It's outside the area where the TSV AD as a person gets involved a lot. Lars
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
Bob Braden wrote: > On 3/4/2013 10:20 AM, Roger Jørgensen wrote: > > I'll ask a rather basic question and hope someone will answer in an > > educational way - Why is congestion control so important? And where > > does it apply? ... :-) > > Ouch. Because without it (as we learned the hard way in the late 1980s) \ > the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to "fix" the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On 3/4/2013 10:20 AM, Roger Jørgensen wrote: I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) Ouch. Because without it (as we learned the hard way in the late 1980s) \ the Internet may collapse and provide essentially no service. It applies to everyone who sends packets into the Internet, potentially. OTOH, it is a collective phenomenon; as long as most Internet users are using TCP, it does not matter much what an individual non-TCP user does. TCP comes with the Gold Standard congestion control. Maybe the IETF could and should invite Van Jacobson to attend ab IETF meeting to reprise one of his talks from 20 years ago. Bob Braden
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
>>>>> "rgensen" == rgensen writes: rgensen> I'll ask a rather basic question and hope someone will rgensen> answer in an educational way - Why is congestion control so rgensen> important? And where does it apply? ... :-) The Transport Area has all of the groups that deal with transport protocols that need to do congestion control. Further, the (current) split of work means that all of the groups that need congestion oversight would be cared for by the position that is currently becoming empty as Wes leaves. -- Michael Richardson , Sandelman Software Works pgp_x2V_NHXrF.pgp Description: PGP signature
congestion control? - (was Re: Appointment of a Transport Area Director)
changed the subject ... and added a cc to some that might not follow ietf@ On Sun, Mar 3, 2013 at 1:50 PM, Eggert, Lars wrote: > On Mar 3, 2013, at 13:37, Eric Burger wrote: >> There are two other interpretations of this situation, neither of which I >> think is true, but we should consider the possibility. The first is the TSV >> is too narrow a field to support an area director and as such should be >> folded in with another area. The second is if all of the qualified people >> have moved on and no one is interested in building the expertise the IESG >> feels is lacking, then industry and academia have voted with their feet: the >> TSV is irrelevant and should be closed. >> >> Since I believe neither is the case, it sounds like the IESG requirements >> are too tight. > > I don't believe the requirements are too tight. *Someone* one the IESG needs > to understand congestion control. > > The likely possibility is that many qualified people failed to get sufficient > employer support to be able to volunteer. It's at least a 50% time > committment. I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
> For other guidelines, i.e., (2), (5), (6), and (7), the author > must perform the suggested evaluations and provide recommended > analysis. Evidence that > the proposed mechanism has significantly more problems than those of > TCP should be a cause for concern in approval for widespread > deployment in the global Internet. Looks OK to me. I have incorporated it, modulo comments from Sally. As for the non-BE stuff: This document is a no-op. But, why is that an issue? The IETF would have to grapple with the non-BE case just as it does today (i.e., without a set of guidelines). This one document does not need to solve all the world's problems. If you want to write a document about how the IETF should handle non-BE congestion control proposals, I think that'd be fine. And, again, I am not hearing outcry on this point so I think the document is fine (even if the consensus on this one point is not completely 'smooth'). Thanks, allman pgpZ20qD5vV8W.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
On Tue, 29 May 2007, Mark Allman wrote: Or do you mean that the proposers should do everything guidelines (2), (5), (6) and (7) say, but shortcomings in the results of these guidelines (e.g., proposal being only slightly more troublesome than TCP) should not block the approval for widespread deployment in the global Internet. Yes. And, in re-reading the text I think it is clear. I really can't untangle your comments in this area. If you have specific suggestions for the text, please send them along. -03 has: For other guidelines, i.e., (2), (5), (6), and (7), evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. if the above is what you mean (and a proposer must really go through everything you list, e.g., all the difficult environments as well), it should be explicit, e.g.: For other guidelines, i.e., (2), (5), (6), and (7), the author must perform the suggested evaluations and provide recommended analysis. Evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. My problem with existing text is that the referred guidelines use wording "should do ...". Is it a "must do" or "may do" or something in between? It should be more explicit. Text proposal above interprets the shoulds as musts. 4) The first evaluation criteria also includes "We also note that this guideline does not constrain the fairness offered for non-best-effort traffic." I don't understand your point here. All we are saying is that if---by some means---we know that some flow is not best effort then it can be subjected to some other criteria then it need not be constrained by the guideline. What I try to say is that I can't figure out how operationally and practically this could be achieved. Do you have examples in mind how how this could apply in some specific scenario? If not -- and it isn't a practical concern right now -- maybe we should not overengineer the BCP to address best-effort vs non-best-effort at all. We didn't overengineer anything. We just said that the guideline doesn't apply to non-BE cases. I can't understand your point here at all. It is a simple statement of document scope. Let's say I propose an informational RFC on congestion control and say that it only applies to non-BE traffic. I don't have to make any of the evaluations or analysis required by this draft. What's the procedure for non-BE congestion control agorithms? I note that Lars's ION does not mention that case. In case there is no process to define non-BE congestion control mechanisms at all (and the response would be "sorry, we don't support that"), I have no problem. In case there is some process with a lower bar, I'd have a problem, because it would be possible to avoid the loops you have jump through defined in this document by saying the CC algorithm applies to non-BE traffic only, but in practice it would be end up deployed for BE traffic as well. -- Pekka Savola "You each name yourselves king, yet the Netcore Oykingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
> >(0) Differences with Congestion Control Principles [RFC2914]
> >
> >Proposed congestion control mechanisms that do should include a
> >clear explanation of the deviations from [RFC2914].
> >
> > Is that more clear?
>
> Yes (though '..that do should..' seemed weird on the first read).
I have fixed this (Sally caught it, too).
> Or do you mean that the proposers should do everything guidelines
> (2), (5), (6) and (7) say, but shortcomings in the results of these
> guidelines (e.g., proposal being only slightly more troublesome than
> TCP) should not block the approval for widespread deployment in the
> global Internet.
Yes. And, in re-reading the text I think it is clear.
I really can't untangle your comments in this area. If you have
specific suggestions for the text, please send them along.
About this 'rock fetch' stuff (in terms of metrics and environments): We
do not solve the problem you outline ('go fetch another rock'). But, we
did not aim to solve that problem and we cannot solve that problem in
this document. We cannot enumerate all environments or all metrics that
might be of interest in the future. I sympathize with your desire for a
simple checklist that one can go through and be "ready", but this is all
much too complicated for a simple checklist. (Consider for a moment the
additional metrics that something like XCP brought to the table that
were not germane previously.) It is not clear to me that we should
pretend we can list metrics. Note that we have not made this 'rock
fetch' problem any worse, either. I.e., it exists for any new CC scheme
that would be run through without this document the same as with this
document.
I am not planning to further change the document with respect to adding
metrics or more about environments unless lots of people start yelling.
This document has been widely read at this point and as far as I know
nobody else has had this concern. (We can call the consensus 'rough' if
you prefer.)
> >> 4) The first evaluation criteria also includes "We also note that this
> >> guideline does not constrain the fairness offered for non-best-effort
> >> traffic."
> >
> > I don't understand your point here. All we are saying is that if---by
> > some means---we know that some flow is not best effort then it can be
> > subjected to some other criteria then it need not be constrained by the
> > guideline.
>
> What I try to say is that I can't figure out how operationally and
> practically this could be achieved. Do you have examples in mind
> how how this could apply in some specific scenario?
>
> If not -- and it isn't a practical concern right now -- maybe we
> should not overengineer the BCP to address best-effort vs
> non-best-effort at all.
We didn't overengineer anything. We just said that the guideline
doesn't apply to non-BE cases. I can't understand your point here at
all. It is a simple statement of document scope.
allman
pgpOP9EI2wHYf.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
On 2007-5-26, at 14:24, ext Pekka Savola wrote: (Note: this is still a draft version if you're referring to http://www.ietf.org/IESG/content/ions/drafts/ion-tsv-alt-cc.txt) This model raises one fundamental question issue of the scope of this document. Who should be evaluating section 3 and 4 of this document? Is this solely meant for ICCRG, the IETF or both? If both, would both parties do everything described in those documents? The basic idea behind this ION is that a researcher would bring his or her proposal, papers and experimental data to the ICCRG, which would then evaluate whether a proposal is safe for experimentation in the Internet or in more restricted network environments. (According to draft-ietf-tsvwg-cc-alt, and probably also draft-irtf-tmrg- metrics.) That review will accompany the resulting -00 technical specification when it is brought to the IETF. It would be clearer if the reviewer was ICCRG, and the IETF would not attempt to perform the same review, and the IETF wouldn't be allowed to second-guess the proposal, e.g., that it's research has not been done well enough if it was already positively evaluated by ICCRG. There is a strong expectation that the IETF would usually agree with the review recommendation that the ICCRG made, and take on the document. (Sufficient people overlap, the ICCRG has stronger congestion control expertise, etc.) But process-wise it *is* up the to the WG (likely TCPM) to come to consensus on whether they want to adopt any given work item, and that consensus call can't be outsourced to the ICCRG. But I would personally see it as a sign that something went very wrong if TCPM would not publish something as Experimental that came with a strong ICCRG review. Lars PS: I'm editing the ION in response to IESG comments. The latest working version is under http://www3.tools.ietf.org/group/iesg/trac/ browser/ions/drafts - I'd be interested in hearing suggestions on how the text could be improved. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
Hi Mark, Thanks for the prompt response, and sorry for a delay in responding. On Wed, 23 May 2007, Mark Allman wrote: 1) the document appears to be slightly inconsistent wrt. what it's actually specifying, or there are nuances that may not be sufficiently well articulated. The introduction speaks of "..evaluating suggested CC algorithms that _significantly differ_ from the general CC principles outlined in [RFC2914]" (emphasis mine). The abstract does not mention 'significantly differ', and there is Rule (0) which seems to imply that this BCP could be applied both to the mechanisms that significantly differ from the RFC2914 guidelines and other congestion control mechanisms that still honor the RFC 2914 guidelines. Which is it? Does it have implications on the different 'tracks'? I think you are reading a little much into this. I have just tweaked the language in the document to include 'significantly different' in the abstract and have changed (0) to this: (0) Differences with Congestion Control Principles [RFC2914] Proposed congestion control mechanisms that do should include a clear explanation of the deviations from [RFC2914]. Is that more clear? Yes (though '..that do should..' seemed weird on the first read). Section 2 also says "Each alternate CC algorithm published is required to include a statement in the abstract indicating whether or not the proposal is considered safe for use on the Internet". Which documents this applies to is not clear enough: all IETF documents (through WG or through an AD)? IAB documents? IRTF documents? Individual RFC-editor submissions? It is not clear to me whether this document would have the authority (without explicit discussion within the RFC-editor publications constituencies) to impose further requirements on non-IETF document streams especially if it doesn't include 'Updates: 3932' in its header. I suspect the document only means to affect the IETF RFC publication stream but is not clear enough about it. The document is intended to apply to IETF-produced documents. I added the following to the 'Status' section. Does this help? Note: we are not changing RFC publication process for non-IETF produced documents (e.g., those from the IRTF or independent RFC-Editor submissions). However, we would hope the guidelines in this document inform the IESG as they consider whether to add a note to such documents. Yes. Section 4 only talks of 'minimum requirements for a document to be approved as Experimental with approval for widespread deployment in the global Internet.' and further down "..approval for widespread deployment". What about the rest? Also, is omitting "in the global Internet" intentional? The flow of text doesn't go well as it is if that's the case, and if it's intentional, I'd rather use two entirely different wordings to make 'encouraged for widespread deployment' and 'encouraged for widespread deployment in the global Internet' more clearly distinct from each other. (Also, it isn't clear if the text is out of sync regarding guideline (2) compared to what it says in section 3 and what it says here.) I agree the text is a little weird. I beat it a little. Does this: The minimum requirements for approval for widespread deployment in the global Internet include guidelines (1) on assessing the impact on standard congestion control, (3) on investigation of the proposed mechanism in a range of environments, guideline (4) on protection against congestion collapse and guideline (8), discussing whether the mechanism allows for incremental deployment. For other guidelines, i.e., (2), (5), (6), and (7), evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. work better? (Maybe you meant to add 'following' before 'guidelines' in the 2nd line?) If 'following' or some such is added, the first paragraph is clearer on what the authors and reviewers should do: they should read through the listed guidelines and do what's required there. It might not be optimally clear whether the author _must_ do as 'shoulds' say in those guidelines or are those just suggestions. I'd guess you mean either "must do" or "must do, or justify why you haven't" but not "may do". What isn't clear enough is what the authors and reviewers should do for the case of 2nd paragraph's guidelines. Can the authors skip them completely, and the burden of proof that the proposal causes significantly more problems on the reviewer? Or do you mean that the proposers should do everything guidelines (2), (5), (6)
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
Pekka- > 1) the document appears to be slightly inconsistent wrt. what it's > actually specifying, or there are nuances that may not be sufficiently > well articulated. The introduction speaks of "..evaluating suggested > CC algorithms that _significantly differ_ from the general CC > principles outlined in [RFC2914]" (emphasis mine). The abstract does > not mention 'significantly differ', and there is Rule (0) which seems > to imply that this BCP could be applied both to the mechanisms that > significantly differ from the RFC2914 guidelines and other congestion > control mechanisms that still honor the RFC 2914 guidelines. Which is > it? Does it have implications on the different 'tracks'? I think you are reading a little much into this. I have just tweaked the language in the document to include 'significantly different' in the abstract and have changed (0) to this: (0) Differences with Congestion Control Principles [RFC2914] Proposed congestion control mechanisms that do should include a clear explanation of the deviations from [RFC2914]. Is that more clear? > Section 2 also says "Each alternate CC algorithm published is > required to include a statement in the abstract indicating whether > or not the proposal is considered safe for use on the Internet". > Which documents this applies to is not clear enough: all IETF > documents (through WG or through an AD)? IAB documents? IRTF > documents? Individual RFC-editor submissions? It is not clear to me > whether this document would have the authority (without explicit > discussion within the RFC-editor publications constituencies) to > impose further requirements on non-IETF document streams especially > if it doesn't include 'Updates: 3932' in its header. I suspect the > document only means to affect the IETF RFC publication stream but is > not clear enough about it. The document is intended to apply to IETF-produced documents. I added the following to the 'Status' section. Does this help? Note: we are not changing RFC publication process for non-IETF produced documents (e.g., those from the IRTF or independent RFC-Editor submissions). However, we would hope the guidelines in this document inform the IESG as they consider whether to add a note to such documents. > Section 4 only talks of 'minimum requirements for a document to be > approved as Experimental with approval for widespread deployment in > the global Internet.' and further down "..approval for widespread > deployment". What about the rest? Also, is omitting "in the global > Internet" intentional? The flow of text doesn't go well as it is if > that's the case, and if it's intentional, I'd rather use two > entirely different wordings to make 'encouraged for widespread > deployment' and 'encouraged for widespread deployment in the global > Internet' more clearly distinct from each other. (Also, it isn't > clear if the text is out of sync regarding guideline (2) compared to > what it says in section 3 and what it says here.) I agree the text is a little weird. I beat it a little. Does this: The minimum requirements for approval for widespread deployment in the global Internet include guidelines (1) on assessing the impact on standard congestion control, (3) on investigation of the proposed mechanism in a range of environments, guideline (4) on protection against congestion collapse and guideline (8), discussing whether the mechanism allows for incremental deployment. For other guidelines, i.e., (2), (5), (6), and (7), evidence that the proposed mechanism has significantly more problems than those of TCP should be a cause for concern in approval for widespread deployment in the global Internet. work better? > 2) the document requires that 'serious scientific study .. needs to have > been done'. Yet there is no metrics an outsider could use to evaluate > whether this test is met or not. It may be that TCP congestion > control community has de-facto oral tradition what needs to be > evaluated before an algorithm can be looked at seriously, but based on > this proposed BCP, such metrics are not clear enough. > > Unless we can define clearer requirements and metrics for evaluation, > perhaps the IETF should not attempt to make such an evaluation but > leave it to the scientific community. I'm not sure how the IETF can > liaise with the scientific community on that, e.g., whether it's > possible to get a consensus statement from IRSG or an IRTF RG or > something that could meet this requirement (if we don't want specify > these criteria within the IETF). The IETF and the IR
Re: Last Call: draft-ietf-tsvwg-cc-alt (Specifying New Congestion Control Algorithms) to BCP
On Fri, 4 May 2007, The IESG wrote: The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Specifying New Congestion Control Algorithms ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-05-18. Sorry for missing the comment DL by a couple of days. Too slow to I believe this document is in a serious need of more work regarding its applicability and evaluation criteria. Some of the TCP community may already be aware of (some of) these criteria through oral and/or scientific tradition. However if IETF is requested to perform evaluation of these congestion control mechanisms by writing a BCP on it, it seems conducting a fair evaluation is impossible if it isn't clear enough what is evaluated. More below. substantial --- 1) the document appears to be slightly inconsistent wrt. what it's actually specifying, or there are nuances that may not be sufficiently well articulated. The introduction speaks of "..evaluating suggested CC algorithms that _significantly differ_ from the general CC principles outlined in [RFC2914]" (emphasis mine). The abstract does not mention 'significantly differ', and there is Rule (0) which seems to imply that this BCP could be applied both to the mechanisms that significantly differ from the RFC2914 guidelines and other congestion control mechanisms that still honor the RFC 2914 guidelines. Which is it? Does it have implications on the different 'tracks'? Section 2 also says "Each alternate CC algorithm published is required to include a statement in the abstract indicating whether or not the proposal is considered safe for use on the Internet". Which documents this applies to is not clear enough: all IETF documents (through WG or through an AD)? IAB documents? IRTF documents? Individual RFC-editor submissions? It is not clear to me whether this document would have the authority (without explicit discussion within the RFC-editor publications constituencies) to impose further requirements on non-IETF document streams especially if it doesn't include 'Updates: 3932' in its header. I suspect the document only means to affect the IETF RFC publication stream but is not clear enough about it. Section 4 only talks of 'minimum requirements for a document to be approved as Experimental with approval for widespread deployment in the global Internet.' and further down "..approval for widespread deployment". What about the rest? Also, is omitting "in the global Internet" intentional? The flow of text doesn't go well as it is if that's the case, and if it's intentional, I'd rather use two entirely different wordings to make 'encouraged for widespread deployment' and 'encouraged for widespread deployment in the global Internet' more clearly distinct from each other. (Also, it isn't clear if the text is out of sync regarding guideline (2) compared to what it says in section 3 and what it says here.) All things considered, the document needs to be much clearer what its scope is intended to be, and if the document applies to a number of different kinds of CC algorithms, more clearly define which rules apply to which categories of documents. 2) the document requires that 'serious scientific study .. needs to have been done'. Yet there is no metrics an outsider could use to evaluate whether this test is met or not. It may be that TCP congestion control community has de-facto oral tradition what needs to be evaluated before an algorithm can be looked at seriously, but based on this proposed BCP, such metrics are not clear enough. Unless we can define clearer requirements and metrics for evaluation, perhaps the IETF should not attempt to make such an evaluation but leave it to the scientific community. I'm not sure how the IETF can liaise with the scientific community on that, e.g., whether it's possible to get a consensus statement from IRSG or an IRTF RG or something that could meet this requirement (if we don't want specify these criteria within the IETF). Also, checklist (2) has "A minimum goal for experimental mechanisms proposed for widespread deployment in the Internet should be that they do not perform significantly worse than TCP in these environments." However, 'these environments' refers to a non-exhaustive list of scenarios. This checklist does not provide adequate information to evaluate whether sufficient testing in the non-exhaustively defined "difficult environments" has taken place or not. I do not believe we can require assessments in various environments unless it's better specified what which environmets
Re: Congestion control
At 10:20 AM 12/18/00 -0800, Bob Hinden wrote: >I find it amusing that this debate on how to handle "congestion" at IETF >meetings mirrors the technical debate on congestion in the Internet. The >two sides still seem to be "more bandwidth" or "apply QOS". Actually, there are three avenues under discussion. "More bandwidth", and "ensuring access for the critical participants" are the ones you mentioned. The third is "apply random early detection with sufficient force to ensure that the meeting fits in the room." Reality, IMHO, involves some elements of each of the above. Our experience has been that we do indeed get the largest venues we can consistent with the projected attendance, and we do in fact ask people to let the folks who have read and posted drafts get in the room. BOFs are often decided weeks in advance, while venues must be contracted months to years in advance, and people decide what to attend as little as minutes before entering the room. I get impatient with the summary dismissal of people as "tourists", but in point of fact when I have ten contributors in a room that will hold 100 and I have another hundred telling me that "the conference attendance is 2700, divide by 8 and make sure that every room will hold that number of people", I do begin to wonder whether every single one of those people is in fact critical to conducting the meeting.
Re: Congestion control
wait for the Assured Seating (AS) Per Hotel Behavior (PHB) with multiple drop precedence levels badges are marked on ingress to the room based on willingness to work... the chair drops people marked "dead weight" first as the room fills in order to come up with another diffserv-related acronym, sophisticated chairs use reverse RED (Read Every Draft) to boot out those who havent. cheers, gja Bob Hinden wrote: > > I find it amusing that this debate on how to handle "congestion" at IETF > meetings mirrors the technical debate on congestion in the Internet. The > two sides still seem to be "more bandwidth" or "apply QOS". > > Bob -- Grenville Armitagehttp://members.home.net/garmitage/ Bell Labs Research Silicon Valley
Re: Congestion control
I find it amusing that this debate on how to handle "congestion" at IETF meetings mirrors the technical debate on congestion in the Internet. The two sides still seem to be "more bandwidth" or "apply QOS". Bob
Re: Congestion control
At 11:25 AM 12/17/00 -0800, Paul Hoffman / IMC wrote: >WG chair says "OK, the room is now over-full. Who are there people in the >doorway or outside who intend to work actively on drafts or forming the >charter for this group? I see seven hands up. Could fourteen people who >are currently sitting or jammed up against a wall who do *not* already >plan to work actively on drafts This is among the set of reasonable procedures to follow when there is congestion. As with each technique suggested, there are benefits and there are problems. However the premise to my suggestion is that we are growing and are going acquire larger venues eventually. So let's acquire them a little sooner and avoid the pain of congestion and imperfections and inconveniences of all these congestion management techniques. d/ ps. The plea for less active attendees to move works once. It does not cover late arrivals. Taking a Draconian attitude towards active participants who arrive late is an example of the imperfection of the management techique. =-=-=-=-= Dave Crocker <[EMAIL PROTECTED]> Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464
Re: Congestion control
WG chair says "OK, the room is now over-full. Who are there people in the doorway or outside who intend to work actively on drafts or forming the charter for this group? I see seven hands up. Could fourteen people who are currently sitting or jammed up against a wall who do *not* already plan to work actively on drafts or forming the charter for this group please be polite and leave? I will announce the mailing list address for this BOF on [EMAIL PROTECTED] if we get anywhere during this hour. Also, look for an announcement of a Bar BOF on the messages board later today. OK, about ten people have left. Thanks!" This, of course, relies on the early sitters being polite and patient, but that has been known to happen at various times in IETF history. --Paul Hoffman, Director --Internet Mail Consortium
Re: Congestion control
On Fri, 15 Dec 2000, Henning G. Schulzrinne wrote: > Then, there's always the Scout Jamboree option: build an Internet tent > city. I'd imagine Burning Man has more attendees than the IETF and it > seems to draw some of the same crowd. Interop tried this at Vegas shows from, what, '96 through '98, when they outgrew the LVCC :) Marketing called it the HTFE -- "High Tension Fabric Enclosure", but the NOC team preferred "Temporary Enclosure Needing Tension" -- TENT. -- Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/ -- "There were other lonely singers / in a world turned deaf and blind Who were crucified for what they tried to show. Their voices have been scattered by the swirling winds of time, 'Cause the truth remains that no one wants to know." - Kris Kristofferson, "To Beat the Devil"
Re: Congestion control
At 12:24 PM 12/15/00 -0800, Fred Baker wrote: >I have asked the Secretariat to advise me, quantitatively, of the >implications of making that leap. I can tell you up front that it has >implications for either the meeting fee or the corporate sponsorship. And that impact is precisely why I phrased my suggestion as a question. On the other hand, we are growing, so that impact will be felt at some point, no matter what. The congestion problem hits us regularly, so it seems worth looking for some sort of basic change to eliminate it. I do not believe that better "planning" is really feasible; too many variables the planners cannot predict or control. I also do not believe that restricted attendance or other draconian administrative practises are appropriate; they would dramatically alter the nature and dynamic of our communal get togethers. More space is entirely practical, except for the open question of cost. But since growth ensures we encounter the problem eventually, let's gain the upside from it sooner rather than later. d/ =-=-=-=-= Dave Crocker <[EMAIL PROTECTED]> Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464
Re: Congestion control
"Henning G. Schulzrinne" wrote: > > In case the IETF is truly desperate: We could also rent out a major > university during the summer and stick everybody in dorm rooms - that > should be enough to discourage the tourists and evoke the roots of the > Internet :-) Many a true word is said in jest cheers, gja
Re: Congestion control
Fred Baker <[EMAIL PROTECTED]> writes: > I don't know if you are aware of it, but there is a very simple > algorithm for determining what the "conference hotel" will be for any > given meeting. Ask what city it is in, and find out what the largest > hotel is. > > > We are already going to the largest places we can find short of going to > conference centers; in some cases, we are already using conference > centers. I have asked the Secretariat to advise me, quantitatively, of > the implications of making that leap. I can tell you up front that it > has implications for either the meeting fee or the corporate > sponsorship. > IMO that is becoming obvious and although some people will hate the idea, I think the latter option is probably the only realistic one. We still need to make it reasonably easy enough for anyone to attend. Therefore we can't afford to blowout the cost of coming to an IETF so that only those individuals working for companies with deep enough pockets can attend. Cheers, -- John Collis IndraNet Technologies Ltd. Email: [EMAIL PROTECTED]
Re: Congestion control
In case the IETF is truly desperate: We could also rent out a major university during the summer and stick everybody in dorm rooms - that should be enough to discourage the tourists and evoke the roots of the Internet :-) I'm sure OSU has classroom space for a few ten thousand students... Then, there's always the Scout Jamboree option: build an Internet tent city. I'd imagine Burning Man has more attendees than the IETF and it seems to draw some of the same crowd. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs
Re: Congestion control
At 04:57 PM 12/14/00 -0800, Jelena Mirkovic wrote: >Would it not be a nice idea to simply find a hotel with enough number >of big rooms so that everyone who wants can fit in? I don't know if you are aware of it, but there is a very simple algorithm for determining what the "conference hotel" will be for any given meeting. Ask what city it is in, and find out what the largest hotel is. We are already going to the largest places we can find short of going to conference centers; in some cases, we are already using conference centers. I have asked the Secretariat to advise me, quantitatively, of the implications of making that leap. I can tell you up front that it has implications for either the meeting fee or the corporate sponsorship.
Re: Congestion control
At 07:58 AM 12/15/00 -0800, Scott Brim wrote: >So, throwing bandwidth at the problem is quite cost-effective in about >85% of the cases, and congestion control is most useful at aggregation >points, say where enterprise networks meet regional networks. It would >seem then, that we should solve the meeting room congestion by getting >really big rooms, and control access to the halls? It is possible to avoid congestion entirely. Use beaches. There may be other problems :^)
Re: Congestion control
--- Keith Moore <[EMAIL PROTECTED]> wrote: > We'd need to adopt drastically different methods for > running a working group and for making decisions. I agree whole heartedly. How ever when do we put a stake in the ground to beging this? > I also suspect it's much easier for thirty people to > come up with a good technical solution, than for > > three thousand or even three hundred, even if the > clue density remains the same for each case. > > Keith Again I agree, however what happens when 3000 want to have their opinion heard? How do we filter them all down to something manageable? Again I would offer a warning flag that the IETF will need to be ready for rapid growth and exposure. Gabriel __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: Congestion control
At 16:57 14/12/2000 -0800, Jelena Mirkovic wrote: >Eso some people get cut off even during registration process??? >What does it mean active? How about newcomers? >Would it not be a nice idea to simply find a hotel with enough number >of big rooms so that everyone who wants can fit in? At least at >registration time? And then you can have stand-by for people that did not >register but suddenly decided they would like to attend some sessions. there is a little problem with the timelines of IETF planning... if you have a BOF meeting at time T, the timeline is roughly: T-2 years: Contract with hotel is signed T-3 months: Most participants register T-2 months: BOF proponents start registering T-1 month: BOF is announced T-1 week: BOF agenda is posted T-3 days: Last BOF participants decide to attend the IETF T-5 minutes: Lots of IETF participants decide to attend the BOF T: BOF happens T+5 minutes: Complaints about room crowding hit the IETF list :-) If someone wants changes to earlier decisions based on events that happen later, please send one (1) time machine to the IETF secretariat. (guessing is what we already do!) -- Harald Tveit Alvestrand, [EMAIL PROTECTED] +47 41 44 29 94 Personal email: [EMAIL PROTECTED]
Re: Congestion control
One suggestion: given that one or two "channels" of video/audio is always available during the meeting, and given that a number of people simply want to "see what is going on" (regardless of the merit of this), why not pipe the 2 channels onto the hotel TV channels?. This was done during the recent ICANN meeting in LA and worked very well. Since 99% of all the action was on stage, you could easily follow the proceedings from the comfort of your hotel room. It's not a complete solution, but it does at least allow people to follow (some of) the meetings they cannot physically get into. Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj
Re: Congestion control
> I think we need to look to the future where > three thousand participants are going to offer up > their ideas and we need to be able to take advantage > of those resources without stuff "getting dropped" > simply because of the meeting space/format. Perhaps. But in a forum with three thousand participants, I doubt that either space or bandwidth are the primary barriers to producing a consensus around sound technical solutions. In other words, even assuming we had the space/bandwidth to accomodate them all, three thousand people is far too many for a single group discussion. We'd need to adopt drastically different methods for running a working group and for making decisions. I also suspect it's much easier for thirty people to come up with a good technical solution, than for three thousand or even three hundred, even if the clue density remains the same for each case. Keith
Re: Congestion control
On 14 Dec 2000 at 17:31 -0800, Dave Crocker apparently wrote: > At 03:58 PM 12/14/00 -0800, Scott Brim wrote: > >Building on a previous suggestion: > > Just to be clear, my suggestion is diametrically opposed to the list that > you specified. > > You are suggesting very tight queue management. By the mid-70's, Kleinrock > showed that these mechanisms do not work in the face of sustained > overload. They only work when the problem is transient. > > Rather than trying to manage the congestion, I am suggesting that we throw > money at the problem, to overbuy space so that we don't have the problem. So, throwing bandwidth at the problem is quite cost-effective in about 85% of the cases, and congestion control is most useful at aggregation points, say where enterprise networks meet regional networks. It would seem then, that we should solve the meeting room congestion by getting really big rooms, and control access to the halls? ...Scott
Re: Congestion control
I am not sure exactly how IETF meetings are executed or how business is conducted, but the group may consider occupying an indoor stadium, etc. With the basic floor space available (convention like) organizers would be able to resize areas to fit audiences accordingly. More importantly sooner or later these meetings are going to be impossible for everyone to reach on a global/space planning/agenda/not enough band-width basis. I think we need to look to the future where three thousand participants are going to offer up their ideas and we need to be able to take advantage of those resources without stuff "getting dropped" simply because of the meeting space/format. Perhaps there should be some sort of use of technology to broadcast/capture the content and make it available to everyone on a global scale. Put fifty people who really want to contribute into a small space and watch the blood bath. I think we as a technology minded think tank should try to look towards capturing all these ideas spilling forth and make it available on an Internet scale. This would help with space planning (a virtual conference room) as well as order of business/capturing good content. (I as a willing reader cannot afford to trot the globe to hear all the goodies!) Regards, Gabriel --- Dave Crocker <[EMAIL PROTECTED]> wrote: > Rather than trying to carefully provide "enough" > meeting room capacity for > expected attendance, what would be the effect of > reserving *too much* > capacity for our meetings? > > d/ > > =-=-=-=-= > Dave Crocker <[EMAIL PROTECTED]> > Brandenburg Consulting > Tel: +1.408.246.8253, Fax: +1.408.273.6464 > __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
Re: Congestion control
On Thu, Dec 14, 2000 at 02:36:18PM -0800, Dave Crocker wrote: > For an industry that has been predicated on queuing theory that permits > managing data traffic through moments of transient congestion, the idea > that the best way to achieve Quality of Service is simply to throw excess > bandwidth at the problem is quaint. > > On the other hand, that simplistic congestion control approach has some > appeal for planning IETF meeting capacity. > > Rather than trying to carefully provide "enough" meeting room capacity for > expected attendance, what would be the effect of reserving *too much* > capacity for our meetings? there are other solutions, of course. Besides an "admission examination" for attendants, "right" choice of the venue may cut attendance. Think at how many people would have come to Minneapolis in December. (On the downside, those people would have not gone outside the hotel, so congestion could have been even worse) My personal experience shows that BOFs are the most overcrowded meetings: I don't know whether this is the result of a biased estimation (nobody knows in advance who will participate to a BOF, since there is no official group), but I also believe that people stay there just to see what happens, and this is much easier than to attend a regular WG meeting, where people talk about actual drafts (ok, *some* people talk, but the idea is this one). Maybe a "preparatory mailing list" one month before the meeting may help to tell the bona fide participants, and allow to give them a "premium pass" ... ciao ,.mau.
Re: Congestion control
At 03:58 PM 12/14/00 -0800, Scott Brim wrote: >Building on a previous suggestion: Just to be clear, my suggestion is diametrically opposed to the list that you specified. You are suggesting very tight queue management. By the mid-70's, Kleinrock showed that these mechanisms do not work in the face of sustained overload. They only work when the problem is transient. Rather than trying to manage the congestion, I am suggesting that we throw money at the problem, to overbuy space so that we don't have the problem. d/ =-=-=-=-= Dave Crocker <[EMAIL PROTECTED]> Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464
Re: Congestion control
I think this is a really, really, really bad idea. This is my first IETF. I had read all the drafts of what interested me before going here. I thought that was enough. Boy was I wrong. I am now also subscribed to the mailiglists... However, I have been to several of the other gatherings of the same people (mostly RIPE) and I thought I was somewhat prepeared for what this woudl be like. I wasn't. This was unlike anything I have seen so far. I have learnt alot and I have really enjoyed following the discussions and meeting the people. This was my first IETF but hopefully not the last. I have learnt some of how the IETF works. I will be following the mailinglist discussions, and maybe I can contribute something. Maybe I oneday in the future can contribute something at a meeting. I hope so. I don't think that this "awakening" should be limited to people that have been active on mailinglists. It's not the same thing, and it will "scare" people off. I really hope that instead the logistical problems can be overcome. - kurtis - On Thu, 14 Dec 2000, Scott Brim wrote: > Given that the overcrowding at this IETF was the worst ever, and really > interfered with work, not to mention the social event ... > > Building on a previous suggestion: > > * When you register for the IETF, you specify which WGs you are > interested in in priority order. > > * Simultaneously WG Chairs submit lists of people who are active. This > includes chairs for new WGs and BOFs. > > * The agenda and room assignments coalesce based in part on expected > attendance -- this probably continues to require hand-crafting. > > * Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. > > * People receive mail saying which WGs they have been granted access to. > They can apply for more, but they probably won't get in, which means > there is a strong incentive to have specific reasons why they want to > go to the IETF when they register in the first place. > > * When they come to the IETF their packets contain not only a receipt > (the point being that the packets are already individualized) but an > authenticated (anything, a little ink stamp, even) schedule, which > they have to show at the meeting room door to get in the room. > > * "Standby" entry is allowed if there are seats not taken 5 minutes > before the meeting starts. > > > Details can be explored based on what you think of this in principle. > > ...Scott >
Re: Congestion control
(Continuing this for its value in exploring the issues ...) On 14 Dec 2000 at 16:57 -0800, Jelena Mirkovic apparently wrote: > >* Software magically takes registrant WG preferences and fills rooms, > > giving priority to those who have been active (purely according to WG > > chairs). Once a room is full no one is added. OK, this is the > > cruddiest part, but leave the details for now. > Eso some people get cut off even during registration process??? > What does it mean active? How about newcomers? How about newcomers? IETF activity takes place primarily on mailing lists. IETF meetings are to resolve issues and reach closure. If you're not active, why are you coming? > Would it not be a nice idea to simply find a hotel with enough number > of big rooms so that everyone who wants can fit in? At least at > registration time? And then you can have stand-by for people that did not > register but suddenly decided they would like to attend some sessions. Yes of course. Our capacity needs are going beyond the capability of most meeting sites. ...Scott
Re: Congestion control
I think this is a really, really, really bad idea. This is my first IETF. I had read all the drafts of what interested me before going here. I thought that was enough. Boy was I wrong. I am now also subscribed to the mailiglists... However, I have been to several of the other gatherings of the same people (mostly RIPE) and I thought I was somewhat prepeared for what this woudl be like. I wasn't. This was unlike anything I have seen so far. I have learnt alot and I have really enjoyed following the discussions and meeting the people. This was my first IETF but hopefully not the last. I have learnt some of how the IETF works. I will be following the mailinglist discussions, and maybe I can contribute something. Maybe I oneday in the future can contribute something at a meeting. I hope so. I don't think that this "awakening" should be limited to people that have been active on mailinglists. It's not the same thing, and it will "scare" people off. I really hope that instead the logistical problems can be overcome. - kurtis - On Thu, 14 Dec 2000, Scott Brim wrote: > Given that the overcrowding at this IETF was the worst ever, and really > interfered with work, not to mention the social event ... > > Building on a previous suggestion: > > * When you register for the IETF, you specify which WGs you are > interested in in priority order. > > * Simultaneously WG Chairs submit lists of people who are active. This > includes chairs for new WGs and BOFs. > > * The agenda and room assignments coalesce based in part on expected > attendance -- this probably continues to require hand-crafting. > > * Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. > > * People receive mail saying which WGs they have been granted access to. > They can apply for more, but they probably won't get in, which means > there is a strong incentive to have specific reasons why they want to > go to the IETF when they register in the first place. > > * When they come to the IETF their packets contain not only a receipt > (the point being that the packets are already individualized) but an > authenticated (anything, a little ink stamp, even) schedule, which > they have to show at the meeting room door to get in the room. > > * "Standby" entry is allowed if there are seats not taken 5 minutes > before the meeting starts. > > > Details can be explored based on what you think of this in principle. > > ...Scott >
Re: Congestion control
>* Software magically takes registrant WG preferences and fills rooms, > giving priority to those who have been active (purely according to WG > chairs). Once a room is full no one is added. OK, this is the > cruddiest part, but leave the details for now. Eso some people get cut off even during registration process??? What does it mean active? How about newcomers? Would it not be a nice idea to simply find a hotel with enough number of big rooms so that everyone who wants can fit in? At least at registration time? And then you can have stand-by for people that did not register but suddenly decided they would like to attend some sessions. Jelena
Re: Congestion control
Given that the overcrowding at this IETF was the worst ever, and really interfered with work, not to mention the social event ... Building on a previous suggestion: * When you register for the IETF, you specify which WGs you are interested in in priority order. * Simultaneously WG Chairs submit lists of people who are active. This includes chairs for new WGs and BOFs. * The agenda and room assignments coalesce based in part on expected attendance -- this probably continues to require hand-crafting. * Software magically takes registrant WG preferences and fills rooms, giving priority to those who have been active (purely according to WG chairs). Once a room is full no one is added. OK, this is the cruddiest part, but leave the details for now. * People receive mail saying which WGs they have been granted access to. They can apply for more, but they probably won't get in, which means there is a strong incentive to have specific reasons why they want to go to the IETF when they register in the first place. * When they come to the IETF their packets contain not only a receipt (the point being that the packets are already individualized) but an authenticated (anything, a little ink stamp, even) schedule, which they have to show at the meeting room door to get in the room. * "Standby" entry is allowed if there are seats not taken 5 minutes before the meeting starts. Details can be explored based on what you think of this in principle. ...Scott
Congestion control
For an industry that has been predicated on queuing theory that permits managing data traffic through moments of transient congestion, the idea that the best way to achieve Quality of Service is simply to throw excess bandwidth at the problem is quaint. On the other hand, that simplistic congestion control approach has some appeal for planning IETF meeting capacity. Rather than trying to carefully provide "enough" meeting room capacity for expected attendance, what would be the effect of reserving *too much* capacity for our meetings? For example, ensure that rooms are 50% larger than we think they need to be and make sure there are some extra rooms, in case we need to move an oversubscribed group to a larger room. The only two effects I can think of are: extra dollars and further restrictions on where we can meet. The latter is inevitable given our growth, the planning trick would merely accelerate the constraint. How bad would the extra cost be? Given the work we do in these meetings and the negative effect of overcrowding, is the extra cost worthwhile? d/ =-=-=-=-= Dave Crocker <[EMAIL PROTECTED]> Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464
Re: Re: Critically compare the congestion control on TCP/IP and ATM
At 20:31 03/09/2000 +0800, Jianbo Huang wrote:
>Dear Sir/Madam,
>
>generally speaking, TCP/IP is equal to the transport and network layer
>in the OSI model, and it seems that the ATM works on the Data Link Layer
>(?). They serve different function in the OSI model. Through they all
>have congestion control facility, how to compare mechanism in different
>layer?
Both are protocol suites. The ATM protocol suite actually includes not
just the ATM layer protocol ("ATM") but lots more including a layer 4
reliable transport mechanism. Each has control signaling at multiple
layers. Just compare the pieces of each that provide similar functionality.
Re: Critically compare the congestion control on TCP/IP and ATM?
The biggest worry to me is that depite all the promises offered and realities measured in the labs on all this MPLS, IP switching etc etc -- Internet protocol cannot provide the QoS for voice and video multicasting with 5 Nines reliability. IETF and Carrier Class 5 Nines reliability in a bulletproof manner are like 2 cities still poles apart. Efficiency feathers went to IP- cannot we be a little more honest and praise the Optical media and the Fibres since even POS needs layer 1 optical PHYs. Traffic management is another name of 99.9% reliabiity at the end of the day ! Just a comment , we are comparing apples with Oranges ! thx getty Sean Doran wrote: > Dan Grossman writes: > > | ATM has a carefully defined traffic management architecture. > > Yes, that's its problem. > > From issue 10 of "New Carrier" (http://www.totaltele.com/newcarrier", p 22: > > ... the past several years' debates over the relative technical > merits of [the] Internet Protocol versus other network technologies > like ATM, often missed the point. IP and its associated technologies > haven't taken over because they produce a brilliantly efficient network, > but because they together seem capable of creating a dynamic > openness for the network economy; this is because of, and not > despite, a simplicity and a lack of carrier-style attributes. > > Sean.
Re: Critically compare the congestion control on TCP/IP and ATM?
Dan Grossman writes: | ATM has a carefully defined traffic management architecture. Yes, that's its problem. >From issue 10 of "New Carrier" (http://www.totaltele.com/newcarrier", p 22: ... the past several years' debates over the relative technical merits of [the] Internet Protocol versus other network technologies like ATM, often missed the point. IP and its associated technologies haven't taken over because they produce a brilliantly efficient network, but because they together seem capable of creating a dynamic openness for the network economy; this is because of, and not despite, a simplicity and a lack of carrier-style attributes. Sean.
Re: Critically compare the congestion control on TCP/IP and ATM?
> -Original Message- > From: Fred Baker [SMTP:[EMAIL PROTECTED]] > Sent: Friday, March 10, 2000 5:32 AM > To: Jianbo Huang > Cc: [EMAIL PROTECTED] > Subject: Re: Critically compare the congestion control on TCP/IP > and ATM? > > At 05:57 PM 3/9/00 +0800, Jianbo Huang wrote: > >Dear Sirs and Madams, > > > >A friend of mine are working on the paper on "critically compare the > >congestion control on TCP/IP and ATM", and she ask me for help. But I > do > >not get much idea on the "congestion control on ATM". So, is there > anyone > >can give me any idea on this topic, while my friend and I processing > on this? > ATM has a carefully defined traffic management architecture. Read: www.atmforum.com/pub/approved-specs/af-tm-0121.000.pdf In short, it supports a strong distinction between elastic and inelastic traffic, and provides distinct services to support each. For inelastic traffic, there is an open loop control system which shapes and polices traffic to traffic contracts defined by token buckets. Signalling triggers admission control and bandwidth reservation. Meaningful guarantees on delay, delay jitter and loss can be offered to traffic streams that conform to the traffic contract. For elastic traffic there are several options: An available bitrate (ABR) service category provides a control loop for matching the rate of each virtual connection (VC) to the larger of a nominal fair share of the bottleneck bandwidth of the path, and a negotiated minimum. End-system behavior is standardized. Switches can either directly indicate the allowed cell rate in resource management cells which are sent periodically, or can use a binary feedback system (mostly for backward compatibility). ABR provides excellent isolation, fairness, and protection against misbehaved VCs. When the end-system behavior rules are honored, there is little if any cell loss. ABR is also resistant to performance problems associated with errored links, highly asymetrical links and long bandwidth-delay product links. The unspecified bitrate (UBR) and guaranteed frame rate (GFR) service categories offer a best-effort service like IP. They depend on packet discard and end-to-end behavior (as in TCP) for stability. Modern implementations have a separate queue for each VC, and provide at least that level of isolation and fairness. There is no admission control. > that's easy; there isn't any. See the ATM Forum Traffic Managment specification >There is ingress port policing, which is > > something different, No, it's one component of the system, especially as applied to inelastic traffic. > and there may be PNNI call routing. That's another component of the system, but operates on a different timescale, and only in the context of signalling and admission control (as well as being a critical network optimization) > But there is > not > anything that corresponds to what TCP expects from its underlying > layers. What do you think is missing for UBR and GFR? The semantics are effectively the same: feedback control using packet loss as a signal. > There have been some papers written and a fair bit of experience with > a > technique for mitigating this, called Early packet Discard. In > essence, if > a link is becoming congested, rather than dropping a single cell, if > it has > to drop an AAL5 cell it drops the entire packet containing the cell. > This > may sound odd, but it is actually quite sensible - if the other cells > were > not also dropped, then they would uselessly occupy bandwidth on > subsequent > links, and at the final delivery point would consume memory > unnecessarily > until the SAR was able to determine that the cell had been dropped. Ah, the segmentation and reassembly problem. EPD is not a congestion control mechanism per se, but rather a correction to an impedence mismatch between the minimum unit that can be dropped (a cell) and the minimum unit which is useful (a packet). There were a couple of papers about this in 1993 (see Sally Floyd's web page), and it was incorporated into the ATM standards. All modern implementations support EPD and PPD. Certainly not a point that I would pick as being one of the most salient in a discussion of ATM congestion control.
Re: Critically compare the congestion control on TCP/IP and ATM?
ATM ABR offers explicit closed loop feedback about congestion experienced, and will drop cells/frames if that feedback is not followed. In certain types of VBR the CLP bit can be used to indicate that a cell was out of profile. Such cells do not have to be dropped if the network has room for them. Fred Baker wrote: > At 05:57 PM 3/9/00 +0800, Jianbo Huang wrote: > >Dear Sirs and Madams, > > > >A friend of mine are working on the paper on "critically compare the > >congestion control on TCP/IP and ATM", and she ask me for help. But I do > >not get much idea on the "congestion control on ATM". So, is there anyone > >can give me any idea on this topic, while my friend and I processing on this? > > that's easy; there isn't any. There is ingress port policing, which is > something different, and there may be PNNI call routing. But there is not > anything that corresponds to what TCP expects from its underlying layers. > > There have been some papers written and a fair bit of experience with a > technique for mitigating this, called Early packet Discard. In essence, if > a link is becoming congested, rather than dropping a single cell, if it has > to drop an AAL5 cell it drops the entire packet containing the cell. This > may sound odd, but it is actually quite sensible - if the other cells were > not also dropped, then they would uselessly occupy bandwidth on subsequent > links, and at the final delivery point would consume memory unnecessarily > until the SAR was able to determine that the cell had been dropped.
Re: Critically compare the congestion control on TCP/IP and ATM?
At 05:57 PM 3/9/00 +0800, Jianbo Huang wrote: >Dear Sirs and Madams, > >A friend of mine are working on the paper on "critically compare the >congestion control on TCP/IP and ATM", and she ask me for help. But I do >not get much idea on the "congestion control on ATM". So, is there anyone >can give me any idea on this topic, while my friend and I processing on this? that's easy; there isn't any. There is ingress port policing, which is something different, and there may be PNNI call routing. But there is not anything that corresponds to what TCP expects from its underlying layers. There have been some papers written and a fair bit of experience with a technique for mitigating this, called Early packet Discard. In essence, if a link is becoming congested, rather than dropping a single cell, if it has to drop an AAL5 cell it drops the entire packet containing the cell. This may sound odd, but it is actually quite sensible - if the other cells were not also dropped, then they would uselessly occupy bandwidth on subsequent links, and at the final delivery point would consume memory unnecessarily until the SAR was able to determine that the cell had been dropped.
Re: Re[2]: Re: Critically compare the congestion control on TCP/
the best work i know of on TCP behaviour _over_ ATM services is the thesis (and papers by) Olivier Bonaventure - http://www.info.fundp.ac.be/~obo/ cheers jon
RE: Re[2]: Re: Critically compare the congestion control on TCP/
At 11:16 AM 03/09/2000 -0600, Schipper, Dell wrote: >I recall that Larry Roberts a few years ago gave presentations (at >NetWorld+InterOp ?) that compared the congestion avoidance algorithms of >ATM-ABR service to TCP/IP. I know he has started a new company since >then and I do not have any contact information. One of my favorites along those lines was: "End-to-End Traffic Management Issues in IP/ATM Internetworks," draft-jagan-e2e-traf-mgmt-00.txt, S. Jagannath and N. Yin, August 1997. - paul [snip] Abstract This document addresses the end-to-end traffic management issues in IP/ATM internetworks. In the internetwork environment, the ATM control mechanisms (e.g., Available Bit Rate (ABR) and UBR with Early Packet Discard (EPD)) are applicable to the ATM subnetwork, while the TCP flow control extends from end to end. We investigated the end to end performance in terms of TCP throughput and file transfer delay in cases using ABR and UBR in the ATM subnetwork. In this document, we also discuss the issue of trade-off between the buffer requirements at the ATM edge device (e.g., Ethernet-ATM switch, ATM router interface) versus ATM switches inside the ATM network. Our simulation results show that in certain scenarios (e.g., with limited edge device buffer memory) UBR with EPD may perform comparably to ABR or even outperform ABR. We show that it is not sufficient to have a lossless ATM subnetwork from the end-to-end performance point of view. The results illustrate the necessity for an edge device congestion handling mechanism that can couple the ABR and TCP feedback control loops. We present an algorithm that makes use of the ABR feedback information and edge device congestion state to make packet dropping decisions at the edge of the ATM network. Using the algorithm at the edge device, the end-to-end performance in throughput and delay are improved while using ABR as the ATM subnetwork technology and with small buffers in the edge device. [snip]
RE: Re[2]: Re: Critically compare the congestion control on TCP/
I recall that Larry Roberts a few years ago gave presentations (at NetWorld+InterOp ?) that compared the congestion avoidance algorithms of ATM-ABR service to TCP/IP. I know he has started a new company since then and I do not have any contact information. Regards, Dell. __ Dell Schipper Phone: (214) 495-6422 Advanced Network Solutions Fax: (214) 495-6219 Fujitsu Network Services[EMAIL PROTECTED] __
Re[2]: Re: Critically compare the congestion control on TCP/
If you receive any good answers on this, please let me know. Thanx. Michael B. Bellopede [EMAIL PROTECTED] Reply Separator Subject:Re: Re: Critically compare the congestion control on TCP/IP Author: Jianbo Huang <[EMAIL PROTECTED]> Date: 3/9/00 8:31 PM Dear Sir/Madam, Thank you all for giving me so much information! I have read some, and almost get a clear idea of how ATM manage the congestion control. But I still get one question: generally speaking, TCP/IP is equal to the transport and network layer in the OSI model, and it seems that the ATM works on the Data Link Layer (?). They serve different function in the OSI model. Through they all have congestion control facility, how to compare mechanism in different layer? Does the topic "Critically compare the congestion control on TCP/IP and ATM" mean only compare of the algorithms of them? Thank you again for you valuable help! rgds, Truly yours, Jianbo Huang :-)
Re: Re: Critically compare the congestion control on TCP/IP and ATM
Dear Sir/Madam, Thank you all for giving me so much information! I have read some, and almost get a clear idea of how ATM manage the congestion control. But I still get one question: generally speaking, TCP/IP is equal to the transport and network layer in the OSI model, and it seems that the ATM works on the Data Link Layer (?). They serve different function in the OSI model. Through they all have congestion control facility, how to compare mechanism in different layer? Does the topic "Critically compare the congestion control on TCP/IP and ATM" mean only compare of the algorithms of them? Thank you again for you valuable help! rgds, Truly yours, Jianbo Huang :-)
Re: Critically compare the congestion control on TCP/IP and ATM?
Jianbo, See ftp://ftp.atmforum.com/pub/approved-specs/af-tm-0121.000.pdf, especially section 5. Regards, Andy --- At 10:57 PM 3/8/00 +0800, Jianbo Huang wrote: >Dear Sirs and Madams, > >A friend of mine are working on the paper on "critically compare the >congestion control on TCP/IP and ATM", and she ask me for help. But I do >not get much idea on the "congestion control on ATM". So, is there anyone >can give me any idea on this topic, while my friend and I processing on >this? Thank you! > >rgds, > >Sincerely yours, >Jianbo Huang >- >This message was passed through [EMAIL PROTECTED], which >is a sublist of [EMAIL PROTECTED] Not all messages are passed. >Decisions on what to pass are made solely by Harald Alvestrand. Andrew G. Malis [EMAIL PROTECTED] phone:978 952-7414 fax:978 392-2074 Lucent Technologies 1 Robbins RoadWestford, MA 01886
Critically compare the congestion control on TCP/IP and ATM?
Dear Sirs and Madams, A friend of mine are working on the paper on "critically compare the congestion control on TCP/IP and ATM", and she ask me for help. But I do not get much idea on the "congestion control on ATM". So, is there anyone can give me any idea on this topic, while my friend and I processing on this? Thank you! rgds, Sincerely yours, Jianbo Huang
