Re: [PCN] 5.5. Probing functions

Lars Eggert <> Mon, 05 November 2007 08:58 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1Ioxmb-0002uI-DY; Mon, 05 Nov 2007 03:58:09 -0500
Received: from pcn by with local (Exim 4.43) id 1IoxmZ-0002rk-Jn for; Mon, 05 Nov 2007 03:58:07 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IoxmU-0002mB-KP for; Mon, 05 Nov 2007 03:58:02 -0500
Received: from ([] by with esmtp (Exim 4.43) id 1IoxmT-00083d-Qu for; Mon, 05 Nov 2007 03:58:02 -0500
Received: from ( []) by (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA58vO0Y021761; Mon, 5 Nov 2007 10:57:41 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:57:33 +0200
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:57:34 +0200
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:57:33 +0200
Received: from [] ( []) by (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$>
References: <> <000f01c81c84$5635b400$> <> <001a01c81c99$b4735350$>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <>
From: Lars Eggert <>
Subject: Re: [PCN] 5.5. Probing functions
Date: Mon, 05 Nov 2007 10:57:27 +0200
To: ext Georgios Karagiannis <>
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' <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0609919827=="


On 2007-11-1, at 17:12, ext Georgios Karagiannis wrote:
>> From: Lars Eggert []
>> 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  

PCN mailing list