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

t.p. <daedulus@btconnect.com> Wed, 06 March 2013 08:40 UTC

Return-Path: <daedulus@btconnect.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 C59ED21F867D for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 00:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_PRICE=3.897, RCVD_IN_DNSWL_MED=-4]
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 Y5REv0K7ajCU for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 00:40:06 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id C531E21F8633 for <ietf@ietf.org>; Wed, 6 Mar 2013 00:40:06 -0800 (PST)
Received: from mail154-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 6 Mar 2013 08:40:06 +0000
Received: from mail154-tx2 (localhost [127.0.0.1]) by mail154-tx2-R.bigfish.com (Postfix) with ESMTP id 03EC7800AC; Wed, 6 Mar 2013 08:40:06 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: PS-22(zzbb2dI98dI9371Ic89bh542I1432Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275bh8275dh2ba5I1954cbhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h)
Received: from mail154-tx2 (localhost.localdomain [127.0.0.1]) by mail154-tx2 (MessageSwitch) id 136255920450103_19838; Wed, 6 Mar 2013 08:40:04 +0000 (UTC)
Received: from TX2EHSMHS022.bigfish.com (unknown [10.9.14.245]) by mail154-tx2.bigfish.com (Postfix) with ESMTP id 0698610004B; Wed, 6 Mar 2013 08:40:04 +0000 (UTC)
Received: from AMSPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.181) by TX2EHSMHS022.bigfish.com (10.9.99.122) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 6 Mar 2013 08:39:58 +0000
Received: from pc6 (86.171.206.193) by pod51017.outlook.com (10.242.14.163) with Microsoft SMTP Server (TLS) id 14.16.263.1; Wed, 6 Mar 2013 08:39:54 +0000
Message-ID: <007e01ce1a45$a9766fa0$4001a8c0@gateway.2wire.net>
From: "t.p." <daedulus@btconnect.com>
To: Cameron Byrne <cb.list6@gmail.com>, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
References: <5134EFEB.2090104@isi.edu><20130305004135.34CCA1A5F4@ld9781.wdf.sap.corp><B31EEDDDB8ED7E4A93FDF12A4EECD30D2502A316@GLKXM0002V.GREENLNK.net> <CAD6AjGRt-0A42apmDwJQeRhUn6EM0qgrbrJuDipEESNz1+K9Gw@mail.gmail.com>
Subject: Re: congestion control? - (was Re: Appointment of a Transport AreaDirector)
Date: Wed, 06 Mar 2013 08:36:02 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.171.206.193]
X-FOPE-CRA-SourceIpAddress: 157.56.250.181
X-FOPE-CRA-DRYRUN: 1207119;1
X-FOPE-BFA-SENDER: daedulus@btconnect.com
X-FOPE-BFA-RECEIVER: braden@isi.edu
X-FOPE-BFA-RECEIVER: ietf@ietf.org
X-FOPE-BFA-RECEIVER: cb.list6@gmail.com
X-FOPE-BFA-RECEIVER: Chris.Dearlove@baesystems.com
Content-Transfer-Encoding: quoted-printable
X-OriginatorOrg: btconnect.com
Cc: braden@isi.edu, 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: Wed, 06 Mar 2013 08:40:08 -0000

----- Original Message -----
From: "Cameron Byrne" <cb.list6@gmail.com>
To: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Cc: <braden@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.Dearlove@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.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.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.
> ********************************************************************
>