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 12:49 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 1F48221F8765 for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 04:49:26 -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 RfUhVb8b-3IV for <ietf@ietfa.amsl.com>; Wed, 6 Mar 2013 04:49:25 -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 95CCC21F8750 for <ietf@ietf.org>; Wed, 6 Mar 2013 04:49:24 -0800 (PST)
Received: (qmail 65153 invoked from network); 6 Mar 2013 12:47:37 -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 12:47:37 -0000
Message-ID: <51373B3D.2000103@necom830.hpcl.titech.ac.jp>
Date: Wed, 06 Mar 2013 21:49:01 +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: l.wood@surrey.ac.uk
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>, <51372A95.7050201@necom830.hpcl.titech.ac.jp> <290E20B455C66743BE178C5C84F124081A49EEF288@EXMB01CMS.surrey.ac.uk>
In-Reply-To: <290E20B455C66743BE178C5C84F124081A49EEF288@EXMB01CMS.surrey.ac.uk>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: 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 12:49:26 -0000

l.wood@surrey.ac.uk wrote:

> 3GPP has to never drop a packet because it's doing zero-header
> compression.

"has to never"? Even though it must, when it goes down.

> Lose a bit, lose everything.

You totally deny FEC. Wow!!!

> 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.

It has nothing to do with congestion, not at all.

						Masataka Ohta

v2.23.0 | Report a Bug | By Email