Re: [conex] Potentially interesting ConEx problem

Mikael Abrahamsson <> Wed, 06 March 2013 05:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F1AC21F85DB for <>; Tue, 5 Mar 2013 21:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VBurPmPSL+C8 for <>; Tue, 5 Mar 2013 21:20:52 -0800 (PST)
Received: from ( [IPv6:2a00:801::f]) by (Postfix) with ESMTP id 5ED3B21F85D8 for <>; Tue, 5 Mar 2013 21:20:52 -0800 (PST)
Received: by (Postfix, from userid 501) id E954D9C; Wed, 6 Mar 2013 06:20:48 +0100 (CET)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E4FCB9A for <>; Wed, 6 Mar 2013 06:20:48 +0100 (CET)
Date: Wed, 06 Mar 2013 06:20:48 +0100
From: Mikael Abrahamsson <>
To: ConEx IETF list <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: Re: [conex] Potentially interesting ConEx problem
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Mar 2013 05:20:53 -0000

On Tue, 5 Mar 2013, Matt Mathis wrote:

> The question I was asking was can ConEx help the content provider know 
> which bottleneck prevails?  Bob?

I tried to get the TCP people look into this, but got shot down. They 
didn't feel TCP would work better by knowing more, or I guess they didn't 
want to handle th complexity.

My idea was that TCP would over time "find out" what the access looked 
like if it indeed was the only thing congesting, and even that the 
connection manager on the machine would inform TCP what the properties of 
the primary connection was (speed, buffering, retransmits, half/full 
duplex etc), and if something substantial (like the link going down or 
coming up, speed changed etc) happened, TCP would be informed of this.

They felt it was better to have TCP find out by itself instead of getting 
fed this information via some API.

Mikael Abrahamsson    email: