Re: [PCN] 5.5. Probing functions

Lars Eggert <lars.eggert@nokia.com> Mon, 05 November 2007 08:58 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 1Ioxmb-0002uI-DY; Mon, 05 Nov 2007 03:58:09 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IoxmZ-0002rk-Jn for pcn-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 03:58:07 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoxmU-0002mB-KP for pcn@ietf.org; Mon, 05 Nov 2007 03:58:02 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoxmT-00083d-Qu for pcn@ietf.org; Mon, 05 Nov 2007 03:58:02 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA58vO0Y021761; Mon, 5 Nov 2007 10:57:41 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:57:33 +0200
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:57:34 +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); Mon, 5 Nov 2007 10:57:33 +0200
Received: from [172.21.37.232] (esdhcp037232.research.nokia.com [172.21.37.232]) by mgw-int01.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA58vUum018131; Mon, 5 Nov 2007 10:57:30 +0200
In-Reply-To: <001a01c81c99$b4735350$4c0d5982@dynamic.ewi.utwente.nl>
References: <EB12498F-82EC-4630-9AED-392B23517ABC@nokia.com> <000f01c81c84$5635b400$4c0d5982@dynamic.ewi.utwente.nl> <2723F111-5919-49CB-AC22-4A5A795F4852@nokia.com> <001a01c81c99$b4735350$4c0d5982@dynamic.ewi.utwente.nl>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <98501B20-1260-4EE0-87F1-DCCA0770230D@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Subject: Re: [PCN] 5.5. Probing functions
Date: Mon, 05 Nov 2007 10:57:27 +0200
To: ext Georgios Karagiannis <karagian@cs.utwente.nl>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 05 Nov 2007 08:57:33.0240 (UTC) FILETIME=[E758DB80:01C81F89]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
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="===============0609919827=="
Errors-To: pcn-bounces@ietf.org

Hi,

On 2007-11-1, at 17:12, ext Georgios Karagiannis wrote:
>> From: Lars Eggert [mailto:lars.eggert@nokia.com]
>>
>> 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.
>
> Georgios: The PCN_ingress_node sends a probe packet and it waits
> for a response from the PCN_egress_node.
> If a PCN_interior_node is congested (is in admission control state),
> then the probe will be marked, either using the PCN_marking or an  
> additional
> encoding, say PCN_Affected_marking.

ah - so this depends on the fact that a congested router uses a  
marking scheme that always tags the packet with _something_.

In other words, this wouldn't work with Anna's single-bit marking  
scheme, right? (Because that does not mark all packets passing a  
congested router.)

> If the probe packet is dropped on the way, then the  
> PCN_ingress_node has to
> know this such that the probe packet is retransmitted. This can be  
> done by using
> retransmission timers at the PCN_ingress_node.

That adds delay, obviously. You also need to defined some  
retransmission scheme that is safe without knowing the path RTT.

>>>> (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?
>
> Georgios: No! Marking proportionally is still needed, since it is also
> needed to encode the flow termination state of the PCN_interior nodes.
> However, all packets that are passing through the congested node  
> and are not
> PCN_marked they will have to be remarked with this additional  
> encoding, denoted as
> PCN_Affected_marking.

Thanks - I think I've understood this now. See above for my comments  
about single-bit marking - this wouldn't work with single-bit  
marking, would it?

>> This eliminates some of the marking options that
>> have been discussed.
>
> Georgios: No, please see above!

I still believe this does eliminate single-bit marking.

>>>> 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).

So what happens to the flow during the RTT needed for probing?  
Packets are dropped? That would seem to significantly affect various  
apps.

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