Subject: [PCN] PCN Admission control ECMP and probing

From: <[email-masked]>
Date: Tue, 24 Jul 2007 22:23:34 +0100

hi,

have been thinking about this. as far as adm ctrl is concerned, i think the following (copied from babiarz-3sm) applies to PCN in general and not just that draft:

As an alternative [to measuring markings on data pkts], probing may be used for admission control.  The PCN ingress node generates and sends probe packets to test and verify the pre-congestion level on the ingress-egress path.  The PCN egress intercepts these probe packets.  If ... [egress makes measurements of probe pkts], the requesting flows are not admitted (blocked).  Probing is useful or even essential under the following conditions:

o  when an ingress-egress aggregate carries no traffic,
o  in the presence of multipath routing, when some paths are already AR-overloaded, but others are not, and further flows should be admitted if they use a non-overloaded path.

< 

is something on these lines correct? (and therefore worth adding to the architecture draft). i think it's correct for all the alternative adm ctrl mechanisms that have been proposed.

in terms of work for the WG, what work does it imply?

(1) the WG must define a normal (non-probing) adm ctrl mechanism - based on making measurements of pkts arriving at an PCN-egress-node from a particular PCN-ingress-node (ie make measurements for the ingress-egress-aggregate that the new flow would use). 

(2) the WG may define a probing-based adm ctrl mechanism. By "may" I mean:

- we could decide to concentrate on (1), and think about probing later

- we could decide to think about probing for the first reason given in the quote above. 

- we could decide to think about probing for the second reason given in the quote above 

The second choice would involve work:

- BCP advice for number/rate of probe pkts to send 

- how to address them (eg address probe pkts to PCN-egress-node)

- a mechanism for the PCN-egress-node to recognise this as a probe pkt (presumably if probe pkts are addressed to the PCN-egress-node, this is just an ID number)

The third choice would involve work:

- BCP advice for number/rate of probe pkts to send 

- probe pkts would just be addressed to the new flow's destination

- mechanism for PCN-egress-node to detect a pkt is a probe pkt (partly so it can make measurements to determine whether to admit the new flow, partly so it doesn't forward the probe pkt on outside the PCN-domain)

- this could be instead of, or in addition to, the 'second choice'. if it's 'in addition to', then there would have to be a way of deciding which was the appropriate one to use.

As to the need for probing, I don't think we have had a discussion (evidence from deployment scenarios) whether the two reasons for probing are common or rare (and therefore how much we should worry about one or both of the reasons in the short term). Here's a starter scenario:

Imagine a core network with 100 PCN-boundary-nodes. Say there are 10 million end nodes. If we assume evenly distributed topology, then each ingress-egress-aggregate carries traffic from 1000 end nodes. However, the end nodes only send data [eg voip] some of the time - say 1% (15mins a day) on average. This might suggest that most ingress-egress-aggregates will have traffic on most of the time, so probing would rarely be required.

However in fact the distribution would typically be long-tailed (eg ingress-egress-aggregate between London and Manchester will always have lots of traffic, but there'll be other aggregates with not much traffic). Also if the network was a bit bigger (say 3 times as many PCN-boundary-nodes) then most ingress-egress-aggregates would need to do probing.

Comments?

phil

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Wed, 25 Jul 2007 11:40:47 +0200

Hi Phil,

see my comments inline!

> - we could decide to think about probing for the second reason given in the quote above 

I find it useful to identify various mechanisms and assessing them with 
respect to (a) their ability to address the different needs and (b) 
their complexity from an operational and (c) protocol point of view. I 
would not favor seeking and exploring only a single solution which is 
able to cover a minimum functionality when a more powerful solution is 
hardly more complex. Having an overview of several possibilities and 
their pros and cons makes a good decision easier. Probably different PCN 
approaches (single/dual marking, measurement/token bucket based marking, 
ECMP-capable/-non-capable...) require different / adapted probing 
methods. In turn, the simplicity and capabilities of the probing 
mechanisms can provide another aspect for the assessment of the 
different PCN approaches.

> - BCP advice for number/rate of probe pkts to send 

This heavily depends on the marking mechanism. If the marking provides a 
"strong" signal, i.e., all packets are marked when the admissible rate 
is exceeded, one or a few packets suffice for probing. If the marking 
provides a "weak" signal, i.e., the marker starts marking proportionally 
to the observed rate when the admissible rate is exceeded, many probe 
packets are required since only a fraction of PCN packets is marked.

> - this could be instead of, or in addition to, the 'second choice'. if it's 'in addition to', then there would have to be a way of deciding which was the appropriate one to use.

Phil, your analysis nicely shows that the challenge about probing is to 
design it in such a way that it works with ECMP, i.e., that probe 
packets take the same path as future data packets of the requesting 
flow. In that case the IP header of the probe packets requires the 
source and destination address of the requesting flow and probe packets 
need to be intercepted at the PCN egress since the PCN egress is not the 
destination of the probe packets. This is a challenge from an encoding 
point of view and needs some analysis how it can be achieved in an 
elegant way such that no header fields are changed that are used for 
hash-based ECMP load balancing.

Summarizing, I think ECMP-compatible probing is easy from an operational 
point of view, but it is not trivial from an encoding and protocol point 
of view. But that's the challenge and I am sure that solutions can be found.

> However in fact the distribution would typically be long-tailed (eg ingress-egress-aggregate between London and Manchester will always have lots of traffic, but there'll be other aggregates with no…

Phil, I think your example shows very well that a probing mechanism is 
something good to have although it is not always in use. In fact, we 
want to do as much as possible without probing, but it is good to have 
such a mechanism for cases where it is needed.

Regards,

    Michael

-- 
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:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn