Re: [PCN] 5.5. Probing functions

Lars Eggert <lars.eggert@nokia.com> Thu, 01 November 2007 13:10 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZow-0005o1-9n; Thu, 01 Nov 2007 09:10:50 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1InZov-0005n0-28 for pcn-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 09:10:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZou-0005mQ-N5 for pcn@ietf.org; Thu, 01 Nov 2007 09:10:48 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InZot-0000vr-5A for pcn@ietf.org; Thu, 01 Nov 2007 09:10:48 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1DAOZP022469; Thu, 1 Nov 2007 15:10:43 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 15:10:26 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 15:10:25 +0200
Received: from mgw-int01.ntc.nokia.com ([172.21.143.96]) by esebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 15:10:24 +0200
Received: from [172.21.34.231] (esdhcp034231.research.nokia.com [172.21.34.231]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1DAMvG027633; Thu, 1 Nov 2007 15:10:23 +0200
In-Reply-To: <000f01c81c84$5635b400$4c0d5982@dynamic.ewi.utwente.nl>
References: <EB12498F-82EC-4630-9AED-392B23517ABC@nokia.com> <000f01c81c84$5635b400$4c0d5982@dynamic.ewi.utwente.nl>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <2723F111-5919-49CB-AC22-4A5A795F4852@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [PCN] 5.5. Probing functions
Date: Thu, 01 Nov 2007 15:10:21 +0200
To: ext Georgios Karagiannis <karagian@cs.utwente.nl>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 01 Nov 2007 13:10:24.0557 (UTC) FILETIME=[90811DD0:01C81C88]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: 'pcn' <pcn@ietf.org>
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0851146161=="
Errors-To: pcn-bounces@ietf.org

Hi,

On 2007-11-1, at 14:39, ext Georgios Karagiannis wrote:
>> (1) The ingress needs to generate traffic in a pattern and at
>> a rate that lets it draw conclusions about whether it is OK
>> to admit the flow that is waiting for admission. How does it
>> know what characteristics the probe traffic should have and
>> how does it generate the probe traffic?
>
> Georgios: The PCN_ingress_node generates one probe packet for each new
> incoming flow that requests access from the PCN_domain.

how is a single packet probing the path? It's not obvious to me how  
one would derive bottleneck load based on a single packet, i.e.,  
based on one or zero markings.

>> (2) How long do you need to probe for before you declare it
>> safe to admit the new flow?
> Georgios: One probe packet per new incoming and flow is enough
> if the PCN_domain takes care that the probe packet will be marked  
> PCN_marked or using an other type of encoding, if it is passing  
> through a congested PCN_interior_node.

Ah - so this requires the marking scheme to mark all packets once the  
defined pre-congestion load level is reached, instead of marking  
proportionally with an increase in load, correct? This eliminates  
some of the marking options that have been discussed.

And you need to ensure that - after having gotten an indication of  
"not loaded" from the path - the single flow you're about to admit  
cannot by itself push the bottleneck straight into overload. This is,  
because the "not loaded" piece of information doesn't tell you how  
close to pre-congestion the bottleneck is, and if it can actually  
sustain the rate that the flow is going to send at.

You could do this through appropriate configuration, i.e., ensuring  
that the level at which you start marking is sufficiently below the  
overload state that you can sustain one new flow. Or two. Or three.  
How much is enough?

And if you did this through configuration, i.e., making sure that  
1,2,3,... flows can be admitted, what's the benefit of probing? Why  
not simply admit the flow?

>> What's the delay before a new
>> flow can be admitted, and can apps actually deal with this delay?
>
> The delay = one RTT (within PCN_domain).
>
>> (3) Since you're sending probe traffic at a rate that is
>> likely not insignificant, how do you prevent the probe
>> traffic itself from causing congestion and triggering
>> stop-admission or flow-termination actions? If you're
>> treating it differently (e.g., at a lower priority), how is
>> what the probe traffic experiences still representative of
>> what the real flow would experience? (How can you treat it
>> differently and still make ECMP work?)
>
> Georgios: By just sending one probe packet per new incoming flow that
> requests access into the PCN_domain.

Lars
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn