Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
- Original Message - From: Cameron Byrne cb.li...@gmail.com To: Brian E Carpenter brian.e.carpen...@gmail.com Cc: bra...@isi.edu; IETF-Discussion ietf@ietf.org; Dearlove, Christopher (UK) chris.dearl...@baesystems.com; t.p. daedu...@btconnect.com Sent: Wednesday, March 06, 2013 4:12 PM On Mar 6, 2013 1:03 AM, Brian E Carpenter 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. 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 AreaDirector)
- Original Message - From: Cameron Byrne cb.li...@gmail.com To: Dearlove, Christopher (UK) chris.dearl...@baesystems.com Cc: bra...@isi.edu; ietf@ietf.org Sent: Tuesday, March 05, 2013 8:01 PM On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: I've no idea about the example quoted, but I can see some of their motivation. snip 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. tp 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 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 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)
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)
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 AreaDirector)
On Mar 6, 2013 1:03 AM, Brian E Carpenter 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)
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 brian.e.carpen...@gmail.commailto: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)
From: t.p. daedu...@btconnect.com 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 cb.li...@gmail.com 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)
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 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 Area Director)
On Tue, Mar 05, 2013 at 07:52:56AM +, Eggert, Lars wrote: On Mar 4, 2013, at 19:44, Michael Richardson mcr+i...@sandelman.ca 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)
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)
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)
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)
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)
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: quote 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 /quote 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 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: quote 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 /quote 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
Re: congestion control? - (was Re: Appointment of a Transport Area Director)
On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com 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 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)
rgensen == rgensen Roger 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 mcr+i...@sandelman.ca, Sandelman Software Works pgp_x2V_NHXrF.pgp Description: PGP signature
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)
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 Mar 4, 2013, at 19:44, Michael Richardson mcr+i...@sandelman.ca 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
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 www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464
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
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
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
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 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
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
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
--- 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 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
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
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
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
"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
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 www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464
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
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
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
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 www.brandenburg.com Tel: +1.408.246.8253, Fax: +1.408.273.6464
