Subject: [PCN] comments on draft-ietf-pcn-architecture-02

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 06:37:10 +0000

Hi Phil, Hi all

I think that version 02 of the the PCN architecture draft is good!
However, I have three comments:

Comment_1:
I could not find information in the draft that mentions the below issue
given in the PCN charter:

"The WG may also consider to investigate additional response
mechanisms that act on (pre-)congestion information. One example
could be flow-rate adaptation (rather than flow admission/
termination) during times of congestion."

Please include a paragraph that discusses this!
-------------------------------------------

Comment_2:
Section 3.5:
You mention:
   "The following two assumptions apply if the PCN WG decides to encode
   PCN-marking in the ECN-field.

   o  It is assumed that PCN-nodes do not perform ECN, [RFC3168], on
      PCN-packets.

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

If I understand the two above assumptions well, they say that traffic
that is arriving into the PCN domain and is end-to-end ECN aware can
only keep its end-to-end ECN semantics if it is tunnelled.
In my opinion this is one possible implementation. There might also be
other implementation. I think that this assumption should refer to the
requirements described in RFC 4774:
http://www.ietf.org/rfc/rfc4774.txt?number=4774

Please use the below paragraph instead the one that is given above:
  "The following two assumptions apply if the PCN WG decides to encode
   PCN-marking in the ECN-field.

   o It is assumed that the requirements imposed by RFC 4774 are
fulfilled."

-------------------

Comment_3:
In Section 3, page 29, you provide the below conclusion on the viewpoint
that admission control is always done by probing:

"The first point breaks Assumption 3 (aggregation) and hence means that
this viewpoint is out of scope of initial Charter of the PCN WG."

I do not agree with this conclusion, since I do not agree with the
argumentation that the first point breaks Assumption 3 more than the
situation that no probing is used during admission control.
Therefore, please remove the sentence:
"The first point breaks Assumption 3 (aggregation) and hence means that
this viewpoint is out of scope of initial Charter of the PCN WG."

Best regards,
Georgios

it will be better to have the follwoing assumption instead of

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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 22 Nov 2007 11:26:49 +0200

> Please include a paragraph that discusses this!

The sentence you quote is from a paragraph that starts with "After  
completion of the initial phase..." Many of the examples given in that  
paragraph will significantly revamp the PCN architecture, and  
duscissug them in the initial phase is likely to be unproductive.

Lars

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 10:29:38 -0000

Georgios,
Thanks for the comments!

> Comment_1:
Lars has answered.
 
> other implementation. 

Yes, I agree tunnelling would be one option, and that there would be
other implementations. Note the issue of how to carry ECN-marking
transparently across the PCN-domain is one that the WG may look at after
the initial Charter is done. Note also, the if: "if the PCN WG decides
to encode PCN-marking in the ECN-field" [in the terms of your encoding
draft, this would include ECN+DSCP option]
> I think that this assumption should refer to the

Yes, I think we could add a ref to 4774 somewhere in the draft, and this
seems a good place to do so. Will add as a 3rd bullet something like
"the Milestone on 'Survey of Encoding Choices' will consider the
implications of [RFC4774]"

> argumentation that the first point breaks Assumption 3 

the "first point" is this:
o  Simply admitting the new flow has a significant risk of leading to
      overload, because the PCN-domain reaches out towards the end
      terminals where link capacity is low.
The link capacity is low means that adding a single flow to the link can
move it directly from no congestion to overloaded [real queue grows
significantly or overflows]. This breaks the aggregation assumption. 

Best wishes
Phil/

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Nov 2007 11:32:54 +0100

Hi,

See inline

>    o  It is assumed that PCN-nodes do not perform ECN, [RFC3168], on

I would like to have a clarification on what is meant with PCN not doing
ECN. To me it seems that in situation where a ECN enabled flow goes
through a PCN domain and the flow are in a situation where a router
actually is congested, it should be able to have that those packets
being marked with CE when leaving the PCN domain. I know this is phase
two of the work if we ever gets there as it discusses another response
mechanism.

>       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 +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 22 Nov 2007 12:13:50 +0100

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 +46 8 4048287
|Torshamsgatan 23           | Fax   +46 8 7575550
|S-164 80 Stockholm, Sweden | mailto: [email-masked]
|----------------------------------------------------------------------
|
|
|_______________________________________________
|PCN mailing list
[email-masked]
|https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 13:29:24 +0100

Hi Phil

Thank you!
Please see comments regarding comment_3:

> The link capacity is low means that adding a single flow to 
> the link can move it directly from no congestion to 
> overloaded [real queue grows significantly or overflows]. 
> This breaks the aggregation assumption. 

Georgios: yes, But if the link capacity is low and the admission
threshold/rate in an PCN-interior node 
is high (by configuration), how then a single flow can move the state in the
PCN_interior_node from 
no congestion to congestion? This means that the admission threshold/rate
should be doen properly such 
that such a situation will not occur!

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: donderdag 22 november 2007 11:30
> To: [email-masked]; [email-masked]
> Subject: RE: [PCN] comments on draft-ietf-pcn-architecture-02
> 
> Georgios,
> Thanks for the comments!
> 
> > Comment_1:
> Lars has answered.
>  
> > Comment_2:
> > Section 3.5:
> > You mention:
> Yes, I agree tunnelling would be one option, and that there 
> would be other implementations. Note the issue of how to 
> carry ECN-marking transparently across the PCN-domain is one 
> that the WG may look at after the initial Charter is done. 
> Note also, the if: "if the PCN WG decides to encode 
> PCN-marking in the ECN-field" [in the terms of your encoding 
> > I think that this assumption should refer to the requirements 
> > described in RFC 4774:
> Yes, I think we could add a ref to 4774 somewhere in the 
> draft, and this seems a good place to do so. Will add as a 
> 3rd bullet something like "the Milestone on 'Survey of 
> Encoding Choices' will consider the implications of [RFC4774]"
> 
> > 
> > -------------------
> > 
> > Comment_3:
> The link capacity is low means that adding a single flow to 
> the link can move it directly from no congestion to 
> overloaded [real queue grows significantly or overflows]. 
> This breaks the aggregation assumption. 
> Best wishes
> Phil/
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 13:34:52 +0100

Hi Lars

Thank you ver much!

Best regards,
Georgios

> From: Lars Eggert [mailto:[email-masked]] 
> Sent: donderdag 22 november 2007 10:27
> To: ext Georgios Karagiannis
> Cc: pcn
> Subject: Re: [PCN] comments on draft-ietf-pcn-architecture-02
> 
> > I could not find information in the draft that mentions the below 
> > issue given in the PCN charter:
> >
> > mechanisms that act on (pre-)congestion information. One 
> example could 
> > be flow-rate adaptation (rather than flow admission/
> The sentence you quote is from a paragraph that starts with 
> "After completion of the initial phase..." Many of the 
> examples given in that paragraph will significantly revamp 
> the PCN architecture, and duscissug them in the initial phase 
> is likely to be unproductive.
> 
> Lars
>

---

From: <[email-masked]>
Date: Thu, 22 Nov 2007 12:38:40 -0000

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 22 November 2007 12:29
> To: Eardley,PL,Philip,CXR9 R; [email-masked]
> is high (by configuration), how then a single flow can move the state
in
> the
after a bit of puzzling...
I was talking about the situation where the low capacity link is inside
the PCN-domain. I think your situation is different, where there's an
access network not running PCN, and the low capacity link is in the
access nw.
Is this right?

If yes, I'd say that how you do admission control in the access nw
(which isn't running PCN) is not a concern of PCN. if you want to always
do 'adm ctrl by probing' in the access nw, that's fine. presumably when
the PCN-boundary-nodes sees one of these probes then it's triggered to
do some PCN adm ctrl activity.

---

From: Steven Blake <[email-masked]>
Date: Fri, 23 Nov 2007 13:14:49 -0500

> two of the work if we ever gets there as it discusses another response

Sentence one of the PCN charter says:

  "The Congestion and Pre-Congestion Notification (PCN) working group
   develops mechanisms to protect the quality-of-service of established 
   inelastic flows within a DiffServ domain when congestion is imminent 
   or existing."

Should "inelastic" flows ever have one of the ECT nonces set?

The reason this might be an issue, is that PCN is considering reusing
the ECN bits.

For clarification, the draft text does not apply to elastic traffic that
is not being handled by PCN mechanisms (i.e., not part of a PCN-managed
behavior aggregate).

> with existing architectures and protocols such as DiffServ and ECN."

I think that PCN has been defined in the charter to not apply for
traffic which might use an ECN-capable transport protocol.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 23 Nov 2007 16:47:44 -0500

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:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: November 22, 2007 6:34 AM
To: [email-masked]; [email-masked];
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

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 22 November 2007 11:14
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: ECN support in a PCN domain (was: Re: [PCN]
commentsondraft-
> ietf-pcn-architecture-02)
> 
> Magnus,
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 26 Nov 2007 09:04:20 +0100

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:[email-masked]]
|Sent: Friday, November 23, 2007 10:48 PM
|To: [email-masked]; Geib, Rudiger;
[email-masked]; [email-masked]
|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:[email-masked]
|Telephone:613-763-6098
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] 
|Sent: November 22, 2007 6:34 AM
|To: [email-masked]; [email-masked];
|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:[email-masked]]
|> Sent: 22 November 2007 11:14
|> To: [email-masked]
|> Cc: [email-masked]
|> 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 +46 8 4048287
|> |Torshamsgatan 23           | Fax   +46 8 7575550
|> |S-164 80 Stockholm, Sweden | mailto: [email-masked]
|>
||----------------------------------------------------------------------
|> |
|> |
|> |_______________________________________________
|> |PCN mailing list
|> [email-masked]
|> |https://www1.ietf.org/mailman/listinfo/pcn
|> |
|> 
|> 
|> _______________________________________________
|> PCN mailing list
|> [email-masked]
|> https://www1.ietf.org/mailman/listinfo/pcn
|

---

From: <[email-masked]>
Date: Mon, 26 Nov 2007 13:18:43 -0000

Joe, whilst I personally agree that your suggestion is sensible, was
trying to keep the architecture draft independent of decisions about
encoding which are taken later in the WGs life. 

Rudiger
Yes, there are several possibilities. The one in the draft seemed the
safest (given that end point reaction is same to dropped pkt as CE).

phil

> From: Jozef Babiarz [mailto:[email-masked]]
> Sent: 23 November 2007 21:48
> To: Eardley,PL,Philip,CXR9 R; [email-masked];
> [email-masked]; [email-masked]
commentsondraft-
> > |>       node with its CE (Congestion experienced) codepoint set,
then
> we

---

From: "Jozef Babiarz" <[email-masked]>
Date: Tue, 27 Nov 2007 17:19:40 -0500

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:[email-masked]
Telephone:613-763-6098

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

Joe,

Regards,

Rudiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 28 Nov 2007 09:13:02 +0100

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:[email-masked]]
|Sent: Tuesday, November 27, 2007 11:20 PM
|To: Geib, Rudiger
|Cc: [email-masked]; [email-masked]; [email-masked]
|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:[email-masked]
|Telephone:613-763-6098
|
|-----Original Message-----
|From: Geib, Ruediger [mailto:[email-masked]] 
|Sent: November 26, 2007 3:04 AM
|To: Babiarz, Jozef (CAR:0S03)
|Cc: [email-masked]; [email-masked]; [email-masked]
|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:[email-masked]]
||Sent: Friday, November 23, 2007 10:48 PM
||To: [email-masked]; Geib, Rudiger;
[email-masked]; [email-masked]
||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:[email-masked]
||Telephone:613-763-6098
||-----Original Message-----
||From: [email-masked] [mailto:[email-masked]] 
||Sent: November 22, 2007 6:34 AM
||To: [email-masked]; [email-masked];
||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:[email-masked]]
||> Sent: 22 November 2007 11:14
||> To: [email-masked]
||> Cc: [email-masked]
||> 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 +46 8 4048287
||> |Torshamsgatan 23           | Fax   +46 8 7575550
||> |S-164 80 Stockholm, Sweden | mailto: [email-masked]
||>
|||-------------------------------------------------------------
|---------
||> |
||> |
||> |_______________________________________________
||> |PCN mailing list
||> [email-masked]
||> |https://www1.ietf.org/mailman/listinfo/pcn
||> |
||> 
||> 
||> _______________________________________________
||> PCN mailing list
||> [email-masked]
||> https://www1.ietf.org/mailman/listinfo/pcn
||
|

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Nov 2007 11:44:19 +0100

> Should "inelastic" flows ever have one of the ECT nonces set?

It could have, and also inelastic is not far from being rate change
capable which in my mind is a future step for PCN. In other words
indicate rate change needed rather than flow termination when being
congested. And from that point of view, is that what PCN treats as
inelastic traffic may actually use ECN for rate adaptation end to end.

Thus ECN enabled traffic may show up on a PCN enabled ingress node with
a DSCP mapping it into a PCN enabled flow.

> The reason this might be an issue, is that PCN is considering reusing

Yes, and that is why PCN needs to consider on how to maintain ECN
capability. I would like to point to the following sentence in the PCN
charter:

> is not being handled by PCN mechanisms (i.e., not part of a PCN-managed

Agreed.

> traffic which might use an ECN-capable transport protocol.

No, I don't agree with this characterization. I can't remember that
being the notion. If I remember Lars and my discussion one of the
reason we did charter PCN like we did was to ensure that you actually
could find a encoding that works and maintains ECN across the PCN
domain. And that is according to my memory what the following sentence
is intended for:

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.

And if there exist no reasonable solution to encode PCN while
maintaining ECN across a PCN domain. Well that would be tough luck and
we would have to revisit the fundamentals. Which could require a new BOF
and rechartering to remove those.

My main message is: As I see it you are not allowed to take the easy way
out and ignore that incomming traffic may be ECN enabled. You will have
to do something reasonable with that.

cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM

---

From: Steven Blake <[email-masked]>
Date: Wed, 28 Nov 2007 11:09:28 -0500

> a DSCP mapping it into a PCN enabled flow.

We obviously have a different understanding of ECN (which means that
mine is probably wrong).

[snip]

> to do something reasonable with that.

Understood.  

Note to wg: let us keep this point in mind when discussing
draft-chan-pcn-encoding-comparison-01.

Regards,

---

From: <[email-masked]>
Date: Wed, 28 Nov 2007 17:49:41 -0000

> >> This one really surprise me. How can you make this assumption? In
case
> a
magnus,
here's the background to the bulleted text [at the start of above - in
current I-D]. or rather, my perspective on the background.

there was quite a lot of discussion (without resolution) whether it's
reasonable for a flow that uses PCN adm ctrl to also want e2e ECN for
rate adaptation (discussion both in terms of whether a flow would
actually ever want this, and how well the PCN mechanism would work if
flows were adapting like this). 
this was resolved by saying that the support of e2e ecn is out of scope
of initial charter of pcn. 
this leaves the question: if/when after re-chartering the scope does
include e2e ecn, how would this impact pcn encoding choice (which we
have to make now)? 
The solution: 
- we know that if use (only) DSCPs for encoding PCN-marks, then e2e ECN
would be ok
- we know that if use ECN field for encoding PCN-marks, then e2e ECN
could be supported; the obvious way is to tunnel the flow over the
PCN-domain & to establish the tunnel as part of the signalling set-up
for this flow. 
- [rationale for the text at top of this email quoted from the I-D]: but
we haven't worked out the details for the tunnelling /signalling, so
let's give some very simple advice if the situation does occur. The best
thing seems to drop the pkt, as at least this means the receiver behaves
in the same way as if it got the ecn-marked pkt. If this is felt to be
unhelpful or misleading, we could instead say something about
signalling/tunnelling approach ['and details would be worked out after
re-chartering as appropriate..']

phil

---

From: Lars Eggert <[email-masked]>
Date: Wed, 28 Nov 2007 20:12:12 +0200

> of initial charter of pcn.

Huh? The charter says:

"Cleanly integrate" doesn't mean "out of scope", it means "must work  
together with".

TSVWG published RFC4774 to describe which alternate uses of the ECN  
bits are OK; the PCN mechanisms are supposed to instantiate such an  
accepted alternate use.

Lars