Re: [PCN] Re: 5.5. Probing functions

Michael Menth <> Tue, 06 November 2007 08:37 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IpJvn-0005NG-Ih; Tue, 06 Nov 2007 03:37:07 -0500
Received: from pcn by with local (Exim 4.43) id 1IpJvm-0005IU-2T for; Tue, 06 Nov 2007 03:37:06 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IpJvl-0005Hp-OE for; Tue, 06 Nov 2007 03:37:05 -0500
Received: from ([] by with esmtp (Exim 4.43) id 1IpJvh-0003P7-Q7 for; Tue, 06 Nov 2007 03:37:05 -0500
Received: from virusscan.mail (localhost []) by mailrelay.mail (Postfix) with ESMTP id F3297C02A; Tue, 6 Nov 2007 09:36:58 +0100 (CET)
Received: from localhost (localhost []) by virusscan.mail (Postfix) with ESMTP id E532BC0B9; Tue, 6 Nov 2007 09:36:58 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 9818CC02A; Tue, 6 Nov 2007 09:36:56 +0100 (CET)
Received: from ( []) by (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id lA68auh10325; Tue, 6 Nov 2007 09:36:56 +0100
Received: from [] ( []) by (Postfix) with ESMTP id B2D516F591; Tue, 6 Nov 2007 09:29:28 +0100 (CET)
Message-ID: <>
Date: Tue, 06 Nov 2007 09:29:00 +0100
From: Michael Menth <>
Organization: University of Wuerzburg
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
To: Lars Eggert <>
Subject: Re: [PCN] Re: 5.5. Probing functions
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Hi Lars and Phil,

I think that one major motivation for probing is to make PCN capable to 
deal with multipath routing like ECMP. Some path are empty, others are 
full. Some flows must be rejected, others can proceed although they all 
belong to the same ingress-egress-aggregate.



Lars Eggert wrote:
> Hi,
> On 2007-11-5, at 21:30, ext wrote:
>> My impression is that probing advocates have 2 reasons:
> thanks for summarizing this! I think this does capture the main points 
> made.
>> - the on-going ingress-egress-aggregate measurement of marked pkts
>> doesn't work. Because there's often no traffic on this
>> ingress-egress-aggregate, or no traffic on the ECMP path; AND simply
>> admitting the flow has a significant risk of leading to overload [pkts
>> dropped &/or flows terminated]
>> - there's no signalling state on the PCN-boundary-nodes for this
>> ingress-egress-aggregate (and no traffic already on it); AND the router
>> behaviour is such that every pkt is marked if the flow should be
>> blocked; AND just admitting the call is dangerous because there's a good
>> chance of overload in some parts of the nw (near the edge where the
>> capacity is low). Hence probing creates no extra delay (since you have
>> to send a signalling set-up msg anyway). Often this scenario is people
>> who envisage PCN going to end terminals or at least further out than
>> core nw [I think].
> Although I agree that we can construct scenarios where "simply 
> admitting the flow has a significant risk of leading to overload", I 
> still remain unclear on how likely such cases are in whatever we 
> envision the most likely deployment scenarios to be. Basically, I 
> worry that we're making the architecture complex for what will provide 
> little real benefit in the end.
> Also, don't forget that using probing will mean dropping the packets 
> of the flow waiting for admission for an RTT *every time* probing is 
> used. Whereas "just admitting" may only cause overload sometimes. 
> There is a tradeoff here - I believe it's possible to construct a case 
> where probing hurts more than "just admitting."
> And I'm still waiting for someone to convince me that dropping the 
> initial packets of a flow at the ingress during the probing RTT will 
> result in something that is acceptable for apps.
>> The first scenario will only happen in narrow conditions [flash crowds,
>> many ingress-egress-aggregates without any traffic]. An alternative way
>> of handling this is to limit the rate at which admit new flows [at least
>> this makes the conditions when the problem occurs even narrower].
> And we should try to determine how narrow these conditions are. If 
> they're very narrow, we may be able to avoid them through 
> configuration suggestions (sufficient overprovisioning, sufficiently 
> broad marking regions, etc.)
>>  The second scenario seems to break the (link) aggregation assumption?
>> presumably it could be solved by running different mechanism at the edge
>> compared with at the core. [joe, sorry if you've already explained, the
>> late hour => even poorer memory than usual.]
> Yes, we seem to be running into the "the number of flows across any 
> potential aggregation bottleneck is sufficiently large for stateless, 
> statistical mechanisms to be effective" restriction from the charter 
> here. These scenarios seems to require a deterministic mechanism, 
> while PCN is supposed to provide a probabilistic one.
> Lars
> ------------------------------------------------------------------------
> _______________________________________________
> PCN mailing list

Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632

PCN mailing list