IETF Logo Mail Archive

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

Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> Wed, 06 March 2013 11:38 UTC

Return-Path: <mohta@necom830.hpcl.titech.ac.jp>
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 499C821F87E4 for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 03:38:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 tr4+vMHz-zxJ for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 03:38:16 -0800 (PST)
Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by ietfa.amsl.com (Postfix) with SMTP id 8A52E21F87DF for <ietf@ietf.org>; Wed, 6 Mar 2013 03:38:15 -0800 (PST)
Received: (qmail 64510 invoked from network); 6 Mar 2013 11:36:26 -0000
Received: from necom830.hpcl.titech.ac.jp (HELO ?127.0.0.1?) (131.112.32.132) by necom830.hpcl.titech.ac.jp with SMTP; 6 Mar 2013 11:36:26 -0000
Message-ID: <51372A95.7050201@necom830.hpcl.titech.ac.jp>
Date: Wed, 06 Mar 2013 20:37:57 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director)
References: <5134EFEB.2090104@isi.edu> <20130305004135.34CCA1A5F4@ld9781.wdf.sap.corp> <B31EEDDDB8ED7E4A93FDF12A4EECD30D2502A316@GLKXM0002V.GREENLNK.net> <CAD6AjGRt-0A42apmDwJQeRhUn6EM0qgrbrJuDipEESNz1+K9Gw@mail.gmail.com>
In-Reply-To: <CAD6AjGRt-0A42apmDwJQeRhUn6EM0qgrbrJuDipEESNz1+K9Gw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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:38:17 -0000

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