Re: [conex] Potentially interesting ConEx problem

Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> Thu, 07 March 2013 21:19 UTC

Return-Path: <mirja.kuehlewind@ikr.uni-stuttgart.de>
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 5F41421F859B for <conex@ietfa.amsl.com>; Thu, 7 Mar 2013 13:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 CazDmRVenPHU for <conex@ietfa.amsl.com>; Thu, 7 Mar 2013 13:19:34 -0800 (PST)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9221F857B for <conex@ietf.org>; Thu, 7 Mar 2013 13:19:20 -0800 (PST)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id DC1A960275; Thu, 7 Mar 2013 22:19:18 +0100 (CET)
Received: from vpn-2-cl113 (vpn-2-cl113 [10.41.21.113]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id CB1FB60274; Thu, 7 Mar 2013 22:19:18 +0100 (CET)
From: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
Organization: University of Stuttgart (Germany), IKR
To: conex@ietf.org
Date: Thu, 07 Mar 2013 22:19:18 +0100
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <CAH56bmD5c3KjVxg3gf9utBTQDLQS3HnxjVbpYf1Bby=iOB85bQ@mail.gmail.com> <354A9577-4AE9-4094-93B8-2778E9B6A80A@cisco.com> <CAH56bmBKsVfo2-2gL6sKAYT18XSrq2N31YEViwp0ZxTSBbWYOQ@mail.gmail.com>
In-Reply-To: <CAH56bmBKsVfo2-2gL6sKAYT18XSrq2N31YEViwp0ZxTSBbWYOQ@mail.gmail.com>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <201303072219.18223.mirja.kuehlewind@ikr.uni-stuttgart.de>
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: Thu, 07 Mar 2013 21:19:34 -0000

Hi Matt,

> The question I was asking was can ConEx help the content provider know
> which bottleneck prevails?   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