Subject: [PCN] Proposed changes to draft-eardley-pcn-marking-behaviour-01 (mainly about traffic conditioning)

From: <[email-masked]>
Date: Mon, 28 Jul 2008 15:53:03 +0100

Some of us met this morning to talk about PCN. We discussed the marking behaviours and encoding drafts. 

On the former [draft-eardley-pcn-marking-behaviour-01]:

- we would like this to become a WG document as soon as possible.

We mainly discussed changes to the traffic conditioning section. Basic proposal is to simplify this section. I wanted to quickly summarise what I think we agreed, in order to get feedback before the WG meeting on Thursday. 

First, the PCN-interior-node behaviour:

-          basic goal of PCN is to keep PCN-traffic within the PCN-threshold-rate on each link in the PCN-domain

-          If there's too much PCN-traffic on a link (eg due to a re-route after a failure), then either the flow termination mechanism kicks in, or else the queue will do its normal action when overloaded, typically tail drop. (The current draft talks about metering and dropping, but it's too much complexity to insist this is done on every link and indeed it should rarely be necessary, especially if the flow termination mechanism is in use.)

-          Using the same capacity for other traffic (ie sharing it with traffic at same or higher priority as PCN) - there should be a mechanism to limit this traffic but it doesn't need to be part of the PCN documents how this is done. 

-          Current draft talks about downgrading as a possible traffic conditioning action on PCN-interior-nodes. But we don't need to mention downgrading. Since overloaded PCN-traffic is tail dropped from queue, whilst non-PCN traffic is dealt with by some mechanism outside the scope of the draft.

-          for non-PCN-traffic, basically we just say "see other docs". Appendix could explain this a bit more, eg reference the Diffserv architecture and [draft-ietf-tsvwg-admitted-realtime-dscp]. Something analogous to S2.1 of the latter, eg could have EF & PCN in different queues & limit the scheduler rate, or in the same queue and police EF.

PCN-ingress-node traffic conditioning:

-          Discussion of PCN-ingress-node traffic conditioning would move to an Appendix. Ideally this text would move to a separate doc about the edge behaviour, signalling aspects etc, however such a document doesn't exist at the moment. So worth keeping the text in an appendix. 

-          The text about policing of PCN-traffic by ingress is a SHOULD. (Current doc has a MUST, this is felt to be too over-prescriptive. Policing has an implementation cost, and operator may want to handle this differently, eg policing per ingress-egress-aggregate at the ingress instead of per flow.) also, the third bullet needs to say dropping or downgrading flows (not packets).

-          The text about policing of non-PCN-traffic by the ingress can be deleted. This should just be a reference to the appropriate Diffserv documents.

Other changes to draft-eardley-pcn-marking-behaviour-01

-          the 'classify function' is re-named to 'behaviour aggregate classifier' (function done on all PCN-links). This is thought more consistent with diffserv terminology. Whereas 'classify' is more typically used to mean 5-tuple style classification that would only be done at the domain ingress.

-          Drop the bullet that "PCN-packets that are dropped SHOULD NOT be metered by the Excess traffic meter". Since the overloaded pkts are tail dropped, it's impractical for the excess traffic meter to know that they'll be dropped. (The issue that Michael found can still be mentioned in the Appendix.)

comments?

Thanks

phil

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

---

From: Michael Menth <[email-masked]>
Date: Mon, 28 Jul 2008 17:48:58 +0200

Hi Phil,

> - we would like this to become a WG document as soon as possible.
agree

> -          basic goal of PCN is to keep PCN-traffic within the PCN-threshold-rate on each link in the PCN-domain
I think you mean the reference rate for the threshold implementation of 
the exhaustive marker, right? Is it here relevant whether this is the 
admissible or supportable rate? I don't think so. My usual remark: the 
names for the thresholds can still be improved ...

> -          If there's too much PCN-traffic on a link (eg due to a re-route after a failure), then either the flow termination mechanism kicks in, or else the queue will do its normal action when ov…
agree

> -          Using the same capacity for other traffic (ie sharing it with traffic at same or higher priority as PCN) - there should be a mechanism to limit this traffic but it doesn't need to be par…
agree

> -          Current draft talks about downgrading as a possible traffic conditioning action on PCN-interior-nodes. But we don't need to mention downgrading. Since overloaded PCN-traffic is tail drop…
agree

> -          for non-PCN-traffic, basically we just say "see other docs". Appendix could explain this a bit more, eg reference the Diffserv architecture and [draft-ietf-tsvwg-admitted-realtime-dscp].…
agree

> -          Discussion of PCN-ingress-node traffic conditioning would move to an Appendix. Ideally this text would move to a separate doc about the edge behaviour, signalling aspects etc, however su…
Agree.

> -          The text about policing of PCN-traffic by ingress is a SHOULD. (Current doc has a MUST, this is felt to be too over-prescriptive. Policing has an implementation cost, and operator may wa…
ok

> -          The text about policing of non-PCN-traffic by the ingress can be deleted. This should just be a reference to the appropriate Diffserv documents.
agree

> -          the 'classify function' is re-named to 'behaviour aggregate classifier' (function done on all PCN-links). This is thought more consistent with diffserv terminology. Whereas 'classify' is…
agree

> -          Drop the bullet that "PCN-packets that are dropped SHOULD NOT be metered by the Excess traffic meter". Since the overloaded pkts are tail dropped, it's impractical for the excess traffic…
agree

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

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 10:09:11 +0100

Further to this just to let you all know that we are still trying to see if we can come to some agreement between the 3 main current encoding options: 
 
baseline encoding - 2 current suggestions:
     1)   Make one of the ECT codepoints experimental or local use
     2)   Specify rules for the two ECT codepoints such that you HAVE to mark all codepoints to the higher threshold but leave the behaviour for the lower thresold undefined (Note I am avoiding using ANY nomenclature here).
 
3 state encoding - allows limited end-to-end ECN. It also allows one to do egress-based measurement of admission marking rate to make admission decisions (simulatins seem to suggest this behaves better in many situations). However this uses a messy solution of 1 standards and one local use DSCP and requires changes between them. There is also some debate about which marking goes in which DSCP.
 
PSDM - uses a single DSCP which is a definite pro. However to be able to use both admission and termination marking, you need an external mechanism to correctly identify which marking a packet originally had. One suggestion that needs careful throught is that there may be a mechanism by which we can merge this encding with the baseline encoding, however there might then be interactions between this and the 3 state encoding...
 
My 30 min slot on Thursday will go into more detail about these and hopefully by then we will have a clear proposal for how to advance the encoding (and hopefully expedite it through to RFC in recrd time!)
 
Toby Moncaster

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Mon 28/07/2008 15:53
To: [email-masked]
Subject: [PCN] Proposed changes to draft-eardley-pcn-marking-behaviour-01(mainly about traffic conditioning)

comments?

Thanks

phil

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jul 2008 11:49:56 +0200

Hi Toby,

>      2)   Specify rules for the two ECT codepoints such that you HAVE to mark all codepoints to the higher threshold but leave the behaviour for the lower thresold undefined (Note I am avoiding usi…
I don't understand this.

>  
> 3 state encoding - allows limited end-to-end ECN. 
I do not see the value for practical application for the following reasons.
* Original ECN codepoints cannot preserved as PCN marks are added, thus 
"dominant" PCN+ECN codepoint are signalled.
* This dominant PCN+ECN signalling can be applied only if flows 
explicitly signal to the PCN domain that they want to receive these signals.
* It is not clear, how these signals are evaluated, in particular, 
because the semantics of the signals heavily depend on the type of PCN 
marking (excess or exhaustive marking, reference rate=admissible or 
supportable rate)
* The same behavior can be obtained for PSDM when PCN traffic is 
tunneled edge-to-edge with appropriate encaps/decaps mechanism (its the 
same type as required for tunneling within PCN domains).
* Preserving original ECN (without additional PCN marks) codepoints 
still require the application of an edge-to-edge tunnel that protects 
the inner header information.

> It also allows one to do egress-based measurement of admission marking rate to make admission decisions (simulatins seem to suggest this behaves better in many situations). However this uses a messy solution of 1 standards and one local use DSCP and requires changes between them. There is also some debate about which marking goes in which DSCP.
>   
I believe that don't understand this properly. Do you mean the fact that 
baseline encoding can be used for both excess and exhaustive marking? 
Yes, it's true that we need to tell routers what kind of marking is 
expected from them. With PSDM this is different as packets are marked at 
the ingress either with non-ExM or non-EhM. Then, routers know what kind 
of marking they have to apply.

> PSDM - uses a single DSCP which is a definite pro. However to be able to use both admission and termination marking, you need an external mechanism to correctly identify which marking a packet orig…
As I said above, 3 state encoding can be received by applying PSDM with 
appropriate edge-to-edge tunnels.

 From my perspective, the issue of delivering dominant ECN+PCN signals 
is irrelevant, in particular as the preservation of original ECN signals 
still requires tunnels and PSDM with appropriate tunnels can also 
deliver dominant ECN+PCN signals.

For me the question boils down to the following. Do we favor the benefits of
1) (baseline + 3 state encoding) = support for independent excess and 
exhaustive marking as required by CL
2) (PSDM) = support for excess marking and exhaustive marking for probe 
traffic within a single codepoint

I believe that any solution with 2 DSCPs will not become reality due to 
DSCP shortage. That was at least my impression from the discussion at 
the last meeting. Since the option baseline+ 3 state encoding requires 2 
DSCPs, I don't think it's realistic for further deployment. Hence, 
baseline + 3 state encoding is equivalent for me to baseline encoding. 
Baseline encoding supports only a single marking scheme which leaves us 
with the Single-Marking approach which is from my perspective not enough 
for smooth operation in many cases.

Regards,

    Michael

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 11:12:47 +0100

Only brief responses
 
Toby

From: Michael Menth [mailto:[email-masked]]
Sent: Tue 29/07/2008 10:49
To: Moncaster,T,Toby,CXR9 R
Cc: [email-masked]
Subject: Re: [PCN] Proposed changes to draft-eardley-pcn-marking-behaviour-01(mainly about traffic conditioning)

Hi Toby,

I don't understand this.

(Toby) See slides when I post them (once I have written them!)

(Toby) Perhaps this would be clearer if we expressed this as exposing the PCN marks to the end-point such that it can react to them. Then it is important to preserve /some/ form of signalling channel to negotiate this. This signalling channel would re-use ECN.

(Toby) NO,  I mean that, unless _all_  packets can be admission marked then CL-like schemes can't make an accurate admission decision based on an aggregate at the egress.

(Toby) NO, ECN can be preserved end-to-end. This is simply a by-product of 3-state encoding...

(Toby) yes this is what I see the question as. However I don't completely agree with your answers to the question. I think that using a local use DSCP is undesirable but I don't think it is necessarily a killer (except apparently to DT). What would be nice is to end up with a standards baseline that is sufficiently flexible to allow operators to do experiments on whether CL-type admission or PBAC is better, whether flow termination is useful, how best to do these functions, etc. In other words lets try to ensure we don't close the door to any future extension (especially lets not close the door to future re-chartering)

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jul 2008 16:59:50 +0200

Hi Toby,

> (Toby) Perhaps this would be clearer if we expressed this as exposing the PCN marks to the end-point such that it can react to them. Then it is important to preserve /some/ form of signalling chann…
I'll wait for your slides.

> (Toby) NO,  I mean that, unless _all_  packets can be admission marked then CL-like schemes can't make an accurate admission decision based on an aggregate at the egress.
That is correct. PSDM does not work for CL when AC and FT is required. 
It  just supports FT and probe-based AC.

> (Toby) NO, ECN can be preserved end-to-end. This is simply a by-product of 3-state encoding...
When IPSec tunnels are used for edge-to-edge transport of PCN traffic, 
the decapsulator adds marking to the inner header if packets are marked. 
The result is essentially what 3 state encoding does. Preserving ECN 
codepoint without tunneling does not work with 3 state encoding as the 
egress node does not know the original codepoints of excess or threshold 
marked packets. Do I miss something?

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jul 2008 18:44:44 +0200

Hi Toby,

while driving home I realized that the primary concern of 
3-state-encoding is to facilitate CL. This could be achieved in 
combination with PSDM as follows:

Use PSDM as base encoding if either only a single marking is required or 
if probing is sufficient.

A different 3-state-encoding could use only the CE field of an 
additional DSCP. If 3-state-encoding is required, then
Voice-Admit CE is interpreted as EhM and DSCP2 CE is interpreted as EcM. 
That means Voice-Admit (ECT(0),(1)) is exhaustive-marked to Voice-Admit 
CE and Voice-Admit (ECT(0),(1),CE) are excess-marked to DSCP2 CE.

What's missing is the ECN stuff which can be handled by tunneling solutions.

Regards,

    Michael

Michael Menth wrote:
>> (Toby) Perhaps this would be clearer if we expressed this as exposing 
>> the PCN marks to the end-point such that it can react to them. Then 
>> it is important to preserve /some/ form of signalling channel to 
>> negotiate this. This signalling channel would re-use ECN.
>>   
>>> It also allows one to do egress-based measurement of admission 
>>> marking rate to make admission decisions (simulatins seem to suggest 
>>> this behaves better in many situations). However this uses a messy 
>>> solution of 1 standards and one local use DSCP and requires changes 
>>> between them. There is also some debate about which marking goes in 
>>> which DSCP.
>>>  
>>>     
>> (Toby) NO,  I mean that, unless _all_  packets can be admission 
>> marked then CL-like schemes can't make an accurate admission decision 
>> based on an aggregate at the egress.
>>   
>>> PSDM - uses a single DSCP which is a definite pro. However to be 
>>> able to use both admission and termination marking, you need an 
>>> external mechanism to correctly identify which marking a packet 
>>> originally had. One suggestion that needs careful throught is that 
>>> there may be a mechanism by which we can merge this encding with the 
>>> baseline encoding, however there might then be interactions between 
>>> this and the 3 state encoding...
>>>  
>>>     
> the decapsulator adds marking to the inner header if packets are 
> marked. The result is essentially what 3 state encoding does. 
> Preserving ECN codepoint without tunneling does not work with 3 state 
> encoding as the egress node does not know the original codepoints of 
> excess or threshold marked packets. Do I miss something?
>
> Regards,
>
>    Michael
>