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

["Geib, Ruediger" <[e-mail]>]

Hi Joe,

the issue on which I suggest to have text on is simpler than the ones 
you suggest. To clarify my point, I add a short sketch:

                     +--------------+
---non PCN domain-->-| Ingress Node |->-PCN domain------
                     +--------------+

My point is that I'd like to have an explicit statement in the 
architecture, how the ingress node should behave if it receives a 
"PCN coloured" packet on the non PCN domain interface. The 
behaviour should cover all cases, i.e. also those 
which are not planned like a packet of an admitted flow with 
an ECN codepoint or DSCP indicating pre-congestion received 
on the non PCN domain interface.

Phil mentioned that there's text in the draft architecture.
I don't find a clear statement or a reference on the text 
defining the desired behaviour for the above case in:

5.2.  PCN-ingress-node functions
10.  Security considerations

Regards,

Rudiger


|-----Original Message-----
|From: Jozef Babiarz [mailto:[e-mail]]
|Sent: Tuesday, November 27, 2007 11:20 PM
|To: Geib, Rudiger
|Cc: [e-mail]; [e-mail]; [e-mail]
|Subject: RE: ECN support in a PCN domain (was: Re: [PCN]
|commentsondraft-ietf-pcn-architecture-02)
|
|
|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