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

Hagen Paul Pfeifer <> Wed, 30 June 2010 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F67A3A6A51; Tue, 29 Jun 2010 17:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.212
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BPn3M03Vro4i; Tue, 29 Jun 2010 17:04:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DD9423A6A35; Tue, 29 Jun 2010 17:04:52 -0700 (PDT)
Received: by (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 <>
To: Patrick McManus <>
Message-ID: <20100630000459.GA3043@nuttenaction>
References: <> <> <> <1277739062.2166.6.camel@tng> <> <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 98350C22
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Multipath TCP Mailing List <>,, Hannes Tschofenig <>, Fred Baker <>
Subject: Re: [tcpm] [multipathtcp] Fwd: Probing the viability of TCP extensions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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


PS: anyway, nice analysis! ;)

Hagen Paul Pfeifer <>  ||
Telephone: +49 174 5455209           ||  Key Id: 0x98350C22
Key Fingerprint: 490F 557B 6C48 6D7E 5706 2EA2 4A22 8D45 9835 0C22