Subject: [PCN] plan for PCN encodings, now ecn-tunnel is in last call

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Jun 2010 13:45:12 +0100

Joe, Daisuke, Toby, Michael, Kwok,

I writing to you all as co-authors of the various PCN encoding drafts 
and RFCs, and to Kwok as author of the encoding comparison draft.

I have started this conversation between you all rather than starting 
numerous side conversations between slightly different sets of 
co-authors. I have also included the PCN list as there are others 
with interest in the outcome (not least the chairs). I hope that's OK 
- otherwise please accept my apologies and feel free to switch to 
off-list mode.

The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10. 
Assuming it goes thru without substantive changes, I would like to 
suggest a plan for how to deal with all the experimental PCN 
encodings and then to try to update the drafts accordingly before the 
Maastricht deadline.

* draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds track
* RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2}
* draft-ietf-pcn-3-state-encoding -> expt track or expire{3}
* draft-ietf-pcn-psdm-encoding -> leave to expire?
* draft-satoh-pcn-st-marking -> (expired) -> leave to expire?

{Note 1}: I propose we edit 3-in-1 to make it clear that you don't 
have to use both severity levels just because you can. So it's OK to 
use 3-in-1 for single marking, you just don't use the extra codepoint.

{Note 2}: To anyone not paying close attention to the PCN w-g, they 
will be (and are) confused by multiple encodings. I think it would be 
best to re-write 3-in-1 a little so it can obsolete the baseline, 
rather than keeping both on the stds track.

{Note 3}: 3-state is the only encoding that explicitly supports e2e 
ECN, but e2e ECN can be supported with tunnelling across the PCN 
domain instead. IMO tunnelling across the domain is more likely to be 
used if e2e ECN is needed, so I would let 3-state expire. Then, in 
3-in-1 we should explicitly say that PCN domain tunnelling MUST be 
used when incoming packets are alread ECT.

Questions:
Q1. Do any co-authors of psdm/st think either could still be useful 
even if ecn-tunnel becomes a proposed standard?
Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by 
tunnelling, rather than 3-state encoding?
Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear 
you don't have to use both severity levels (i.e. single marking with 
3-in-1 is OK)?
Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 replacing it?
Q5. Have I missed anything?

Background on ecn-tunnel:
------------------------
<draft-ietf-tsvwg-ecn-tunnel> finally got to IETF last call on 22-Jun-10.
<https://datatracker.ietf.org/feed/comments/draft-ietf-tsvwg-ecn-tunnel/>

It previously received a favourable SecDir review:
<http://www.ietf.org/mail-archive/web/tsvwg/current/msg09994.html>

We created various experimental PCN encodings as work-rounds to ECN 
tunnelling not propagating congestion markings how we wished:
- RFC3168 ingress breaks excess-rate marking and single marking;
- all egress tunnels break two severity-level marking.
Altho we cannot expect all tunnels in the Internet to immediately 
become compliant with this new spec (!), an operator wanting to 
deploy PCN can ask tunnel vendors to comply with it.

It's at -08, but I have prepared an -09b draft to capture the queued 
up minor changes since -08, and removal of the comments, notes and 
appendices marked for removal before publication:
<http://www.bobbriscoe.net/projects/ipe2eqos/pcn/papers/draft-ietf-tsvwg-ecn-tunnel-09b.txt>
For diffs from -08, either see the list within the doc, or the diffs here:
<http://www.bobbriscoe.net/projects/ipe2eqos/pcn/papers/draft-ietf-tsvwg-ecn-tunnel-09b-08.html>

Bob

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 25 Jun 2010 14:15:30 +0100

Initial comment is this seems to run counter to the PCN W-G decision that we
should actually experiment on the different experimental encodings to see
which was best... But as long as the W-G agrees to the new approach that
won't matter

Some quick answers inline.... 

> -----Original Message-----
> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 25 June 2010 13:45
> To: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; Michael Menth;
> CHAN, Kwok Ho
> Cc: PCN IETF list
> Subject: plan for PCN encodings, now ecn-tunnel is in last call
> 

I can see the argument for STDs track, however there are some issues and it
will be tough getting it through, especially if it becomes the only STDs
track encoding. I think we need to take a straw poll to find out what the
general view is on this

> * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2}

If we obsolete this, we need to add in some extra details from there into
3-in-1

> * draft-ietf-pcn-3-state-encoding -> expt track or expire{3}

Experiment as it allows lots of extra functionality in its extended form.
However if 3-in-1 is going to be the new STD then we need to make sure it
allows for this sort of encoding...

> * draft-ietf-pcn-psdm-encoding -> leave to expire?

No strong views - it does fit nicely with the RSVP model for signalling...

> * draft-satoh-pcn-st-marking -> (expired) -> leave to expire?

Expire as I am still not convinced by it...

> use 3-in-1 for single marking, you just don't use the extra codepoint.

if it is obsoleting baseline then it also needs to include all the extra
stuff that is in there...

> rather than keeping both on the stds track.

Not keen on this. I would prefer to make 3-in-1 a STDs track extension to
RFC5696. I can see the current state of affairs (with 4 possible extension
encodings all competing) is confusing but having a baseline encoding and an
extended encoding doesn't seem at all confusing to me...

> used when incoming packets are alread ECT.

3-state gives the potential for a much richer encoding, not just tunnelling
of ECN. Also there is the point that this is designed to allow the PCN
domain to signal pre-congestion back to the responsive codec...

> even if ecn-tunnel becomes a proposed standard?

As I said, it does make a neat fit with the RSVP signalling model. But I
have no strong views

> tunnelling, rather than 3-state encoding?

This question also needs to go out to people who wanted to include ECN
functionality. In particular we need to look at the issue of how to expose
PCN marking to the end-system in some later extension.

> you don't have to use both severity levels (i.e. single marking with

Yes, but exactly what else needs editing will depend on the decision
regarding what status to give this.

> Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1

Not really, as I say I prefer to make this an extension to baseline

---

From: <[email-masked]>
Date: Fri, 25 Jun 2010 15:48:26 +0200

Bob,

despite being no author I'd like to PSDM being maintained. 
Threshold marking combined with probe packets to avoid 
admission is simple an straightforward. I don't object if 
that feature is moved from PSDM to another document of 
the ones you mentioned below (and excuse if this happened 
already). Is this linked to ECN tunneling? 

The wording of 3 in 1 must allow for MPLS support of PCN with 
just two TC codepoints. Then baseline may be obsoleted.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: Friday, June 25, 2010 2:45 PM
To: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; Michael Menth; CHAN, Kwok Ho
Cc: PCN IETF list
Subject: [PCN] plan for PCN encodings, now ecn-tunnel is in last call

Questions:

Bob

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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Jun 2010 19:13:10 +0100

Ruediger,

At 14:48 25/06/2010, [email-masked] wrote:
>already).

Trouble is, I believe 3-in-1 and the encoding used by psdm are 
mutually incompatible.

I think it should be possible to do the probing you want and use 
threshold marking with 3-in-1 rather than PSDM.

I believe the motivation for PSDM was the other way round: if you use 
PSDM, you can only use one of the codepoints for probing, so probing 
became an integral part of PSDM. That doesn't preclude probing using 
another encoding.

Michael might be able to confirm whether I'm correct here-it's late 
on a Friday and my brain is fried.

>Is this linked to ECN tunneling?

PSDM was designed to work-round the ECN-tunnelling issue. And 
ecn-tunnel side-steps that issue. So in that sense, it's linked to tunnelling.

>just two TC codepoints. Then baseline may be obsoleted.

3-in-1 is an IP encoding, so it shouldn't constrain MPLS deployments. 
We could say that explicitly, but I think it's pretty clear already.

RFC5129 (ECN in MPLS) says words about only mapping the ECN 
codepoints you need from IP into the MPLS CoS field and mapping the 
rest all to the the same MPLS CoS codepoint.

HTH

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 25 Jun 2010 19:28:11 +0100

Toby,

>which was best... But as long as the W-G agrees to the new approach that

Yeah, I know but, now ecn-tunnel is nearly there, the world changes...

>Some quick answers inline....

Responses marked [BB] inline (non-repsonse to the other points means 
I agree)...

>Experiment as it allows lots of extra functionality in its extended form.

[BB]: We need to be brutal if we can make the same functionality work 
with 3-in-1

>extended encoding doesn't seem at all confusing to me...

[BB]: I'm trying to force the issue to see if we can do everything 
with one encoding now the tunnel issue has gone away.

Otherwise, I agree it would not make much sense to have a stds track 
baseline and a stds track extension, if experimental alternatives to 
the extension were mutually incompatible.

>domain to signal pre-congestion back to the responsive codec...

[BB]: You can do that with tunnelling just as well.

>regarding what status to give this.

[BB]: Seen the other way round, exactly how we edit it will determine 
whether it should deserve consensus and the status of stds track.

>Not really, as I say I prefer to make this an extension to baseline

[BB]: As above - depends whether we can satisfy all the features of the others.

Cheers

Bob

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jun 2010 01:34:55 +0200

Hi Bob and all,

Bob Briscoe schrieb:
> co-authors. I have also included the PCN list as there are others with 
> interest in the outcome (not least the chairs). I hope that's OK - 
> otherwise please accept my apologies and feel free to switch to 
> off-list mode.
>
> suggest a plan for how to deal with all the experimental PCN encodings 
> and then to try to update the drafts accordingly before the Maastricht 
> deadline.
>
ok

> * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2}
On the one hand I like the idea to have only a single relevant encoding. 
On the other hand I am not 100% sure that baseline encoding is no longer 
needed as it may take some time until new tunnels will be deployed.

I also thought that another advantage of baseline might be that it 
requires only two PCN states so that it requires fewer codepoints in the 
MPLS header. However, the same can be done with 3-in-1 encoding if only 
one marking scheme is used. After reading rfc 5129 it seems to me that 
pcn is considered only in the appendix and that only 3-in-1 is 
considered but baseline is not.  Therefore, when defining a necessary 
adaptation from 3-in-1 to mpls shim, it is possible to define a 
translation for three and for two used pcn states in that document. Hm, 
has anybody understood me? Am I correct?

> * draft-ietf-pcn-3-state-encoding -> expt track or expire{3}
ok

> * draft-ietf-pcn-psdm-encoding -> leave to expire?
ok. I saw some positive comments about psdm. However, I think what 
people like is rather the implicit probing feather than the encoding 
itself. I'll provide a write-up to separate implicit probing (edge 
behavior for admission control) from the encoding issue and make clear 
that it equally works with baseline or 3-in-1 encoding.

> * draft-satoh-pcn-st-marking -> (expired) -> leave to expire?
ok

> use 3-in-1 for single marking, you just don't use the extra codepoint.
ok And it should be made clear that baseline has no advantage over 
3-in-1 when going to MPLS.

> rather than keeping both on the stds track.
Currently I see that only the tunneling issue is an advantage of 
baseline encoding over 3-in-1. If we can expect that new tunnels are 
supported when PCN is deployed, I think baseline can be well obsoleted 
by 3-in-1 encoding.

> used when incoming packets are alread ECT.
I do not think that 3-state is very useful:
1) it cannot fully support e2e ECN - it gives support only if packets 
are not re-marked in a PCN domain, therefore, it cannot substitute tunneling
2) providing combined ECN & PCN information to end hosts requires 
additional signalling to the egress node which is a lot of extra work 
that still needs to be done. If the egress node has this information, it 
can provide combined PCN & ECN information also without this type of 
encoding.
Therefore, I can well live with the option of expiring 3-state encoding.

> even if ecn-tunnel becomes a proposed standard?
Not in this form. What's useful is implicit probing as edge behavior and 
that's what people especially liked due to its simplicity. I'll provide 
a draft that retains this aspect.

> tunnelling, rather than 3-state encoding?
I prefer tunneling as 3-state does not give support for e2e ECN as soon 
as packets are re-marked in the PCN domain.

> Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 
If we can be sure that new tunnels are available before PCN is deployed, 
obsoleting RFC5696 is a good option.

Best wishes,

    Michael

> become compliant with this new spec (!), an operator wanting to deploy 
> PCN can ask tunnel vendors to comply with it.
>

-- 
PD Dr. habil. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/31-86632 (new)
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Michael Menth <[email-masked]>
Date: Tue, 29 Jun 2010 01:40:04 +0200

Hi Bob, hi Ruediger,

psdm was able to support both admission control based on threshold 
marking and flow termination based on excess marking with current 
tunnels. However, psdm required implicit probing as edge behavior for 
admission control as it cannot support CLE-based admission control. In 
contrast, implicit probing does not depend on psdm, it can be equally 
applied with baseline or 3-in-1. I'll provide a write-up for that.

Best wishes,

    Michael

Bob Briscoe schrieb:
> Michael might be able to confirm whether I'm correct here-it's late on 
> a Friday and my brain is fried.
>
> RFC5129 (ECN in MPLS) says words about only mapping the ECN codepoints 
> you need from IP into the MPLS CoS field and mapping the rest all to 
> the the same MPLS CoS codepoint.
>
> HTH
>
>
> Bob
>
>
>
>> Regards,
>>
>> Ruediger
>>
>>
>>

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 29 Jun 2010 09:28:53 +0100

I have trimmed the reply to the key points Michael was making

> From: Michael Menth [mailto:[email-masked]]
> Sent: 29 June 2010 00:35
> To: Bob Briscoe
> Cc: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; CHAN, Kwok Ho; PCN
> IETF list
> Subject: Re: plan for PCN encodings, now ecn-tunnel is in last call
> 
> Hi Bob and all,
> 

That shows that baseline wasn't even invented as an option until after
RFC5129 had been published... The really key point relates to the issue of
when the new tunnels are deployed. I suspect Bob's argument might be that
this would add another deployment incentive for those new tunnels, on the
other hand things can take a good while to be deployed in the core...

One solution would be to effectively merge the two by having a "legacy
encoding" in 3-in-1 that is essentially baseline and applies whenever
old-style tunnels are in operation...

> that it equally works with baseline or 3-in-1 encoding.

That sounds an excellent idea. I think you are right that it was the probing
feature that attracted most people and as you rightly say, that can be used
with other encodings.

> supported when PCN is deployed, I think baseline can be well obsoleted

See my earlier comment about merging the two documents and providing a
legacy encoding within 3-in-1

> Therefore, I can well live with the option of expiring 3-state

Reasonable points. Would like to get an explicit response from Ingemar and
the others that were interested in E2E ECN support in PCN...

Toby

---

From: SATOH Daisuke <[email-masked]>
Date: Tue, 29 Jun 2010 17:30:53 +0900

Dear Bob, Michael, and all

On Tue, 29 Jun 2010 01:34:55 +0200

> > * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds 

OK

> has anybody understood me? Am I correct?

As Michael writes, adaptaion from 3-in-1 to mpls shim is necessary.

> > * draft-ietf-pcn-3-state-encoding -> expt track or expire{3}

OK

> > * draft-ietf-pcn-psdm-encoding -> leave to expire?

OK.

> > * draft-satoh-pcn-st-marking -> (expired) -> leave to expire?

OK

Best regards,
Daisuke

---

From: Tom Taylor <[email-masked]>
Date: Tue, 29 Jun 2010 10:48:18 -0400

Does this mean we have to postpone WGLC on the edge behaviour drafts? Or can we 
factor in the changes at a later stage?

Tom Taylor