[PCN] 5.5. Probing functions

Hi,

I read through the section on probing in the architecture draft, and  
have some comments. Folks know that I'm not too thrilled with the  
idea of probing, so this should come as no surprise...

> 5.5.  Probing functions
>
>    Probing functions are optional, and can be used for admission
>    control.
>
>    PCN's admission control, as described so far, is essentially a
>    reactive mechanism where the PCN-egress-node monitors the pre-
>    congestion level for traffic from each PCN-ingress-node; if the  
> level
>    rises then it blocks new flows on that ingress-egress-aggregate.
>    However, it's possible that an ingress-egress-aggregate carries no
>    traffic, and so the PCN-egress-node can't make an admission  
> decision
>    using the usual method described earlier.
>
>    One approach is to be "optimistic" and simply admit the new flow.
>    However it's possible to envisage a scenario where the traffic  
> levels
>    on other ingress-egress-aggregates are already so high that they're
>    blocking new PCN-flows and admitting a new flow onto this 'empty'
>    ingress-egress-aggregate would add extra traffic onto the link  
> that's
>    already pre-congested - which may 'tip the balance' so that PCN's
>    flow termination mechanism is activated or some packets are  
> dropped.
>    This risk could be lessened by configuring on each link sufficient
>    'safety margin' above the PCN-lower-rate.
>
>    An alternative approach is to make PCN a more proactive mechanism.
>    The PCN-ingress-node explicitly determines, before admitting the
>    prospective new flow, whether the ingress-egress-aggregate can
>    support it.  This can be seen as a "pessimistic" approach, in
>    contrast to the "optimism" of the approach above.  It involves
>    probing: a PCN-ingress-node generates and sends probe packets in
>    order to test the pre-congestion level that the flow would
>    experience.

The above is a really good intro to the problem - nice job.

>    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 control
>    process.  Also note that in the scenario described in the previous
>    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.

>    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 be
>    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 ingress-
>    egress-aggregate.  This is rather similar to the "optimistic"
>    approach above.
>
>    An alternative ("pessimistic" or "proactive") approach is to probe
>    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 it.
>    An ECMP algorithm typically examines: the source and destination IP
>    addresses and port numbers, the protocol ID and the DSCP.  Hence
>    these fields must have the same values in the probe packets as the
>    future data packets would have.  On the other hand, the PCN-egress-
>    node needs to consume the probe packets to ensure that they don't
>    travel beyond the PCN-domain (eg they might confuse the destination
>    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 PCN-interior-node's
>    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.

>    The probing functions are:
>
>    o  Make decision that probing is needed.  As described above,  
> this is
>       when the ingress-egress-aggregate or the ECMP path carries no  
> PCN-
>       traffic.  An alternative is always to probe, ie probe before
>       admitting every PCN-flow.
>
>    o  (if required) Communicate the request that probing is needed  
> - the
>       PCN-egress-node signals to the PCN-ingress-node that probing is
>       needed
>
>    o  Generate probe traffic - the PCN-ingress-node generates the  
> probe
>       traffic.  The appropriate number (or rate) of probe packets will
>       depend on the PCN-marking algorithm; for example an excess-rate-
>       marking algorithm generates fewer PCN-marks than a threshold-
>       marking algorithm, and so will need more probe packets.
>
>    o  Forward probe packets - as far as PCN-interior-nodes are
>       concerned, probe packets must be handled the same as (ordinary
>       data) PCN-packets, in terms of routing, scheduling and PCN-
>       marking.
>
>    o  Consume probe packets - the PCN-egress-node consumes probe  
> packets
>       to ensure that they don't travel beyond the PCN-domain.

Nice summary of the required functions.

Lars

[PCN] 5.5. Probing functions

Attachment: smime.p7s