[PCN] Re: 5.5. Probing functions

Lars Eggert <lars.eggert@nokia.com> Tue, 06 November 2007 08:19 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpJem-0001vN-Ur; Tue, 06 Nov 2007 03:19:32 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IpJel-0001tb-4F for pcn-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 03:19:31 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpJeg-0001lG-7S for pcn@ietf.org; Tue, 06 Nov 2007 03:19:26 -0500
Received: from smtp.nokia.com ([] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpJed-0002pt-Fo for pcn@ietf.org; Tue, 06 Nov 2007 03:19:26 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com []) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA68IwF9008956; Tue, 6 Nov 2007 10:19:20 +0200
Received: from esebh103.NOE.Nokia.com ([]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 10:19:17 +0200
Received: from mgw-int02.ntc.nokia.com ([]) by esebh103.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 10:19:16 +0200
Received: from [] (esdhcp0352.research.nokia.com []) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA68JFB3012836; Tue, 6 Nov 2007 10:19:15 +0200
In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B342DD@E03MVZ1-UKDY.domain1.systemhost.net>
References: <75A199C5D243C741BF3D3F1EBCEF9BA503B342DD@E03MVZ1-UKDY.domain1.systemhost.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <C94DEA37-8D78-4288-AF94-3A8EC68D91C2@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Date: Tue, 06 Nov 2007 10:19:11 +0200
To: "ext philip.eardley@bt.com" <philip.eardley@bt.com>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 06 Nov 2007 08:19:16.0681 (UTC) FILETIME=[B8E78390:01C8204D]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365
Cc: pcn@ietf.org
Subject: [PCN] Re: 5.5. Probing functions
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="===============1031015123=="
Errors-To: pcn-bounces@ietf.org


On 2007-11-5, at 21:30, ext philip.eardley@bt.com 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.

PCN mailing list