Re: [conex] Potentially interesting ConEx problem

Bob Briscoe <bob.briscoe@bt.com> Fri, 08 March 2013 00:06 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2CC21F86D3 for <conex@ietfa.amsl.com>; Thu, 7 Mar 2013 16:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcNg8dSHJchZ for <conex@ietfa.amsl.com>; Thu, 7 Mar 2013 16:06:30 -0800 (PST)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id E97D521F86D9 for <conex@ietf.org>; Thu, 7 Mar 2013 16:06:29 -0800 (PST)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.297.1; Fri, 8 Mar 2013 00:06:25 +0000
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 8 Mar 2013 00:06:23 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.342.3; Fri, 8 Mar 2013 00:06:23 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.109.160.193]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id r2806LFq021835; Fri, 8 Mar 2013 00:06:22 GMT
Message-ID: <201303080006.r2806LFq021835@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 8 Mar 2013 00:06:22 +0000
To: Matt Mathis <mattmathis@google.com>, Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <201303072219.18223.mirja.kuehlewind@ikr.uni-stuttgart.de>
References: <CAH56bmD5c3KjVxg3gf9utBTQDLQS3HnxjVbpYf1Bby=iOB85bQ@mail.gmail.com> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> <CAH56bmBKsVfo2-2gL6sKAYT18XSrq2N31YEViwp0ZxTSBbWYOQ@mail.gmail.com> <201303072219.18223.mirja.kuehlewind@ikr.uni-stuttgart.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: conex@ietf.org
Subject: Re: [conex] Potentially interesting ConEx problem
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2013 00:06:31 -0000

Matt,

At 21:19 07/03/2013, Mirja Kuehlewind wrote:
>Hi Matt,
>
> > The question I was asking was can ConEx help the content provider know
> > which bottleneck prevails?   Bob?

Sorry, seeing your repeated question, I had misinterpreted.

As Mirja says below, I can't see how ConEx could help the /content 
provider/ to know anything. The content provider sends the ConEx 
signal in the first place, so it surely cannot learn anything new 
from a signal it sends itself.

I think Mirja's on the right track for the content provider to infer 
the difference between shared and self-congestion. Fixed-line 
self-congestion should lead to a very regular total bandwidth across 
flows, and a regular loss pattern.

That isn't a panacea tho, because there might be tons of devices 
within a home sharing a fixed access link making all the flows to any 
single device see what looks like shared and variable congestion. Or 
the link might have a wireless tail that is shaking about all over 
the bandwidth range.

Does it matter? If there's a link failure so loads of people's 
traffic all gets squeezed into some remaining link, the content 
provider will see the congestion, and adjust down. The congestion 
level will be higher, so it should go slower. Sorted?

However, I don't understand the last part of your question (below). 
Why more brittle?

At 17:36 05/03/2013, Matt Mathis wrote:
>Traditional serving optimizations actually make this problem far
>worse: serving from as many places as possible, as close to the users
>as possible makes the system even more brittle to ISP failures.



Bob


>(sorry I'm not Bob but will give it a try anyway)
>
>I don't think ConEx can help here. I believe you assume a scenario where the
>content provider is in most cases the sender. With ConEx information will be
>re-insert form the sender into the network. Thus ECN or loss information thus
>will be sufficient at the sender.
>
>Anyway as I've been recently looking in loss measurement/estimations methods,
>I actually came over the same question. Here my current ideas:
>
>- The client/receiver might know its access bandwidth and could provide this
>information to the server (in a higher layer protocol) or send some
>measurement traffic to the server or a measurement server
>
>- distinguish self-congestion (only one flow on bottleneck link) form shared
>congestion by looking at the lost pattern, e.g. a flow using cubic or reno
>has a very regular loss burst with a defined number of losses in a defined
>period (I'm currently looking at this) if there is no cross traffic
>disturbing the flow
>
>- correlate the losses (or loss pattern) of multiple flows (from the same
>server to different clients) to see if losses occur at the same time/in the
>same period (see network tomography in literature)
>
>Does this help?
>
>Mirja
>
>_______________________________________________
>conex mailing list
>conex@ietf.org
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                                  BT