[PCN] Architecture draft

Hi,

There was quite a discussion about the probing section of the
Architecture draft recently, draft-ietf-pcn-architecture-00. This showed
to me that it needed a re-write, which I've attempted. 

One thing that struck me reading the discussion was that there really
seem to be 2 uses of probing. The current draft tries to talk about them
as though they're two aspects of the same thing; in the text below I've
tried instead to talk about them separately - because I think they're
really quite different.

The first uses probing to test the ingress-egress-aggregate, the second
uses probing is to test a particular ECMP path.

The first uses probe pkts addressed to the PCN-egress-node, the second
uses probe pkts addressed to the destination end node [so they follow
the same ECMp path as the data pkts would do]

The first has no problem stopping probe pkts leaking out of the
PCN-domain [because they're addressed to the PCN-egress-node] whilst the
second has to think carefully about this [how the PCN-egress-node can
easily identify pkts, but the ECMP algos are unaffected by the "flag =
probe pkt"]

The first would probably be used by people who envisage probing rarely
being used (most ingress-egress-aggregates always have traffic), the
second is probably favoured by people who would actually probe on every
call admission attempt [esp people who have it in mind to have PCN
operating in parts of network with lower capacity links ie the multiple
flows (aggregation) assumption doesn't hold]. (There are plenty of other
scenarios which I'm not commenting on!)

The first has a less clear benefit to me (it doesn't seem that much
better than the easy alternative - just admit the 'first' flow into an
'empty' ingress-egress-aggregate, and take the chance it causes flows to
be terminated or pkts to be dropped). The second has a clearer benefit
to me, in some scenarios (you test the actual ECMP path the flow would
take.) 

The first probing approach (ie tests the ingress-egress-aggregate) seems
to me quite simple to define, but the second much harder [need to work
out how to stop probes leaking out of PCN-domain and how to flag a probe
to minimise interactions with ECMP]. 

Personally I think that in the short term (say until Christmas) our
objective is to start converging on the router's PCN-marking behaviour
(algorithm & encoding) - so it isn't necessary to talk about the details
of probing at the moment. However, as part of the algorithm discussion
it is relevant to note (as Michael has already pointed out) that
excess-rate-marking algorithm is less suitable than a threshold-marking
algo from a probing perspective (at least you have to send a lot more
probe pkts to get an accurate picture of the pre-congestion level). (of
course it's only one factor when we choose the algo.)

Anyway, here's the proposed revised sub-section 5.5 about probing -
please comment /shout if you don't like it:-

****

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

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 the
PCN-node's ECMP algorithm. 

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.

****

Incidentally, I have edited the draft to include all the comments
/discussion that there's been on the list since Vancouver. I'll add the
above probing section [unless there are cries of unhappiness]. I also
have some comments on paper from bob [will summarise to list where >
typos etc]. So will send revised version out next week or end of this
week.

Best wishes

phil

[PCN] Architecture draft - probing section & general updates.