Re: [tcpm] [multipathtcp] Fwd: Probing the viability of TCP extensions

Hagen Paul Pfeifer <hagen@jauu.net> Wed, 30 June 2010 00:04 UTC

Return-Path: <hagen@jauu.net>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F67A3A6A51; Tue, 29 Jun 2010 17:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.212
X-Spam-Level:
X-Spam-Status: No, score=0.212 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_50=0.001, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPn3M03Vro4i; Tue, 29 Jun 2010 17:04:53 -0700 (PDT)
Received: from geheimer.internetendpunkt.de (alternativer.internetendpunkt.de [88.198.24.89]) by core3.amsl.com (Postfix) with ESMTP id DD9423A6A35; Tue, 29 Jun 2010 17:04:52 -0700 (PDT)
Received: by geheimer.internetendpunkt.de (Postfix, from userid 1000) id DD9D0F4413A; Wed, 30 Jun 2010 02:05:01 +0200 (CEST)
Date: Wed, 30 Jun 2010 02:04:59 +0200
From: Hagen Paul Pfeifer <hagen@jauu.net>
To: Patrick McManus <mcmanus@ducksong.com>
Message-ID: <20100630000459.GA3043@nuttenaction>
References: <3D3C75174CB95F42AD6BCC56E5555B4502BE0741@FIESEXC015.nsn-intra.net> <D12F4EB3-3081-4CE0-BE1A-CBF9A2E2FCC9@nokia.com> <5FDC413D5FA246468C200652D63E627A09227C84@LDCMVEXC1-PRD.hq.netapp.com> <1277739062.2166.6.camel@tng> <FC0290A4-358F-4486-91AD-6F7283442E73@cisco.com> <1277852679.2166.21.camel@tng>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1277852679.2166.21.camel@tng>
X-Key-Id: 98350C22
X-Key-Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22
X-GPG-Key: gpg --recv-keys --keyserver wwwkeys.eu.pgp.net 98350C22
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Multipath TCP Mailing List <multipathtcp@ietf.org>, tcpm@ietf.org, Hannes Tschofenig <hannes.tschofenig@nsn.com>, Fred Baker <fred@cisco.com>
Subject: Re: [tcpm] [multipathtcp] Fwd: Probing the viability of TCP extensions
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jun 2010 00:04:54 -0000

* Patrick McManus | 2010-06-29 19:04:39 [-0400]:

>> how many routers does it show that had ECN marking configured active?
>
>not a single ecn capable flow in the data contained a ecn-marked packet.
>This was general Internet traffic, including a lot of spam SMTP flows
>from abroad that you would think would have a reasonable chance of
>seeing congestion.
>
>I don't see how to identify which if any routers had ecn configured on,
>but the implication is that it is very few if any. (or that there is no
>congestion on "my" internet :)), right?

;-) was this insight surprising? ECN lacks one important attribute: it is not
good-natured if things goes wrong. What would you do if you had to configure a
core router: a) configure the router and setup standard RED/WRED where you
_know_ that if you are on fire and drop packets the sender will reduce their
sending rate or b) configure ECN and _hope_ that everything between you, the
receiver the last but not least the sender goes right?

Eventually you will think about the advantages of ECN and the reduced
TCP/DCCP/whatever retransmissions but is this more important then the former
paragraph? I don't think that this is the view of the guys at the core
routers.

ECN is a technical superior answer for a question questioned in a complex and
fragile environment.

HGN

PS: anyway, nice analysis! ;)


-- 
Hagen Paul Pfeifer <hagen@jauu.net>  ||  http://blog.jauu.net/
Telephone: +49 174 5455209           ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22