Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN?

From: Michael Menth <[email-masked]>
Date: Tue, 12 Feb 2008 17:07:36 +0100

Hi all,

I am not so happy yet with the current version of the encoding
draft. I am worrying about extensibility of edge-to-edge PCN to
end-to-end PCN. I do not want push work towards end-to-end PCN in
the near future, but we should be aware that a wrong encoding
might close the door for end-to-end PCN. We should only
intentionally close the door or keep it open.

I discuss two different marking schemes taking this issue into
account.

1. Non-extensible solution for edge-to-edge PCN

When we do not want to extend PCN towards an end-to-end solution,
we can stick with edge-to-edge PCN islands. If we take the
decision that these islands do not support ECN, we can simply
reuse the ECN-bits for encoding. To take advantage of the marking
functionality of legacy ECN equipment, "excess-traffic" (ET)
should be mapped to ECN's CE (11) codepoint, and
"no-pre-congestion" (NP) as well as "admission-stop" (AS) should
be mapped to ECN's ECT(0) and ECT(1) (10, 01). Then, ECN's
codepoint not-ECT (00) is left over to indicate non-PCN traffic.
This scheme requires that traffic is remarked when entering a PCN
domain. All 11-marked packets must be dropped. Afterwards, all
non-PCN traffic is remarked to 00 and PCN traffic is remarked to
e.g. 01. Upon leaving the PCN domain, all traffic is reset to 00.

Bad: This scheme is applicable only in a closed island where ECN
     semantics are substituted by PCN semantics. It cannot be
     extended to an end-to-end solution since it is not possible
     to differentiate PCN from non-PCN traffic.
     ECN marks are lost for PCN and non-PCN traffic.

Good: PCN encoding does not require a new DSCP and PCN can be
applied to any DSCP allowing PCN support for various service
classes (DSCPs).

2. Solution for end-to-end PCN treating edge-to-edge PCN as a
special case

This requires the definition of a new "PCN DSCP" indicating that
endpoints (either host nodes or proxies) implement the semantics
of PCN instead of ECN. PCN treatment is only applied to traffic
with the PCN DSCP. However, ECN treatment is possibly applied to
PCN traffic by legacy nodes. A core question is: what is the
desired behavior in that case? Should CE-marking be different from
ET-marking or not?
 a) ET=CE=11: legacy nodes throttle ECN flows and tear down PCN
 flows in case of overload;
 other mappings {NP, AS} -> {ECT(0), ECT(1)}
 b) CE not used for PCN encoding: CE-marking always results from
 overloaded ECN nodes. Therefore, endpoints should either drop
 such packets or hand them to TCP if it is ECN-capable.
 mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)}

Edge-to-edge PCN is a special case of this encoding scheme when
ingress and egress nodes of a PCN domain act as proxies for
endpoints.
This implies for PCN ingress nodes: drop all 11-marked PCN packets
and then mark the other PCN packets with NP
This implies for PCN egress nodes:
 case a) remark all 01, 10, 11-marked PCN packets to 00
         Problem: 1. not-ECT flows with CE-marked packets by pure ECN
                  nodes within the PCN domain do not back off
                  2. PCN traffic is terminated while non-PCN
                  traffic continues to send in case of congestion
                  when PCN domain contains pure ECN nodes
                  -> PCN traffic is squeezed out
 case b) remark all 01, 10-marked PCN packets to 00; let 11-marked
         packets escape if all nodes of the PCN domain are PCN-enabled
         and drop them if the PCN domain has some nodes that are only
         ECN-enabled.

Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage
     for non-PCN traffic.

Bad: requires definition of new DSCP, cannot be used for different
     traffic classes; Simultaneous usage of PCN and ECN not possible

If you think this kind of reflection is useful, I'd be happy to
see it in the encoding draft.

I am interested in your opinion about closing the door for
end-to-end PCN or keeping it open.

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

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 13 Feb 2008 09:07:49 +0100

Hello Michael,

a discussion like the one you've proposed should find a place in the 
encoding draft until there's an agreed solution on how to proceed 
on the issue. I don't it must be in the core document (an annex may 
do), but your concerns are valid and shouldn't be ignored.

Regards,

Ruediger

| -----Original Message-----
| From: Michael Menth [mailto:[email-masked]] 
| Sent: Tuesday, February 12, 2008 5:08 PM
| To: pcn
| Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN?
| 
| Hi all,
| 
| I am not so happy yet with the current version of the 
| encoding draft. I am worrying about extensibility of 
| edge-to-edge PCN to end-to-end PCN. I do not want push work 
| towards end-to-end PCN in the near future, but we should be 
| aware that a wrong encoding might close the door for 
| end-to-end PCN. We should only intentionally close the door 
| or keep it open.
| 
| I discuss two different marking schemes taking this issue 
| into account.
| 
| 1. Non-extensible solution for edge-to-edge PCN
| 
| When we do not want to extend PCN towards an end-to-end 
| solution, we can stick with edge-to-edge PCN islands. If we 
| take the decision that these islands do not support ECN, we 
| can simply reuse the ECN-bits for encoding. To take advantage 
| of the marking functionality of legacy ECN equipment, 
| "excess-traffic" (ET) should be mapped to ECN's CE (11) 
| codepoint, and "no-pre-congestion" (NP) as well as 
| "admission-stop" (AS) should be mapped to ECN's ECT(0) and 
| ECT(1) (10, 01). Then, ECN's codepoint not-ECT (00) is left 
| over to indicate non-PCN traffic.
| This scheme requires that traffic is remarked when entering a 
| PCN domain. All 11-marked packets must be dropped. 
| Afterwards, all non-PCN traffic is remarked to 00 and PCN 
| traffic is remarked to e.g. 01. Upon leaving the PCN domain, 
| all traffic is reset to 00.
| 
| Bad: This scheme is applicable only in a closed island where ECN
|      semantics are substituted by PCN semantics. It cannot be
|      extended to an end-to-end solution since it is not possible
|      to differentiate PCN from non-PCN traffic.
|      ECN marks are lost for PCN and non-PCN traffic.
| 
| Good: PCN encoding does not require a new DSCP and PCN can be 
| applied to any DSCP allowing PCN support for various service 
| classes (DSCPs).
| 
| 
| 2. Solution for end-to-end PCN treating edge-to-edge PCN as a 
| special case
| 
| This requires the definition of a new "PCN DSCP" indicating 
| that endpoints (either host nodes or proxies) implement the 
| semantics of PCN instead of ECN. PCN treatment is only 
| applied to traffic with the PCN DSCP. However, ECN treatment 
| is possibly applied to PCN traffic by legacy nodes. A core 
| question is: what is the desired behavior in that case? 
| Should CE-marking be different from ET-marking or not?
|  a) ET=CE=11: legacy nodes throttle ECN flows and tear down 
| PCN  flows in case of overload;  other mappings {NP, AS} -> 
| {ECT(0), ECT(1)}
|  b) CE not used for PCN encoding: CE-marking always results 
| from  overloaded ECN nodes. Therefore, endpoints should 
| either drop  such packets or hand them to TCP if it is ECN-capable.
|  mapping: NP -> not-ECT, {AS, ET} -> {ECT(0), ECT(1)}
| 
| Edge-to-edge PCN is a special case of this encoding scheme 
| when ingress and egress nodes of a PCN domain act as proxies 
| for endpoints.
| This implies for PCN ingress nodes: drop all 11-marked PCN 
| packets and then mark the other PCN packets with NP This 
| implies for PCN egress nodes:
|  case a) remark all 01, 10, 11-marked PCN packets to 00
|          Problem: 1. not-ECT flows with CE-marked packets by pure ECN
|                   nodes within the PCN domain do not back off
|                   2. PCN traffic is terminated while non-PCN
|                   traffic continues to send in case of congestion
|                   when PCN domain contains pure ECN nodes
|                   -> PCN traffic is squeezed out  case b) 
| remark all 01, 10-marked PCN packets to 00; let 11-marked
|          packets escape if all nodes of the PCN domain are PCN-enabled
|          and drop them if the PCN domain has some nodes that are only
|          ECN-enabled.
| 
| Good: Scheme keeps the door open for end-to-end PCN; Allows ECN-usage
|      for non-PCN traffic.
| 
| Bad: requires definition of new DSCP, cannot be used for different
|      traffic classes; Simultaneous usage of PCN and ECN not possible
| 
| 
| If you think this kind of reflection is useful, I'd be happy 
| to see it in the encoding draft.
| 
| I am interested in your opinion about closing the door for 
| end-to-end PCN or keeping it open.
| 
| 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
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| http://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 13 Feb 2008 09:19:55 -0000

Michael 
In the detail of what you write, some I agree with and some I don't
follow. However, I don't agree with the context you set it of "1.
Non-extensible solution for edge-to-edge PCN " & "2. Solution for
end-to-end PCN treating edge-to-edge PCN as a special case". For
instance, in 1 I think you're assuming that non_PCN traffic is
distinguished by setting the codepoint to 00. I think I prefer that a
known dscp indicated pcn-traffic in the pcn-domain, ie non-pcn traffic
uses other dscp(s). then the non-pcn traffic doesn't need to be touched
by the pcn-mechanisms. 

Where you say >      ECN marks are lost for PCN and non-PCN traffic.
With a separate dscp, they're not lost for non-pcn traffic - nor for
pcn-traffic if tunnel (or downgrade to BE) (assuming that ECN on
pcn-traffic is really needed). 

I found some of 2 a bit confusing, as legacy node could mean a node
outside the pcn-domain, or a misconfigured pcn-interior-node or a
misconfigured pcn-boundary-node. You seem to introduce the concept of
pure ecn nodes within the pcn-domain, which I don't agree with. 
> let 11-marked packets escape if all nodes of the PCN domain are PCN-
> enabled
why?

On a separate topic, I think the encoding draft should also consider
this issue. Re-reading
http://www.watersprings.org/pub/id/draft-charny-pcn-comparison-00.txt
about the requirement that a router doing admission marking must ensure
it doesn't over-write onto a pkt that's already termination marked -
this threatens to introduce implementation complexity of having to check
the marking state of a pkt before marking. So an encoding scheme which
allows a pkts to be both AM & TM would be beneficial. At least this
should be on the evaluation criteria.  

phil
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Menth
> Sent: 12 February 2008 16:08
> To: pcn
> Subject: [PCN] PCN encoding: keep the door open for end-to-end PCN?
> 
> Hi all,
>

---

From: Michael Menth <[email-masked]>
Date: Wed, 13 Feb 2008 10:46:54 +0100

Hi Phil,

> uses other dscp(s). then the non-pcn traffic doesn't need to be touched

You are right, but you consider a different scenario. I don't say we 
should follow 1, I am rather in favor of option 2 (like you). I just 
want to point out the implications of a pure ECN-bit solution.

> pcn-traffic is really needed). 
That's another reason why I also find option 2 better than option 1. 
Regarding tunneling, I think this is a rather high price to save the ECN 
marks (and to not drop previously 11-marked CE packets).

> pure ecn nodes within the pcn-domain, which I don't agree with. 
Yes, that is what I have considered. Do you disagree with the term 
legacy node or do you find this scenario unlikely? I mean, do you assume 
that 100% of all nodes are upgraded when a PCN domain is defined? I can 
imagine that some older routers are reused for simple forwarding. But 
I'm the university guy who doesn't know the operations of providers so well.

>> let 11-marked packets escape if all nodes of the PCN domain are PCN-
This applies to 2b where codepoint 11 is not used for PCN marking. If 
there are no pure ECN nodes in the PCN domain, 11-marked PCN packets do 
not need to be dropped by the PCN ingress (forgot to say that in the 
short description). Thus, all 11-marked PCN packets stem from previous 
ECN-nodes and can be savely conveyed to the endpoints to throttle the 
TCP senders.

> should be on the evaluation criteria.  

I see that it possibly facilitates implementation. However, TM is a 
"stronger" marking that subsumes AM. Having codpoints indicating 
"no-pre-congestion" (NP), AM, TM, and AM&TM is a waste of bits. 
Therefore, I think that this criterion should be ranked rather low.

Michael

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 13 Feb 2008 11:06:17 -0500

Hi Ruediger:
The encoding comparison draft currently calls out the different
encoding options' satisfying RFC 4774 (Alternate ECN) concerns.
With an eye on trying to allow the same encoding be used for
edge-to-edge deployment now and end-to-end in the future.
This is not clearly state in the draft.

Hence the notion of edge-to-edge and end-to-end should be added
as one of the criteria at the beginning of the draft and bring this out
more clearly in the encoding option discussion sections.

Thanks!
-- Kwok --

---

From: <[email-masked]>
Date: Wed, 13 Feb 2008 16:49:18 -0000

Kwok

Rather than "satisfying 4774" & "end-to-end" being the criteria, I think
it would be better to have criteria that are things like: what
assumptions are made? (the real difference between edge-to-edge &
end-to-end ecn)  What is the impact of a misconfigured egress node?
What's the impact on ecn, under particular assumptions? (4774 inspires
some of these questions)

phil
> Kwok-Ho Chan
> Sent: 13 February 2008 16:06
> To: Geib, Ruediger
> Cc: [email-masked]
> Subject: Re: [PCN] PCN encoding: keep the door open for end-to-end
PCN?

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 13 Feb 2008 12:24:15 -0500

Hi Phil:
Thanks!
Please see inline below.
-- Kwok --

At 11:49 AM 2/13/2008, [email-masked] wrote:
>end-to-end ecn)

More of a top down approach, the draft currently is more bottom up 
(with 4774, etc).

>What is the impact of a misconfigured egress node?
I believe there are discussion of this in the draft currently, we have also
touched on misconfigured ingress node (leaking of ECN packets into PCN domain).
Need to bring them out more clearly and then tie this back into how they
may affect the edge-to-edge and end-to-end issues (the encoding part only).