Subject: [PCN] FW: New Version Notification for draft-moncaster-pcn-baseline-encoding-01

From: <[email-masked]>
Date: Mon, 23 Jun 2008 18:12:00 +0100

Here is the latest revision to the baseline encoding document. Please
let me have any suggested changes by July 8th to give me time to upload
a further revision before Dublin.

Do people think this is in any state yet to request it to be considered
as a WG draft?

Toby
____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 23 June 2008 18:09
To: Moncaster,T,Toby,CXR9 R
Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
Subject: New Version Notification for
draft-moncaster-pcn-baseline-encoding-01 

A new version of I-D, draft-moncaster-pcn-baseline-encoding-01.txt has
been successfuly submitted by T Moncaster and posted to the IETF
repository.

Filename:	 draft-moncaster-pcn-baseline-encoding
Revision:	 01
Title:		 Baseline Encoding and Transport of Pre-Congestion
Information
Creation_date:	 2008-06-23
WG ID:		 Independent Submission
Number_of_pages: 12

Abstract:
Pre-congestion notification (PCN) provides information to support
admission control and flow termination in order to protect the
Quality of Service of inelastic flows.  It does this by marking
packets when traffic load on a link is approaching or has exceeded a
rate threshold below the physical link rate.  This document specifies
how such marks are to be encoded into the IP header.  The baseline
encoding described here provides for only two PCN encoding states.
Another document describes an extended encoding scheme that allows
for three encoding states.

Status

This memo is posted as an Internet-Draft with an intent to eventually
progress to standards track.

The IETF Secretariat.

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

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 11:45:02 +0100

Toby, all,

Quick comment: in section 4.3 :

PCN edge node behaviour compliant with the PCN baseline encoding:

   o  Any packets with the ECN field already marked as CE or ECT
      arriving at a PCN ingress node SHOULD be dropped or alternatively
      MAY be tunnelled through the PCN-domain.  They MUST NOT be
      admitted to the PCN-domain directly.

- downgrading also seems possible, ie setting DS codepoint to a lower
behaviour aggregate like best effort or assured forwarding
- suggest "SHOULD be dropped or downgraded" - not clear to me that one
is particularly preferable to the other
- agree with MAY tunnel - basically because it needs extra signalling
work

would be very interested in comments on this. currently am re-writing
the traffic conditioning section of draft-eardley-marking-behaviour.
This has a similar choice about what to do to out-of-profile traffic. My
current idea is simply to list the different possible actions that you
"may" take - ie follow the approach of RFC2475 (Diffserv architecture)

phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 23 June 2008 18:12
{ To: [email-masked]
{ Cc: [email-masked]
{ Subject: [PCN] FW: New Version Notification fordraft-moncaster-pcn-
{ baseline-encoding-01
{ 
{ 
{ Here is the latest revision to the baseline encoding document. Please
{ let me have any suggested changes by July 8th to give me time to
upload
{ a further revision before Dublin.
{ 
{ Do people think this is in any state yet to request it to be
considered
{ as a WG draft?
{ 
{ Toby
{ ____________________________________________________________________
{ Toby Moncaster, <[email-masked]> Networks Research Centre, BT
{ B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734
{ 
{ 
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:[email-masked]]
{ Sent: 23 June 2008 18:09
{ To: Moncaster,T,Toby,CXR9 R
{ Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
{ Subject: New Version Notification for
{ draft-moncaster-pcn-baseline-encoding-01
{ 
{ 
{ A new version of I-D, draft-moncaster-pcn-baseline-encoding-01.txt has
{ been successfuly submitted by T Moncaster and posted to the IETF
{ repository.
{ 
{ Filename:	 draft-moncaster-pcn-baseline-encoding
{ Revision:	 01
{ Title:		 Baseline Encoding and Transport of
Pre-Congestion
{ Information
{ Creation_date:	 2008-06-23
{ WG ID:		 Independent Submission
{ Number_of_pages: 12
{ 
{ Abstract:
{ Pre-congestion notification (PCN) provides information to support
{ admission control and flow termination in order to protect the
{ Quality of Service of inelastic flows.  It does this by marking
{ packets when traffic load on a link is approaching or has exceeded a
{ rate threshold below the physical link rate.  This document specifies
{ how such marks are to be encoded into the IP header.  The baseline
{ encoding described here provides for only two PCN encoding states.
{ Another document describes an extended encoding scheme that allows
{ for three encoding states.
{ 
{ Status
{ 
{ This memo is posted as an Internet-Draft with an intent to eventually
{ progress to standards track.
{ 
{ 
{ 
{ 
{ The IETF Secretariat.
{ 
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 24 Jun 2008 13:57:01 +0200

Hi

I have one comment to section 4.3
>      admitted to the PCN-domain directly.
Sounds reasonable. One issue however that I don't understand is where
the decision to do tunneling is made. With my limited knowledge about IP
tunneling I understand that PCN ingress determines that the flow is ECT
or ECN-CE, then applies tunneling and signals to the PCN egress about
this. What protocols are defined for this (or is it outside the scope of
the current charter?). Does tunneling of ECN enabled flows need a
separate section ?

>   o  On leaving the PCN-domain the ECN bits MUST be set to 00 (Not
>      ECT).
If the tunneling approach (for ECT flows) is used, my understanding is
that the ECN bits should not be set to zero at PCN egress as these
contain ECN-CE and ECT already set before PCN ingress.

Regards
Ingemar

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: den 23 juni 2008 19:12
> To: [email-masked]
> Cc: [email-masked]
> Subject: [PCN] FW: New Version Notification 
> fordraft-moncaster-pcn-baseline-encoding-01
> 
> 
> Here is the latest revision to the baseline encoding 
> document. Please let me have any suggested changes by July 
> 8th to give me time to upload a further revision before Dublin.
> 
> Do people think this is in any state yet to request it to be 
> considered as a WG draft?
> 
> Toby
> Toby Moncaster, <[email-masked]> Networks Research 
> Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 
> 1473 648734 
> 
>

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 14:22:29 +0100

Tunnelling seems to be one of the areas we still need to do more work
in... See inline

Toby

> From: Ingemar Johansson S [mailto:[email-masked]] 
> Sent: 24 June 2008 12:57
> To: Moncaster,T,Toby,CXR9 R; [email-masked]
> Subject: RE: [PCN] FW: New Version Notification 

This is outside the scope of this document. Not sure if it is in scope
for the charter. Mechanisms are needed to find the egress node anyway
and setting up a tunnel is one solution to that (which also avoids the
ECMP issue completely). 

> contain ECN-CE and ECT already set before PCN ingress.

You would need to wite things carefully such that the PCN egress action
is performed first (e.g. reset any marked packets to not-ECT). Then
simply discard the outer header and keep the inner header unchanged.
This would not be quite what is defined in any current tunnleing
standard. Perhaps the solution to all this is for someone (not me!) to
write a document about tunneling and PCN (there is some mention in the
architecture document but that doesn't go into this level of detail).

> > A new version of I-D, 
> draft-moncaster-pcn-baseline-encoding-01.txt has

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 14:36:26 +0100

Perhaps this should actually say:

Any packet with the ECN field already marked as CE or ECT arriving at a
PCN ingress node SHOULD be dropped or downgraded to a lower class.
Alternatively it MAY be tunnelled through the PCN-domain if mechanisms
exist to preserve the mark at the PCN-egress node. A future document may
describe such a mechanism but this is beyond the scope of this document.
Such packets MUST NOT be admitted to the PCN-domain directly.

There is currently a slight issue about what would happen when a packet
is decapsulated if its outer header is set to not ECT and its inner
header carries either ECT or CE. This is best addressed in a separate
document (although it could go in as an appendix in this document
initially).

Toby

> From: Eardley,PL,Philip,CXR9 R 
> Sent: 24 June 2008 11:45
> - downgrading also seems possible, ie setting DS codepoint to 
> a lower behaviour aggregate like best effort or assured forwarding
> - suggest "SHOULD be dropped or downgraded" - not clear to me 
> that one is particularly preferable to the other
> - agree with MAY tunnel - basically because it needs extra 
> signalling work
> 
> would be very interested in comments on this. currently am 
> re-writing the traffic conditioning section of 
> draft-eardley-marking-behaviour. This has a similar choice 
> about what to do to out-of-profile traffic. My current idea 
> is simply to list the different possible actions that you 
> { let me have any suggested changes by July 8th to give me 
> time to upload
> { Do people think this is in any state yet to request it to 
> be considered
> { as a WG draft?
> { 
> { Toby
> { A new version of I-D,

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 14:48:44 +0100

Your wording sounds ok to me.

Another place to mention the 'slight issue' might be the architecture
draft, as that already has a section that discusses tunnelling
(hopefully quite carefully!)

phil

{ -----Original Message-----
{ From: Moncaster,T,Toby,CXR9 R
{ Sent: 24 June 2008 14:36
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]'
{ Subject: RE: [PCN] FW: New Version Notification
fordraft-moncaster-pcn-
{ baseline-encoding-01
{ 
{ 
{ Perhaps this should actually say:
{ 
{ Any packet with the ECN field already marked as CE or ECT arriving at
a
{ PCN ingress node SHOULD be dropped or downgraded to a lower class.
{ Alternatively it MAY be tunnelled through the PCN-domain if mechanisms
{ exist to preserve the mark at the PCN-egress node. A future document
may
{ describe such a mechanism but this is beyond the scope of this
document.
{ Such packets MUST NOT be admitted to the PCN-domain directly.
{ 
{ There is currently a slight issue about what would happen when a
packet is
{ decapsulated if its outer header is set to not ECT and its inner
header
{ carries either ECT or CE. This is best addressed in a separate
document
{ (although it could go in as an appendix in this document initially).
{ 
{ Toby
{ 
{ > -----Original Message-----
{ > From: Eardley,PL,Philip,CXR9 R
{ > Sent: 24 June 2008 11:45
{ > To: Moncaster,T,Toby,CXR9 R; [email-masked]
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] FW: New Version Notification
{ > fordraft-moncaster-pcn-baseline-encoding-01
{ >
{ > Toby, all,
{ >
{ > Quick comment: in section 4.3 :
{ >
{ > PCN edge node behaviour compliant with the PCN baseline encoding:
{ >
{ >    o  Any packets with the ECN field already marked as CE or ECT
{ >       arriving at a PCN ingress node SHOULD be dropped or
{ > alternatively
{ >       MAY be tunnelled through the PCN-domain.  They MUST NOT be
{ >       admitted to the PCN-domain directly.
{ >
{ > - downgrading also seems possible, ie setting DS codepoint to
{ > a lower behaviour aggregate like best effort or assured forwarding
{ > - suggest "SHOULD be dropped or downgraded" - not clear to me
{ > that one is particularly preferable to the other
{ > - agree with MAY tunnel - basically because it needs extra
{ > signalling work
{ >
{ > would be very interested in comments on this. currently am
{ > re-writing the traffic conditioning section of
{ > draft-eardley-marking-behaviour. This has a similar choice
{ > about what to do to out-of-profile traffic. My current idea
{ > is simply to list the different possible actions that you
{ > "may" take - ie follow the approach of RFC2475 (Diffserv
architecture)
{ >
{ > phil
{ >
{ > { -----Original Message-----
{ > { From: [email-masked] [mailto:[email-masked]] On
{ > Behalf Of
{ > { [email-masked]
{ > { Sent: 23 June 2008 18:12
{ > { To: [email-masked]
{ > { Cc: [email-masked]
{ > { Subject: [PCN] FW: New Version Notification
fordraft-moncaster-pcn-
{ > { baseline-encoding-01
{ > {
{ > {
{ > { Here is the latest revision to the baseline encoding
{ > document. Please
{ > { let me have any suggested changes by July 8th to give me
{ > time to upload
{ > { a further revision before Dublin.
{ > {
{ > { Do people think this is in any state yet to request it to
{ > be considered
{ > { as a WG draft?
{ > {
{ > { Toby
{ > {
____________________________________________________________________
{ > { Toby Moncaster, <[email-masked]> Networks Research Centre,
BT
{ > { B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734
{ > {
{ > {
{ > { -----Original Message-----
{ > { From: IETF I-D Submission Tool [mailto:[email-masked]]
{ > { Sent: 23 June 2008 18:09
{ > { To: Moncaster,T,Toby,CXR9 R
{ > { Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
{ > { Subject: New Version Notification for
{ > { draft-moncaster-pcn-baseline-encoding-01
{ > {
{ > {
{ > { A new version of I-D,
{ > draft-moncaster-pcn-baseline-encoding-01.txt has
{ > { been successfuly submitted by T Moncaster and posted to the IETF
{ > { repository.
{ > {
{ > { Filename:	 draft-moncaster-pcn-baseline-encoding
{ > { Revision:	 01
{ > { Title:		 Baseline Encoding and Transport of
{ > Pre-Congestion
{ > { Information
{ > { Creation_date:	 2008-06-23
{ > { WG ID:		 Independent Submission
{ > { Number_of_pages: 12
{ > {
{ > { Abstract:
{ > { Pre-congestion notification (PCN) provides information to support
{ > { admission control and flow termination in order to protect the
{ > { Quality of Service of inelastic flows.  It does this by marking
{ > { packets when traffic load on a link is approaching or has exceeded
a
{ > { rate threshold below the physical link rate.  This document
{ > specifies
{ > { how such marks are to be encoded into the IP header.  The baseline
{ > { encoding described here provides for only two PCN encoding states.
{ > { Another document describes an extended encoding scheme that allows
{ > { for three encoding states.
{ > {
{ > { Status
{ > {
{ > { This memo is posted as an Internet-Draft with an intent to
{ > eventually
{ > { progress to standards track.
{ > {
{ > {
{ > {
{ > {
{ > { The IETF Secretariat.
{ > {
{ > {
{ > { _______________________________________________
{ > { PCN mailing list
{ > { [email-masked]
{ > { https://www.ietf.org/mailman/listinfo/pcn
{ >
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 25 Jun 2008 10:44:22 +0200

Hi

I believe quite some uncertanity is related to how these ECN bits are
treated at PCN ingress and how tunneling would solve this, esp. in the
light of the discussion around tunneling constraints mentioned in
Appendix A in
http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt
It would be good to know if the e2e ECN issue can actually be solved in
a good way using tunneling and if so how it could be done. Question is
probably, who will do the dirty job..

Regards
/Ingemar

> From: [email-masked] [mailto:[email-masked]] 
> Sent: den 24 juni 2008 15:22
> To: Ingemar Johansson S; [email-masked]
> Tunnelling seems to be one of the areas we still need to do 
> more work in... See inline
> 
> Toby
> 
> > the decision to do tunneling is made. With my limited 
> knowledge about 
> > IP tunneling I understand that PCN ingress determines that 
> the flow is 
> > ECT or ECN-CE, then applies tunneling and signals to the PCN egress 
> > about this. What protocols are defined for this (or is it 
> outside the 
> > scope of the current charter?). Does tunneling of ECN enabled flows 
> > need a separate section ?
> 
> This is outside the scope of this document. Not sure if it is 
> in scope for the charter. Mechanisms are needed to find the 
> egress node anyway and setting up a tunnel is one solution to 
> that (which also avoids the ECMP issue completely). 
> 
> > 
> You would need to wite things carefully such that the PCN 
> egress action is performed first (e.g. reset any marked 
> packets to not-ECT). Then simply discard the outer header and 
> keep the inner header unchanged.
> This would not be quite what is defined in any current 
> tunnleing standard. Perhaps the solution to all this is for 
> someone (not me!) to write a document about tunneling and PCN 
> (there is some mention in the architecture document but that 
> doesn't go into this level of detail).
> 
> > Regards
> > Ingemar
> > 
> > 
> > 
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of [email-masked]
> > > Here is the latest revision to the baseline encoding document. 
> > > Please let me have any suggested changes by July 8th to 
> give me time 
> > > to upload a further revision before Dublin.
> > > 
> Centre, BT

---

From: <[email-masked]>
Date: Wed, 25 Jun 2008 09:52:17 +0100

Hi

I think toby, Michael, bob have worked well through the non-tunnelling
case for ecn/pcn. where the work is more limited is the tunnelling case
(we know how the solution might look, but the details eg of the
signalling are unknown). My feeling is that we should concentrate on
finishing properly the non-tunnelled case - get one thing done before
trying to do another.

phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Ingemar Johansson S
{ Sent: 25 June 2008 09:44
{ To: Moncaster,T,Toby,CXR9 R; [email-masked]
{ Subject: Re: [PCN] FW: New Version Notificationfordraft-moncaster-pcn-
{ baseline-encoding-01
{ 
{ Hi
{ 
{ I believe quite some uncertanity is related to how these ECN bits are
{ treated at PCN ingress and how tunneling would solve this, esp. in the
{ light of the discussion around tunneling constraints mentioned in
{ Appendix A in
{ http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt
{ It would be good to know if the e2e ECN issue can actually be solved
in
{ a good way using tunneling and if so how it could be done. Question is
{ probably, who will do the dirty job..
{ 
{ Regards
{ /Ingemar
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]]
{ > Sent: den 24 juni 2008 15:22
{ > To: Ingemar Johansson S; [email-masked]
{ > Subject: RE: [PCN] FW: New Version Notification
{ > fordraft-moncaster-pcn-baseline-encoding-01
{ >
{ >
{ > Tunnelling seems to be one of the areas we still need to do
{ > more work in... See inline
{ >
{ > Toby
{ >
{ > > -----Original Message-----
{ > > From: Ingemar Johansson S
[mailto:[email-masked]]
{ > > Sent: 24 June 2008 12:57
{ > > To: Moncaster,T,Toby,CXR9 R; [email-masked]
{ > > Cc: [email-masked]
{ > > Subject: RE: [PCN] FW: New Version Notification
{ > > fordraft-moncaster-pcn-baseline-encoding-01
{ > >
{ > > Hi
{ > >
{ > > I have one comment to section 4.3
{ > > >   o  Any packets with the ECN field already marked as CE or ECT
{ > > >      arriving at a PCN ingress node SHOULD be dropped or
{ > > alternatively
{ > > >      MAY be tunnelled through the PCN-domain.  They MUST NOT be
{ > > >      admitted to the PCN-domain directly.
{ > > Sounds reasonable. One issue however that I don't
{ > understand is where
{ > > the decision to do tunneling is made. With my limited
{ > knowledge about
{ > > IP tunneling I understand that PCN ingress determines that
{ > the flow is
{ > > ECT or ECN-CE, then applies tunneling and signals to the PCN
egress
{ > > about this. What protocols are defined for this (or is it
{ > outside the
{ > > scope of the current charter?). Does tunneling of ECN enabled
flows
{ > > need a separate section ?
{ >
{ > This is outside the scope of this document. Not sure if it is
{ > in scope for the charter. Mechanisms are needed to find the
{ > egress node anyway and setting up a tunnel is one solution to
{ > that (which also avoids the ECMP issue completely).
{ >
{ > >
{ > > >   o  On leaving the PCN-domain the ECN bits MUST be set to 00
(Not
{ > > >      ECT).
{ > > If the tunneling approach (for ECT flows) is used, my
{ > understanding is
{ > > that the ECN bits should not be set to zero at PCN egress as these
{ > > contain ECN-CE and ECT already set before PCN ingress.
{ > >
{ >
{ > You would need to wite things carefully such that the PCN
{ > egress action is performed first (e.g. reset any marked
{ > packets to not-ECT). Then simply discard the outer header and
{ > keep the inner header unchanged.
{ > This would not be quite what is defined in any current
{ > tunnleing standard. Perhaps the solution to all this is for
{ > someone (not me!) to write a document about tunneling and PCN
{ > (there is some mention in the architecture document but that
{ > doesn't go into this level of detail).
{ >
{ > > Regards
{ > > Ingemar
{ > >
{ > >
{ > >
{ > > > -----Original Message-----
{ > > > From: [email-masked] [mailto:[email-masked]]
{ > On Behalf
{ > > > Of [email-masked]
{ > > > Sent: den 23 juni 2008 19:12
{ > > > To: [email-masked]
{ > > > Cc: [email-masked]
{ > > > Subject: [PCN] FW: New Version Notification
{ > > > fordraft-moncaster-pcn-baseline-encoding-01
{ > > >
{ > > >
{ > > > Here is the latest revision to the baseline encoding document.
{ > > > Please let me have any suggested changes by July 8th to
{ > give me time
{ > > > to upload a further revision before Dublin.
{ > > >
{ > > > Do people think this is in any state yet to request it to be
{ > > > considered as a WG draft?
{ > > >
{ > > > Toby
{ > > >
{ > ____________________________________________________________________
{ > > > Toby Moncaster, <[email-masked]> Networks Research
{ > Centre, BT
{ > > > B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44
{ > > > 1473 648734
{ > > >
{ > > >
{ > > > -----Original Message-----
{ > > > From: IETF I-D Submission Tool [mailto:[email-masked]]
{ > > > Sent: 23 June 2008 18:09
{ > > > To: Moncaster,T,Toby,CXR9 R
{ > > > Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
{ > > > Subject: New Version Notification for
{ > > > draft-moncaster-pcn-baseline-encoding-01
{ > > >
{ > > >
{ > > > A new version of I-D,
{ > > draft-moncaster-pcn-baseline-encoding-01.txt has
{ > > > been successfuly submitted by T Moncaster and posted to the IETF
{ > > > repository.
{ > > >
{ > > > Filename:	 draft-moncaster-pcn-baseline-encoding
{ > > > Revision:	 01
{ > > > Title:		 Baseline Encoding and Transport of
{ > > > Pre-Congestion
{ > > > Information
{ > > > Creation_date:	 2008-06-23
{ > > > WG ID:		 Independent Submission
{ > > > Number_of_pages: 12
{ > > >
{ > > > Abstract:
{ > > > Pre-congestion notification (PCN) provides information to
support
{ > > > admission control and flow termination in order to protect the
{ > > > Quality of Service of inelastic flows.  It does this by marking
{ > > > packets when traffic load on a link is approaching or has
{ > exceeded a
{ > > > rate threshold below the physical link rate.  This document
{ > > specifies
{ > > > how such marks are to be encoded into the IP header.  The
{ > baseline
{ > > > encoding described here provides for only two PCN encoding
states.
{ > > > Another document describes an extended encoding scheme
{ > that allows
{ > > > for three encoding states.
{ > > >
{ > > > Status
{ > > >
{ > > > This memo is posted as an Internet-Draft with an intent to
{ > > eventually
{ > > > progress to standards track.
{ > > >
{ > > >
{ > > >
{ > > >
{ > > > The IETF Secretariat.
{ > > >
{ > > >
{ > > > _______________________________________________
{ > > > PCN mailing list
{ > > > [email-masked]
{ > > > https://www.ietf.org/mailman/listinfo/pcn
{ > > >
{ > >
{ >
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 25 Jun 2008 10:07:09 +0100

Hi,

Definitely agree with Phil here. Would love to volunteer to try and sort
this out but am unlikely to have enough time. I know Bob wants to do
some work on trying to rationalise all the different tunnel behaviours
and how they treat the DSCP and ECN fields on encapsulation and on
decapsulation so perhaps he's the one for this job...

Toby

> Sent: 25 June 2008 09:52
> To: 'Ingemar Johansson S'; Moncaster,T,Toby,CXR9 R; [email-masked]
> Subject: RE: [PCN] FW: New Version 
> Notificationfordraft-moncaster-pcn-baseline-encoding-01
> 
> Hi
> 
> I think toby, Michael, bob have worked well through the 
> non-tunnelling case for ecn/pcn. where the work is more 
> limited is the tunnelling case (we know how the solution 
> might look, but the details eg of the signalling are 
> unknown). My feeling is that we should concentrate on 
> finishing properly the non-tunnelled case - get one thing 
> done before trying to do another.
> 
> phil
> 
> { It would be good to know if the e2e ECN issue can actually 
> be solved in
> { > > ECT or ECN-CE, then applies tunneling and signals to 
> the PCN egress
> { > > scope of the current charter?). Does tunneling of ECN 
> enabled flows
> { > > >   o  On leaving the PCN-domain the ECN bits MUST be 
> set to 00 (Not
> { > > >      ECT).
> { > > > Pre-congestion notification (PCN) provides 
> information to support
> { > > > encoding described here provides for only two PCN 
> encoding states.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 25 Jun 2008 11:20:43 +0200

Ingemar,
 
| Definitely agree with Phil here.

I too agree with Phil on this issue.

Regards,

Rudiger

| > -----Original Message-----
| > From: Eardley,PL,Philip,CXR9 R
| > Sent: 25 June 2008 09:52
| > To: 'Ingemar Johansson S'; Moncaster,T,Toby,CXR9 R; [email-masked]
| > Subject: RE: [PCN] FW: New Version
| > Notificationfordraft-moncaster-pcn-baseline-encoding-01
| > 
| > Hi
| > 
| > I think toby, Michael, bob have worked well through the non-tunnelling 
| > case for ecn/pcn. where the work is more limited is the tunnelling 
| > case (we know how the solution might look, but the details eg of the 
| > signalling are unknown). My feeling is that we should concentrate on 
| > finishing properly the non-tunnelled case - get one thing done before 
| > trying to do another.
| > 
| > phil
| > 
| > { -----Original Message-----
| > { From: [email-masked] [mailto:[email-masked]] 
| On Behalf 
| > Of { Ingemar Johansson S { Sent: 25 June 2008 09:44 { To: 
| > Moncaster,T,Toby,CXR9 R; [email-masked] { Subject: Re: [PCN] FW: New 
| > Version
| > Notificationfordraft-moncaster-pcn-
| > { baseline-encoding-01
| > {
| > { Hi
| > {
| > { I believe quite some uncertanity is related to how these ECN bits 
| > are { treated at PCN ingress and how tunneling would solve 
| this, esp. 
| > in the { light of the discussion around tunneling constraints 
| > mentioned in { Appendix A in { 
| > http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt
| > { It would be good to know if the e2e ECN issue can 
| actually be solved 
| > in { a good way using tunneling and if so how it could be done.
| > Question is
| > { probably, who will do the dirty job..
| > {
| > { Regards
| > { /Ingemar
| > {
| > { > -----Original Message-----
| > { > From: [email-masked] [mailto:[email-masked]] { > 
| > Sent: den 24 juni 2008 15:22 { > To: Ingemar Johansson S; 
| [email-masked] 
| > { > Subject: RE: [PCN] FW: New Version Notification { > 
| > fordraft-moncaster-pcn-baseline-encoding-01
| > { >
| > { >
| > { > Tunnelling seems to be one of the areas we still need to do { > 
| > more work in... See inline { > { > Toby { > { > > -----Original 
| > Message----- { > > From: Ingemar Johansson S 
| > [mailto:[email-masked]]
| > { > > Sent: 24 June 2008 12:57
| > { > > To: Moncaster,T,Toby,CXR9 R; [email-masked] { > > Cc: 
| > [email-masked] { > > Subject: RE: [PCN] FW: New Version 
| > Notification { > > fordraft-moncaster-pcn-baseline-encoding-01
| > { > >
| > { > > Hi
| > { > >
| > { > > I have one comment to section 4.3
| > { > > >   o  Any packets with the ECN field already marked as 
| > CE or ECT
| > { > > >      arriving at a PCN ingress node SHOULD be dropped or
| > { > > alternatively
| > { > > >      MAY be tunnelled through the PCN-domain.  They 
| > MUST NOT be
| > { > > >      admitted to the PCN-domain directly.
| > { > > Sounds reasonable. One issue however that I don't { > 
| understand 
| > is where { > > the decision to do tunneling is made. With 
| my limited { 
| > > knowledge about { > > IP tunneling I understand that PCN ingress 
| > determines that { > the flow is { > > ECT or ECN-CE, then applies 
| > tunneling and signals to the PCN egress { > > about this. What 
| > protocols are defined for this (or is it { > outside the { 
| > > scope 
| > of the current charter?). Does tunneling of ECN enabled flows { > > 
| > need a separate section ?
| > { >
| > { > This is outside the scope of this document. Not sure if 
| it is { > 
| > in scope for the charter. Mechanisms are needed to find the 
| { > egress 
| > node anyway and setting up a tunnel is one solution to { > 
| that (which 
| > also avoids the ECMP issue completely).
| > { >
| > { > >
| > { > > >   o  On leaving the PCN-domain the ECN bits MUST be 
| > set to 00 (Not
| > { > > >      ECT).
| > { > > If the tunneling approach (for ECT flows) is used, my { > 
| > understanding is { > > that the ECN bits should not be set 
| to zero at 
| > PCN egress as these { > > contain ECN-CE and ECT already set before 
| > PCN ingress.
| > { > >
| > { >
| > { > You would need to wite things carefully such that the PCN { > 
| > egress action is performed first (e.g. reset any marked { > 
| packets to 
| > not-ECT). Then simply discard the outer header and { > keep 
| the inner 
| > header unchanged.
| > { > This would not be quite what is defined in any current { > 
| > tunnleing standard. Perhaps the solution to all this is for { > 
| > someone (not me!) to write a document about tunneling and PCN { > 
| > (there is some mention in the architecture document but that { > 
| > doesn't go into this level of detail).
| > { >
| > { > > Regards
| > { > > Ingemar
| > { > >
| > { > >
| > { > >
| > { > > > -----Original Message-----
| > { > > > From: [email-masked] 
| [mailto:[email-masked]] { > 
| > On Behalf { > > > Of [email-masked] { > > > Sent: 
| den 23 juni 
| > 2008 19:12 { > > > To: [email-masked] { > > > Cc: 
| > [email-masked] { > > > Subject: [PCN] FW: New Version 
| > Notification { > > > fordraft-moncaster-pcn-baseline-encoding-01
| > { > > >
| > { > > >
| > { > > > Here is the latest revision to the baseline 
| encoding document.
| > { > > > Please let me have any suggested changes by July 8th to { > 
| > give me time { > > > to upload a further revision before Dublin.
| > { > > >
| > { > > > Do people think this is in any state yet to request 
| it to be { 
| > > > > considered as a WG draft?
| > { > > >
| > { > > > Toby
| > { > > >
| > { >
| > ____________________________________________________________________
| > { > > > Toby Moncaster, <[email-masked]> Networks 
| Research { > 
| > Centre, BT { > > > B54/70 Adastral Park, Ipswich, IP53RE, 
| UK.  +44 { > 
| > > > 1473 648734 { > > > { > > > { > > > -----Original 
| Message----- { > 
| > > > From: IETF I-D Submission Tool 
| [mailto:[email-masked]] { > 
| > > > Sent: 23 June 2008 18:09 { > > > To: 
| Moncaster,T,Toby,CXR9 R { > > 
| > > Cc: Briscoe,RJ,Bob,CXR9 R; 
| [email-masked] { > > > 
| > Subject: New Version Notification for { > > > 
| > draft-moncaster-pcn-baseline-encoding-01
| > { > > >
| > { > > >
| > { > > > A new version of I-D,
| > { > > draft-moncaster-pcn-baseline-encoding-01.txt has { > > > been 
| > successfuly submitted by T Moncaster and posted to the IETF { > > > 
| > repository.
| > { > > >
| > { > > > Filename:	 draft-moncaster-pcn-baseline-encoding
| > { > > > Revision:	 01
| > { > > > Title:		 Baseline Encoding and Transport of
| > { > > > Pre-Congestion
| > { > > > Information
| > { > > > Creation_date:	 2008-06-23
| > { > > > WG ID:		 Independent Submission
| > { > > > Number_of_pages: 12
| > { > > >
| > { > > > Abstract:
| > { > > > Pre-congestion notification (PCN) provides information to 
| > support { > > > admission control and flow termination in order to 
| > protect the { > > > Quality of Service of inelastic flows.  It does 
| > this by marking { > > > packets when traffic load on a link is 
| > approaching or has { > exceeded a { > > > rate threshold below the 
| > physical link rate.  This document { > > specifies { > > > how such 
| > marks are to be encoded into the IP header.  The { > 
| baseline { > > > 
| > encoding described here provides for only two PCN encoding states.
| > { > > > Another document describes an extended encoding scheme { > 
| > that allows { > > > for three encoding states.
| > { > > >
| > { > > > Status
| > { > > >
| > { > > > This memo is posted as an Internet-Draft with an 
| intent to { > 
| > > eventually { > > > progress to standards track.
| > { > > >
| > { > > >
| > { > > >
| > { > > >
| > { > > > The IETF Secretariat.
| > { > > >
| > { > > >
| > { > > > _______________________________________________
| > { > > > PCN mailing list
| > { > > > [email-masked]
| > { > > > https://www.ietf.org/mailman/listinfo/pcn
| > { > > >
| > { > >
| > { >
| > { _______________________________________________
| > { PCN mailing list
| > { [email-masked]
| > { https://www.ietf.org/mailman/listinfo/pcn
| > 
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 27 Jun 2008 13:03:13 +0200

Hi

I accept your conclusion, especially as I don't have the time to delve
too deeply into this myself. Thanks anyway for the consideration.

/Ingemar 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: den 25 juni 2008 10:52
> To: Ingemar Johansson S; [email-masked]; [email-masked]
> { From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of { Ingemar Johansson S { Sent: 25 June 2008 09:44 { 
> To: Moncaster,T,Toby,CXR9 R; [email-masked] { Subject: Re: 
> [PCN] FW: New Version Notificationfordraft-moncaster-pcn-
> { baseline-encoding-01
> {
> { Hi
> {
> { I believe quite some uncertanity is related to how these 
> ECN bits are { treated at PCN ingress and how tunneling would 
> solve this, esp. in the { light of the discussion around 
> tunneling constraints mentioned in { Appendix A in { 
> be solved in { a good way using tunneling and if so how it 
> could be done. Question is { probably, who will do the dirty job..
> {
> { Regards
> { /Ingemar
> {
> { > From: [email-masked] 
> [mailto:[email-masked]] { > Sent: den 24 juni 2008 
> 15:22 { > To: Ingemar Johansson S; [email-masked] { > Subject: 
> RE: [PCN] FW: New Version Notification { > 
> { > Tunnelling seems to be one of the areas we still need to 
> do { > more work in... See inline { > { > Toby { > { > > 
> -----Original Message----- { > > From: Ingemar Johansson S 
> { > > To: Moncaster,T,Toby,CXR9 R; [email-masked] { > > Cc: 
> [email-masked] { > > Subject: RE: [PCN] FW: New 
> Version Notification { > > fordraft-moncaster-pcn-baseline-encoding-01
> { > >
> { > > Hi
> { > >
> { > > Sounds reasonable. One issue however that I don't { > 
> understand is where { > > the decision to do tunneling is 
> made. With my limited { > knowledge about { > > IP tunneling 
> I understand that PCN ingress determines that { > the flow is 
> the PCN egress { > > about this. What protocols are defined 
> for this (or is it { > outside the { > > scope of the current 
> charter?). Does tunneling of ECN enabled flows { > > need a 
> separate section ?
> { >
> { > This is outside the scope of this document. Not sure if 
> it is { > in scope for the charter. Mechanisms are needed to 
> find the { > egress node anyway and setting up a tunnel is 
> one solution to { > that (which also avoids the ECMP issue 
> completely).
> { >
> { > >
> { > > If the tunneling approach (for ECT flows) is used, my { 
> > understanding is { > > that the ECN bits should not be set 
> to zero at PCN egress as these { > > contain ECN-CE and ECT 
> already set before PCN ingress.
> { > >
> { >
> { > egress action is performed first (e.g. reset any marked { 
> > packets to not-ECT). Then simply discard the outer header 
> and { > keep the inner header unchanged.
> { > This would not be quite what is defined in any current { 
> { > someone (not me!) to write a document about tunneling and 
> PCN { > (there is some mention in the architecture document 
> but that { > doesn't go into this level of detail).
> { >
> { > > Regards
> { > > Ingemar
> { > >
> { > >
> { > >
> { > > > From: [email-masked] 
> [mailto:[email-masked]] { > On Behalf { > > > Of 
> [email-masked] { > > > Sent: den 23 juni 2008 19:12 { 
> > > > To: [email-masked] { > > > Cc: [email-masked] 
> { > > > Subject: [PCN] FW: New Version Notification { > > > 
> { > > > Please let me have any suggested changes by July 8th 
> to { > give me time { > > > to upload a further revision 
> before Dublin.
> { > > >
> { > > > Do people think this is in any state yet to request 
> it to be { > > > considered as a WG draft?
> { > > >
> { > > > Toby
> { > > >
> { > 
> { > > > Toby Moncaster, <[email-masked]> Networks 
> Research { > Centre, BT { > > > B54/70 Adastral Park, 
> Ipswich, IP53RE, UK.  +44 { > > > 1473 648734 { > > > { > > > 
> { > > > -----Original Message----- { > > > From: IETF I-D 
> Submission Tool [mailto:[email-masked]] { > > > Sent: 
> 23 June 2008 18:09 { > > > To: Moncaster,T,Toby,CXR9 R { > > 
> > Cc: Briscoe,RJ,Bob,CXR9 R; 
> [email-masked] { > > > Subject: New 
> Version Notification for { > > > 
> { > > draft-moncaster-pcn-baseline-encoding-01.txt has { > > 
> > been successfuly submitted by T Moncaster and posted to the 
> IETF { > > > repository.
> { > > >
> information to support { > > > admission control and flow 
> termination in order to protect the { > > > Quality of 
> Service of inelastic flows.  It does this by marking { > > > 
> packets when traffic load on a link is approaching or has { > 
> exceeded a { > > > rate threshold below the physical link 
> rate.  This document { > > specifies { > > > how such marks 
> are to be encoded into the IP header.  The { > baseline { > > 
> { > > > Another document describes an extended encoding 
> scheme { > that allows { > > > for three encoding states.
> { > > >
> { > > > Status
> { > > >
> { > > > This memo is posted as an Internet-Draft with an 
> intent to { > > eventually { > > > progress to standards track.
> { > > >
> { > > >
> { > > >
> { > > >