Subject: [PCN] Fwd: How necessary is affected marking?

From: Bob Briscoe <[email-masked]>
Date: Mon, 10 Mar 2008 13:44:47 +0000

Georgios,

[Following up my own post (please ignore the original), since talking 
to you just now has simplified this to one outstanding question:]

>Have you tried to quantify how likely it will be that AfM will be useful?

A 'good enough' alternative to AfM would be to use AM as a reasonably 
good approximator for AfM. The egress would only terminate flows 
marked TM and it would calculate how much to terminate from the 
proportion of TM to AM.

This 'good enough' approach would never terminate flows not passing 
through a termination marking router. But, if other path(s) were 
coincidentally admission marking but not termination marking, 
termination on the first path would be slowed down but still 
completely terminate sufficient flows. I imagine termination would 
rarely be prolonged by more than a few percent.

There could be cases where termination would be prolonged by hundreds 
of percent, when many other paths were heavily admission marking but 
not termination marking at all. However, I think network operators 
should be given the probability that these cases will happen, so they 
can decide whether AfM is worth deploying.

Bob

>Date: Mon, 10 Mar 2008 12:18:54 +0000
>To: Georgios Karagiannis <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: How necessary is affected marking?
>Cc: "PCN IETF list" <[email-masked]>
>
>Georgios,
>
>Do you propose using Affected Marking (AfM) in ECMP cases to 
>calculate the Admission Marking level or just the Termination Marking level?

I understand now, that the same AfM can't be used for admission 
marking as for termination marking (because then AfM on paths with 
admission marking would be confusable with AfM from paths doing 
termination marking.

>If both, I can see it seems to help in ECMP cases {but see Note 1}.
>
>But if AfM is only used for Termination, the case for Affected 
>Marking (AfM) seems marginal. Because all packets that aren't 
>Termination Marked (TM) will typically be Admission Marked (AM), so 
>AM can serve the function of AfM.
>
>Of course, there may be one queue sending TM & AM to an egress and 
>another sending only AM. So AfM would help in such cases. But that's 
>a bit of a corner case to justify another codepoint. Without AfM, 
>this would slow down flow termination, but it would still terminate 
>the right amount of flows eventually.
>
>My question: Have you tried to quantify how likely it will be that 
>AfM will be useful?
>
>I'm just wondering whether it is worth complicating the core PCN 
>algorithm and encoding specs with AfM, or whether we should have a 
>separate spec just about AfM. Then the main PCN specs can refer to 
>AfM as an optional extra for any vendor who wants to do it.
>
>Cheers
>
>
>Bob
>
>---------
>{Note 1}: However, the admission marking behaviour we are likely to 
>standardise doesn't have a clear point where AM is on or off. It 
>gets gradually greater. The egress can decide when the fraction of 
>AM has passed a threshold for sufficient time (e.g. with an 
>exponentially weighted moving average EWMA). But that seems quite 
>complicated (but not impossible) for an interior node.
>
>I guess though that excess rate marking would also have to be able 
>to detect when it had been marking sufficiently for sufficiently 
>long to turn on AfM, and when to turn it off again. Have you 
>documented a possible algorithm for these state change triggers anywhere?
>
>
>____________________________________________________________________________
>Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

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