Re: [conex] Potentially interesting ConEx problem

"Scharf, Michael (Michael)" <> Wed, 06 March 2013 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5AE321F8263 for <>; Wed, 6 Mar 2013 11:46:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.319
X-Spam-Status: No, score=-7.319 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MHjwfXhEGkf5 for <>; Wed, 6 Mar 2013 11:46:25 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3148021F8235 for <>; Wed, 6 Mar 2013 11:46:25 -0800 (PST)
Received: from ( []) by (8.14.3/8.14.3/ICT) with ESMTP id r26JjM3t013624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 20:46:22 +0100
Received: from ([]) by ([]) with mapi; Wed, 6 Mar 2013 20:46:08 +0100
From: "Scharf, Michael (Michael)" <>
To: Mikael Abrahamsson <>, ConEx IETF list <>
Date: Wed, 06 Mar 2013 20:46:07 +0100
Thread-Topic: [conex] Potentially interesting ConEx problem
Thread-Index: Ac4aKma/D1i9fNTWSYqZZ0RmqnleZQAdiCZD
Message-ID: <>
References: <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
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 19:46:27 -0000


I do not understand how a congestion manager solves the problem raised here. Also, since you seem to be unhappy with TCPM,  please recall that at least I was interested in seeing empirical data for the timer problem you described (e. g., real OS traces). But that discussion would be better suited for the TCPM list, imho.

Actually, I do think that another recent TCPM discussion is closer related to this question: (But Matt is certainly aware of this already, and it doesn't solve the problem).

Another random idea that comes into my mind is the Quick-Start nonce mechanism. In Quick-Start one can ensure that certain actions can only be performed by downstream routers. Sure, this is not what is needed here, but maybe another interesting pointer?


Von: [] im Auftrag von Mikael Abrahamsson []
Gesendet: Mittwoch, 6. März 2013 06:20
An: ConEx IETF list
Betreff: Re: [conex] Potentially interesting ConEx problem

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:
conex mailing list