ietf
[Top] [All Lists]

Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)

2013-03-06 02:40:30
----- Original Message -----
From: "Cameron Byrne" <cb(_dot_)list6(_at_)gmail(_dot_)com>
To: "Dearlove, Christopher (UK)" 
<Chris(_dot_)Dearlove(_at_)baesystems(_dot_)com>
Cc: <braden(_at_)isi(_dot_)edu>; <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, March 05, 2013 8:01 PM
On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK)
<Chris(_dot_)Dearlove(_at_)baesystems(_dot_)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(_dot_)dearlove(_at_)baesystems(_dot_)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-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf
Of Martin Rex
Sent: 05 March 2013 00:42
To: braden(_at_)isi(_dot_)edu
Cc: ietf(_at_)ietf(_dot_)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.
********************************************************************




<Prev in Thread] Current Thread [Next in Thread>