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 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
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 l...@netapp.com wrote: On Mar 3, 2013, at 13:37, Eric Burger ebur...@standardstrack.com 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: 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
