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

From: <[email-masked]>
Date: Fri, 11 Jul 2008 14:43:26 +0100

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 11 July 2008 14:43
To: Moncaster,T,Toby,CXR9 R
Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
Subject: New Version Notification for
draft-moncaster-pcn-baseline-encoding-02 

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

Filename:	 draft-moncaster-pcn-baseline-encoding
Revision:	 02
Title:		 Baseline Encoding and Transport of Pre-Congestion
Information
Creation_date:	 2008-07-11
WG ID:		 Independent Submission
Number_of_pages: 13

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
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.
Other documents describe extended encoding schemes that allow 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, 15 Jul 2008 10:30:11 +0100

Toby,

It looks good to me. Yes, I support it as wg doc.

Some comments:

S4.3:
Clarify that the context of the first bullet (PCN-ingress-node action if
pkt arrives with CE or ECT) is for packets that use the same DSCP as
PCN-traffic

S5:
"that traffic" -> "traffic that"

"ECN marked traffic is blocked from entering the PCN-domain directly"
2 things. First, the context is non-PCN-traffic using the same DSCP as
PCN-traffic. Second, ECN capable rather than ECN marked (or whatever
term includes ECT as well as CE)

4th bullet, All traffic -> All PCN-traffic

I think we need some minor work between the Tunnelling sections in the
encoding drafts, architecture draft & bob's Layered Encapsulation of
Congestion Notification,
http://www.ietf.org/internet-drafts/briscoe-tsvwg-ecn-tunnel-01.txt . i
don't think there's any real content that needs changing, just some
slight clarification. as i understand it, the encoding drafts summarises
how the behaviour of existing tunnelling encapsulators/decapsulators has
constrained the choice of encoding; the architecture draft summarises
what the 'right' behaviour for tunnelling encapsulators/decapsulators is
in a PCN-domain; and bob's draft adds a whole lot of detailed
explanation and history etc. 

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 11 July 2008 14:43
{ To: [email-masked]
{ Subject: [PCN] FW: New Version Notification fordraft-moncaster-pcn-
{ baseline-encoding-02
{ 
{ 
{ 
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:[email-masked]]
{ Sent: 11 July 2008 14:43
{ To: Moncaster,T,Toby,CXR9 R
{ Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
{ Subject: New Version Notification for
{ draft-moncaster-pcn-baseline-encoding-02
{ 
{ 
{ A new version of I-D, draft-moncaster-pcn-baseline-encoding-02.txt has
{ been successfuly submitted by T Moncaster and posted to the IETF
{ repository.
{ 
{ Filename:	 draft-moncaster-pcn-baseline-encoding
{ Revision:	 02
{ Title:		 Baseline Encoding and Transport of
Pre-Congestion
{ Information
{ Creation_date:	 2008-07-11
{ WG ID:		 Independent Submission
{ Number_of_pages: 13
{ 
{ 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
{ 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.
{ Other documents describe extended encoding schemes that allow 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: <[email-masked]>
Date: Tue, 15 Jul 2008 11:54:23 +0100

Thanks for the comments Phil. I will incorporate those changes in the
next version of the draft (which will hopefully be a WG item by then!). 

I agree there is a need for some clarification between the different
tunnelling sections. One possible way to do this would be to write a
complete ID (targeted to be informational) giving full details of the
current constraints of tunnelling, the correct way to deal with tunnels
inside a PCN-domain, the correct order in which to perform PCN actions
if the ingress or egress nodes are also tunnel encapsulators or
decapsulators and a brief explanation of what would be gained if all
tunnel behaviours were rationalised for both DSCP and ECN fields.

Toby 

> From: Eardley,PL,Philip,CXR9 R 
> Sent: 15 July 2008 10:30
> To: Moncaster,T,Toby,CXR9 R; [email-masked]
> Subject: RE: [PCN] FW: New Version Notification 
> fordraft-moncaster-pcn-baseline-encoding-02
> 
> Toby,
> 
> Clarify that the context of the first bullet 
> (PCN-ingress-node action if pkt arrives with CE or ECT) is 
> for packets that use the same DSCP as PCN-traffic
> 
> S5:
> 2 things. First, the context is non-PCN-traffic using the 
> same DSCP as PCN-traffic. Second, ECN capable rather than ECN 
> marked (or whatever term includes ECT as well as CE)
> 
> I think we need some minor work between the Tunnelling 
> sections in the encoding drafts, architecture draft & bob's 
> Layered Encapsulation of Congestion Notification, 
> http://www.ietf.org/internet-drafts/briscoe-tsvwg-ecn-tunnel-0
1.txt . i don't think there's any real content that needs > changing,
just some slight clarification. as i understand it, 
> the encoding drafts summarises how the behaviour of existing 
> tunnelling encapsulators/decapsulators has constrained the 
> choice of encoding; the architecture draft summarises what 
> the 'right' behaviour for tunnelling 
> encapsulators/decapsulators is in a PCN-domain; and bob's 
> draft adds a whole lot of detailed explanation and history etc. 
> 
> 
> { A new version of I-D, 
> draft-moncaster-pcn-baseline-encoding-02.txt has