RE: ECN support in a PCN domain (was: Re: [PCN] commentsondraft-ietf-pcn-architecture-02)

["Jozef Babiarz" <[e-mail]>]

Ruediger, I'm not sure if I understand your scenario completely but will
state some assumption so hopefully it will help.

Assumptions: 
PCN function is added to a Diffserv enabled network. That means that
this network has at least two service classes (or traffic classes) but
most likely more than two. 

In the Diffserv enabled network there is at least on service class that
does not support the PCN function.

So if a flow arrives that is not PCN enabled, it should be mapped at
ingress to a non-PCN capable service class. The ECN field must be
unchanged. 

Only PCN-capable flows/packets should be mapped into the PCN-enabled
service class.

If the wg decides to define a new codepoint and PHB for PCN that reuses
ECN field for PCN function, than we need to state what happens if a PCN
packet hits a router that is not PCN-capable or if it is ECN-capable.

If a PCN marked packet hits a router that is not PCN-capable, the router
provides the default treatment that any packet would receive.

If the ECN field is used for PCN marking and a PCN marked packet hits an
ECN-capable router, than the router should threat this packet like any
other ECN-cable flow (assuming the ECN-field is other then zero) and set
the CE bits if congestion is experienced.

I'm not sure if this should be discussed in the architecture draft as it
depends on what marking (bits in IP header) approach is agreed to.


Regards, Joe
email:[e-mail]
Telephone:[phone]

-----Original Message-----
From: Geib, Ruediger [mailto:[e-mail]] 
Sent: November 26, 2007 3:04 AM
To: Babiarz, Jozef (CAR:0S03)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: ECN support in a PCN domain (was: Re: [PCN]
commentsondraft-ietf-pcn-architecture-02)

Joe,

you and Magnus consider fundamental issues. I'm more interested in daily
business and there specifically in "unexpected events": the PCN ingress
node receives a packet on a non PCN interface and this packet carries a
DSCP which the ingress node will map to the PCN DSCP. Further, this
packet has some ECN bits set (which is the unexpected event). The
architecture document (or any other document indicated by the
architecture doc) should recommend an action. And this action should
allow for later extensions - congestion feedback given to the end
system, especially.

Assume the flow to be admitted. My personal preference is to ignore the
ECN bits and overwrite them. Dropping seems to tough. And keeping the
markings may result in wrong congestion status (may be only depending on
the specific ECN codepoint).

The same holds, if DSCPs are used for pre-congestion marking and a
packet arrives the ingress with a pre-congestion DSCP.

We need to define an action of the ingress node.

Regards,

Rudiger

|-----Original Message-----
|From: Jozef Babiarz [mailto:[e-mail]]
|Sent: Friday, November 23, 2007 10:48 PM
|To: [e-mail]; Geib, Rudiger;
|[e-mail]; [e-mail]
|Subject: RE: ECN support in a PCN domain (was: Re: [PCN]
|commentsondraft-ietf-pcn-architecture-02)
|
|
|Phil, Ruediger and Magnus, 
|
|For Section 3.5, I would like to propose that it be replaced with the
|statement below.
|
|If the WG choose to use ECN flied for convey PCN information 
|through the
|network. The PCN WG will request that IANA assign a DSCP value for PCN
|traffic class consistent with RFC3246 and with PCN marking behavior
|defined by this workgroup. The Diffserv code point should be 
|referred to
|as PCN.
|
|Explanation:
|The PCN mechanism will use a new standardized DSCP and will reuse bits
|14 & 15 (the ECN-field) of the IPv4 header for PCN therefore no impact
|to RFC3168, meaning that PCN and ECN can co-exist in the same network.
|
|Could discuss other options but they get really messy. 
|
|Regards, Joe
|email:[e-mail]
|Telephone:[phone]
|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] 
|Sent: November 22, 2007 6:34 AM
|To: [e-mail]; [e-mail];
|Babiarz, Jozef (CAR:0S03)
|Subject: RE: ECN support in a PCN domain (was: Re: [PCN]
|commentsondraft-ietf-pcn-architecture-02)
|
|Joe, will leave this one to you as you thought about it more 
|than I did!
|Thanks
|phil
|
|> -----Original Message-----
|> From: Geib, Ruediger [mailto:[e-mail]]
|> Sent: 22 November 2007 11:14
|> To: [e-mail]
|> Cc: [e-mail]
|> Subject: RE: ECN support in a PCN domain (was: Re: [PCN]
|commentsondraft-
|> ietf-pcn-architecture-02)
|> 
|> Magnus,
|> 
|> I agree to your request, I've asked Phil for a statement on the
|behaviour
|> of an ingress node receiving a PCN coloured packet in the 
|architecture
|> draft in my latest mail.
|> 
|> I thougth about ignore and remark DSCP and ECN. Drop is a tough
|option.
|> Forward with DSCP Best Effort and unchanged ECM may be 
|another one (if
|> the DSCP is unknown on the ingress interface).
|> 
|> There are more possibilities, depending on the PCN marking mechanism
|and
|> whether the ECN codepoints are used.
|> 
|> Regards,
|> 
|> Rudiger
|> 
|> |>
|> |>    o  If a packet that is part of a PCN-flow arrives at a
|PCN-ingress-
|> |>       node with its CE (Congestion experienced) codepoint 
|set, then
|we
|> |>       assume that the PCN-ingress-node drops the packet.  
|After its
|> |>       initial Charter is complete, the WG may decide to work on a
|> |>       mechanism (such as through a signalling extension) that
|enables
|> |>       ECN-marking to be carried transparently across the
|PCN-domain."
|> |
|> |This one really surprise me. How can you make this assumption? In
|case a
|> |ECN enabled flow with some packets CE marked arrive to the 
|ingress of
|> |the PCN domain and are within the limits for which the flow has been
|> |admitted into the PCN domain, then the PCN domain has no right to
|> |summarily drop that packet as being less important than any of the
|> |unmarked packets. Only in cases if congestion actually is experience
|> |within the PCN domain would a differential treatment of CE marked
|> |packets being warranted.
|> |
|> |Can someone please explain how the above assumptions still satisfy
|the
|> |following sentence in the charter?
|> |
|> |"All PCN mechanisms, including transport and encoding
|> |of (pre-congestion) information, are required to cleanly integrate
|> |with existing architectures and protocols such as DiffServ and ECN."
|> |
|> |
|> |Cheers
|> |
|> |Magnus Westerlund
|> |
|> |IETF Transport Area Director & TSVWG Chair
|>
||----------------------------------------------------------------------
|> |Multimedia Technologies, Ericsson Research EAB/TVM/M
|>
||----------------------------------------------------------------------
|> |Ericsson AB                | Phone [phone]
|> |Torshamsgatan 23           | Fax   [phone]
|> |S-164 80 Stockholm, Sweden | mailto: [e-mail]
|>
||----------------------------------------------------------------------
|> |
|> |
|> |_______________________________________________
|> |PCN mailing list
|> |[e-mail]
|> |https://www1.ietf.org/mailman/listinfo/pcn
|> |
|> 
|> 
|> _______________________________________________
|> PCN mailing list
|> [e-mail]
|> https://www1.ietf.org/mailman/listinfo/pcn
|


_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn