[PCN] RE: 5.5. Probing functions

<philip.eardley@bt.com> Mon, 05 November 2007 19:30 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7ef-0005vF-0z; Mon, 05 Nov 2007 14:30:37 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ip7ee-0005uR-Cg for pcn-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 14:30:36 -0500
Received: from [] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7ee-0005uJ-1P for pcn@ietf.org; Mon, 05 Nov 2007 14:30:36 -0500
Received: from smtp1.smtp.bt.com ([]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip7ed-0000SG-5n for pcn@ietf.org; Mon, 05 Nov 2007 14:30:35 -0500
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 19:30:33 +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
Date: Mon, 05 Nov 2007 19:30:32 -0000
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B342DD@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <EB12498F-82EC-4630-9AED-392B23517ABC@nokia.com>
Thread-Topic: 5.5. Probing functions
Thread-Index: Acgce7uAIUGeKCASRrCiFdfKcQLMsQDYoCjA
From: philip.eardley@bt.com
To: lars.eggert@nokia.com, pcn@ietf.org
X-OriginalArrivalTime: 05 Nov 2007 19:30:33.0797 (UTC) FILETIME=[5585EF50:01C81FE2]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
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>
Errors-To: pcn-bounces@ietf.org

General conclusion is that next version of arch draft needs to include
more on the downsides of probing. Also seems to be a feeling that should
be out of initial scope [not sure if this needs saying in draft]

Follow-ups in-line

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> Sent: 01 November 2007 11:38
> To: pcn
> Cc: Eardley,PL,Philip,CXR9 R
> Subject: 5.5. Probing functions
> >    A probe packet is just a dummy data packet, generated by
> >    the PCN-ingress-node and addressed to the PCN-egress-node.  A
> >    downside of probing is that it adds delay to the admission
> >    process.  Also note that in the scenario described in the
> >    paragraph (where traffic levels on other ingress-egress-
> > aggregates is
> >    already very high), the probe packets may also 'tip the balance'.
> This discussion on the downsides of probing is too short. Let me list
> some issues:
> (1) The ingress needs to generate traffic in a pattern and at a rate
> that lets it draw conclusions about whether it is OK to admit the
> flow that is waiting for admission. How does it know what
> characteristics the probe traffic should have and how does it
> generate the probe traffic?
> (2) How long do you need to probe for before you declare it safe to
> admit the new flow? What's the delay before a new flow can be
> admitted, and can apps actually deal with this delay?
> (3) Since you're sending probe traffic at a rate that is likely not
> insignificant, how do you prevent the probe traffic itself from
> causing congestion and triggering stop-admission or flow-termination
> actions? If you're treating it differently (e.g., at a lower
> priority), how is what the probe traffic experiences still
> representative of what the real flow would experience? (How can you
> treat it differently and still make ECMP work?)
> Without at least some good ideas about what the answers to these
> questions will be I believe it is premature to declare that probing
> is an optional component of PCN.

I think these are fair points.
My impression is that probing advocates have 2 reasons:
- 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].

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

> >    However, the risk should be reduced because it should be
> > possible to
> >    send probe packets for a shorter time and at a lower rate than a
> >    typical data flow.
> This claim is related to (1) and (2) above. Is there any evidence
> that is it possible to "send probe packets for a shorter time and at
> a lower rate than a typical data flow"? I'm not aware of any research
> in this space.
> >    The situation is more complicated if there is multipath routing
> >    (ECMP) in the PCN-domain.  It is then possible for some paths to
> >    pre-congested whilst other paths within the same ingress-egress-
> >    aggregate aren't pre-congested.
> >
> >    One approach essentially ignores ECMP: as usual, admit or block
> > a new
> >    flow depending on the "measurements of PCN-traffic" on the
> >    egress-aggregate.  This is rather similar to the "optimistic"
> >    approach above.
> >
> >    An alternative ("pessimistic" or "proactive") approach is to
> >    the ECMP path.  The PCN-ingress-node generates and sends probe
> >    packets (dummy data) that follow the specific ECMP path that the
> > new
> >    flow would do, in order to test the pre-congestion level along
> >    An ECMP algorithm typically examines: the source and destination
> >    addresses and port numbers, the protocol ID and the DSCP.  Hence
> >    these fields must have the same values in the probe packets as
> >    future data packets would have.  On the other hand, the
> >    node needs to consume the probe packets to ensure that they don't
> >    travel beyond the PCN-domain (eg they might confuse the
> >    end node).  Hence somehow the PCN-egress-node has to be able to
> >    disambiguate a probe packet from a data packet, via the
> >    characteristic setting of particular bit(s) in the packet's
> > header or
> >    body - but these bit(s) mustn't be used by any
> >    ECMP algorithm.  This should be possible with a typical ECMP
> >    algorithm, but isn't in the general case.
> Some things in this paragraph aren't specific to ECMP, such as that
> the egress needs to consume the probe packets.

in the non-ecmp scenario the pcn-ingress-node is sending probes
addressed to the pcn-egress-node, so it's quite easy for the egress to
consume them!

PCN mailing list