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

[Michael Menth <[e-mail]>]

Hi Phil,

I like your text as it reflects the current ideas about probing. It 
nicely identifies the benefits and also the difficulties (that we were 
always aware of!) of the two different types of probing. My view is to 
first solve the easy tasks and then see whether there is a solution to 
the more challenging objectives. It is good to have this section in the 
architecture draft that the benefits of probing do not get lost on the 
way to a first simple system.

Regards,

Michael


[e-mail] wrote:
>
> 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 mailing list
> [e-mail]
> 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: [phone], fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn



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