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 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
