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

Cameron Byrne <cb.list6@gmail.com> Tue, 05 March 2013 20:01 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3351F0D10 for <ietf@ietfa.amsl.com>; Tue, 5 Mar 2013 12:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.634
X-Spam-Level:
X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, FRT_PRICE=3.897, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAOKMhTWHxQM for <ietf@ietfa.amsl.com>; Tue, 5 Mar 2013 12:01:40 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC271F0D13 for <ietf@ietf.org>; Tue, 5 Mar 2013 12:01:34 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr12so6210438wgb.23 for <ietf@ietf.org>; Tue, 05 Mar 2013 12:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=dQM+QWjKr9DE9Z8P7xFFJyfApMa+zBlSjmJEngeACTc=; b=vpxBv4eo2WzLU7YBUNkh9mIZbfU59jewEeqgoByniaNvj8F6YMBhszg0BkdurCY46Y s6lONyZjQnkvl/4IlYDz/awKzwKo92XvfHP8MxTIXUF3gB8yg9bPgYIiimVPvSwZnOhN IqsEVCV3BsfDBL6AcM1SLqGW90SA6/tg7rU8Mg51M6yTN97co1VOaB3Zu9RpijA5lJ54 ndW6UnR3Bg4B0JUFcmjSJCiZzLZFEpW2Yj/9KOrO7YxciA9a93rRH7CsuZ11XMcI2hoP qPljP/f15xmNioVR1glgKfybmHJ8+NLmVWscE6ge+/WzEe+pl25Nxw2HROiZ04FJ++Ar 3tww==
MIME-Version: 1.0
X-Received: by 10.180.80.73 with SMTP id p9mr18147338wix.22.1362513680410; Tue, 05 Mar 2013 12:01:20 -0800 (PST)
Received: by 10.194.20.35 with HTTP; Tue, 5 Mar 2013 12:01:20 -0800 (PST)
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30D2502A316@GLKXM0002V.GREENLNK.net>
References: <5134EFEB.2090104@isi.edu> <20130305004135.34CCA1A5F4@ld9781.wdf.sap.corp> <B31EEDDDB8ED7E4A93FDF12A4EECD30D2502A316@GLKXM0002V.GREENLNK.net>
Date: Tue, 05 Mar 2013 12:01:20 -0800
Message-ID: <CAD6AjGRt-0A42apmDwJQeRhUn6EM0qgrbrJuDipEESNz1+K9Gw@mail.gmail.com>
Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director)
From: Cameron Byrne <cb.list6@gmail.com>
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "braden@isi.edu" <braden@isi.edu>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2013 20:01:41 -0000

On Tue, Mar 5, 2013 at 3:55 AM, Dearlove, Christopher (UK)
<Chris.Dearlove@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.dearlove@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-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Martin Rex
> Sent: 05 March 2013 00:42
> To: braden@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.
> ********************************************************************
>