Re: [conex] Potentially interesting ConEx problem

Matt Mathis <> Wed, 06 March 2013 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 778C721F8734 for <>; Wed, 6 Mar 2013 10:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 483cVWrYxp13 for <>; Wed, 6 Mar 2013 10:13:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::232]) by (Postfix) with ESMTP id 0942A21F89AE for <>; Wed, 6 Mar 2013 10:13:23 -0800 (PST)
Received: by with SMTP id c13so10030237ieb.9 for <>; Wed, 06 Mar 2013 10:13:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pDyMVjLy50y/1p7uYl3ZS8TzWXW8F5lvN64nYk8o6Lw=; b=MN8XxwM4bYrg5dgbesvyftlEfPPBS8l25Ms1FnBqJ8eyqsJh0MMNex/BFGNyMJxOo2 6CYiikenE2RUt1c/eCtT/iUsBR4TE3r+WFTNKeppYCalOJihHLe29CcflePqrknkTIp9 cwB5KgvQZ79FaciwWtTGi2OB+/kdrFsuy9c0KVC3fpJFxXwuZ3ne9KuPshZTbcwjTHFN tzv6uQ2lqH+WFiOkBJr+X9RywpUW059eZ3mr7kP2tdphXEvxvmqE1zRoYjhJTaIiHkYZ zEhQAPEpTD58nJqYaGk6DpdnUVwz2PU5gtoqZleQuYDvG0bWibBxQJcNMDe+bu9RY4vW g/fg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=pDyMVjLy50y/1p7uYl3ZS8TzWXW8F5lvN64nYk8o6Lw=; b=hDoNmdfK4fWaG2DTzFSmDNSvyI2e6DeAuhWScK8EFMOiRZxwgj2Pe+b0ZH2lCnRQvQ dx3eDz4gzrH/ZueoqXnbEXbeGOhmDnR687MQR/OjsrtxJWzwI84We1g0aTmRL54phPnQ EG/AY+uYvZ/Sbzz2ovZbFIzcWX/l0+fTCiWaw5chruNxRjEfQZlIi+5M+53RSV73F5xW Cdrs0K3zDkI5f3o0KLnAl4tEypuK35DY32SRlSYugHWya7XZSj3Ng6AucDN459TKmf6v jYnH7rgBD3QXiwYnC9Rwy+x0+KU1jESr2T8Huqw8ha2Xcu4P3AndISfiJP3Jqmdh1GPA AcZQ==
MIME-Version: 1.0
X-Received: by with SMTP id l6mr3706000ics.54.1362593598731; Wed, 06 Mar 2013 10:13:18 -0800 (PST)
Received: by with HTTP; Wed, 6 Mar 2013 10:13:18 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Wed, 06 Mar 2013 10:13:18 -0800
Message-ID: <>
From: Matt Mathis <>
To: Mikael Abrahamsson <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQn/Ct+ws//K4fTNNlYI32B605aDkSY2o8v1lhmJl9dMELxIc38jhiv17xjnuA1p9sQ8G9L13DAZxJOLHXVdKVwOyJ372mImVQl9bJG3DaW+2roq6IQD85TK4ITBWU71HEzh2Ci741b+2KoJiswFGWIvVYr9w7r5R93nfOqXG/5ouoGXVI4c3Jwwr4lNiY3lPjHXwrTS
Cc: ConEx IETF list <>
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 18:13:31 -0000

So as an intermittent TCP person, I agree with them: this does not
belong at the TCP layer, but at some slightly higher serving services
layer, because it is has to be coupled to things like load balancers,
etc.  Per server state isn't useful.

Which is not the same as saying the idea isn't valuable, it is just
that TCP itself isn't quite the right place.

The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.

On Tue, Mar 5, 2013 at 9:20 PM, Mikael Abrahamsson <> wrote:
> 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