IETF Logo Mail Archive

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

<l.wood@surrey.ac.uk> Wed, 06 March 2013 11:48 UTC

Return-Path: <l.wood@surrey.ac.uk>
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 CFD7D21F8534 for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 03:48:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.624
X-Spam-Level:
X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[AWL=0.974, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 2C7utcxEs0Sv for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 03:48:56 -0800 (PST)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id BCC6221F847B for <ietf@ietf.org>; Wed, 6 Mar 2013 03:48:55 -0800 (PST)
Received: from [193.109.255.147:18389] by server-6.bemta-14.messagelabs.com id C4/E9-31180-52D27315; Wed, 06 Mar 2013 11:48:53 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-9.tower-72.messagelabs.com!1362570533!3665589!1
X-Originating-IP: [131.227.200.39]
X-StarScan-Received:
X-StarScan-Version: 6.8.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 31048 invoked from network); 6 Mar 2013 11:48:53 -0000
Received: from unknown (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-9.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 6 Mar 2013 11:48:53 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.107]) by EXHT012P.surrey.ac.uk ([131.227.200.39]) with mapi; Wed, 6 Mar 2013 11:48:52 +0000
From: l.wood@surrey.ac.uk
To: mohta@necom830.hpcl.titech.ac.jp, ietf@ietf.org
Date: Wed, 06 Mar 2013 11:43:55 +0000
Subject: RE: congestion control? - (was Re: Appointment of a Transport Area Director)
Thread-Topic: congestion control? - (was Re: Appointment of a Transport Area Director)
Thread-Index: Ac4aXyy+MawIeEJQS8KlT9TJQ+Ok3QAALV67
Message-ID: <290E20B455C66743BE178C5C84F124081A49EEF288@EXMB01CMS.surrey.ac.uk>
References: <5134EFEB.2090104@isi.edu> <20130305004135.34CCA1A5F4@ld9781.wdf.sap.corp> <B31EEDDDB8ED7E4A93FDF12A4EECD30D2502A316@GLKXM0002V.GREENLNK.net> <CAD6AjGRt-0A42apmDwJQeRhUn6EM0qgrbrJuDipEESNz1+K9Gw@mail.gmail.com>, <51372A95.7050201@necom830.hpcl.titech.ac.jp>
In-Reply-To: <51372A95.7050201@necom830.hpcl.titech.ac.jp>
Accept-Language: en-US, en-GB
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 11:48:56 -0000

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-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Masataka Ohta [mohta@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

v2.23.0 | Report a Bug | By Email