Subject: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains

From: "Sarker Zaheduzzaman" <[email-masked]>
Date: Tue, 19 Feb 2008 09:58:09 +0100

Hi,

A new draft has been submitted to the PCN WG, comments are very welcome. Originally this was supposed to be a teamwork with Bob Briscoe but due to an unfortunate event he could not be a part of this draft this time. we welcome his contribution as well as the contributions from other interested people in future versions of this draft.

Title:
 Usecases and Benefits of end to end ECN support in PCN Domains 

Abstract :
 This document provides an informative overview of possible use cases where ECN marking can be used for inelastic traffic. It outlines benefits of preserving the ECN support in a PCN domain. As ECN provides with a simple mechanism for network nodes to inform the end points about possible upcoming congestion and resulting packet losses and delay increase, the scheme can be useful for adaptive real-time media applications, thus enabling them to adjust the transmission rate to avoid quality degradation due to congestion. By showing the benefits of ECN this memo asks the working group to consider end to end ECN support in PCN domain. 

Link:
 http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt

Regards
Zaheduzzaman Sarker

-----------------------------------------------------------------------------------------
ANM Zaheduzzaman Sarker
Research Engineer
EAB/TVP -Multimedia Technologies
Ericsson Research
Ericsson AB
S-971 28 Luleå, Sweden
Tel: +46 (0)8 7573743
ECN: 850-73743
Mobile: +46 (0)76 1153743 
www.ericsson.com

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

---

From: Michael Menth <[email-masked]>
Date: Wed, 20 Feb 2008 14:55:35 +0100

Hi Sarker,

your ID is a pleading to keep ECN within a PCN domain. There are various 
options:

1. All traffic crossing a PCN domain keeps ECN capability (inlcuding PCN 
traffic).
2. Only non-PCN traffic keeps ECN marking.
3. No traffic keeps ECN marking (e.g. all packets have ECN bits set to 
00 at the egress).

Option 3 is possible if we use only ECN bits for PCN encoding without 
using DSCP (see my attached email I sent to this list a week ago). It's 
nice as it does not require DSCPs such that PCN can basically be applied 
to any DSCP, but the loss of  ECN capability for  all(!) traffic 
crossing the PCN domain would be the price we have to pay. Your draft 
says this price is high.

Regards,

    Michael

Sarker Zaheduzzaman wrote:
>
> Hi,
>
> A new draft has been submitted to the PCN WG, comments are very 
> welcome. Originally this was supposed to be a teamwork with Bob 
> Briscoe but due to an unfortunate event he could not be a part of this 
> draft this time. we welcome his contribution as well as the 
> contributions from other interested people in future versions of this 
> draft.
>
> Title:
>  This document provides an informative overview of possible use cases 
> where ECN marking can be used for inelastic traffic. It outlines 
> benefits of preserving the ECN support in a PCN domain. As ECN 
> provides with a simple mechanism for network nodes to inform the end 
> points about possible upcoming congestion and resulting packet losses 
> and delay increase, the scheme can be useful for adaptive real-time 
> media applications, thus enabling them to adjust the transmission rate 
> to avoid quality degradation due to congestion. By showing the 
> benefits of ECN this memo asks the working group to consider end to 
> end ECN support in PCN domain.
>
> Link:
>  _http://tools.ietf.org/wg/pcn/draft-sarker-pcn-ecn-pcn-usecases-00.txt_
>
> Regards
> Zaheduzzaman Sarker
>
> _www.ericsson.com_ <file://www.ericsson.com>
>
>
> ------------------------------------------------------------------------
>

-- 
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

Subject: PCN encoding: keep the door open for end-to-end PCN?
From: Michael Menth <[email-masked]>
To: pcn <[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