RE: [PCN] Re: 5.5. Probing functions

<philip.eardley@bt.com> Tue, 06 November 2007 09:13 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 1IpKUm-00080K-Lv; Tue, 06 Nov 2007 04:13:16 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1IpKUl-0007zo-Hm for pcn-confirm+ok@megatron.ietf.org; Tue, 06 Nov 2007 04:13:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpKUl-0007zg-8J for pcn@ietf.org; Tue, 06 Nov 2007 04:13:15 -0500
Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpKUg-0004Uc-2e for pcn@ietf.org; Tue, 06 Nov 2007 04:13:15 -0500
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:13:09 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PCN] Re: 5.5. Probing functions
Date: Tue, 06 Nov 2007 09:13:08 -0000
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B342E0@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <473025CC.7020408@informatik.uni-wuerzburg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Re: 5.5. Probing functions
Thread-Index: AcggUDKa4LUC41jsStq0PhNQgQOoOwABFx6A
From: philip.eardley@bt.com
To: menth@informatik.uni-wuerzburg.de, lars.eggert@nokia.com
X-OriginalArrivalTime: 06 Nov 2007 09:13:09.0619 (UTC) FILETIME=[3FE2B430:01C82055]
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Cc: 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>
Errors-To: pcn-bounces@ietf.org

Michael

Do you have an idea of how likely this is? will it be the case that for
a small increase in load all/most of the ECMP paths become full? Does it
depend strongly on topology? If each link is shared by mnay ecmp paths
from many different ingress-egress-aggregates is this less of a risk?

phil

> -----Original Message-----
> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
> Sent: 06 November 2007 08:29
> To: Lars Eggert
> Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org
> Subject: Re: [PCN] Re: 5.5. Probing functions
> 
> 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.
> 
> Regards,
> 
>     Michael
> 
> Lars Eggert wrote:
> > Hi,
> >
> > 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.
> >
> > Lars
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > PCN mailing list
> > PCN@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pcn
> >
> 
> --
> 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
> mailto:menth@informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn



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