Subject: [Tsvwg] comments on draft-davie-ecn-mpls-00

From: <[email-masked]>
Date: Fri, 4 Aug 2006 19:30:20 +0100

Bruce, all

Here are some comments on the MPLS-ECN draft, draft-davie-ecn-mpls-00.

Basically I think it's very good and agree with it, so these comments
are fairly minor. 

S1 - just some nits

way-side // wayside

pre-emption[I-D.briscoe-tsvwg-cl-architecture] // pre-emption
[I-D.briscoe-tsvwg-cl-architecture]

header[RFC3032] // header [RFC3032]

Section 8.) // Section 8).

S2 & elsewhere - mentions of PCN 

I agree with francois's comment to tsvwg ML [17jul] that "it is useful
that the ecn-mpls doc does discuss, as an example, how PCN requirements
could be met." Especially useful where it explains the motivation for
ecn-mpls (S2, 8.4 & maybe needs adding to S9). 

S2

1-[1+p(d-1)][1-p]^(d-1)

maybe show how derived it by expressing as

1 - [1-p]^d - dp([1-p]^(d-1))

don't really mind though. 

"While such an approach seemed potentially palatable for traditional
ECN"

doesn't your argument also make it unpalatable for any scheme that uses
marks to drive edge-to-edge domain feedback (such as [shayman])? (It's
more unpalatable with PCN as marking rates are higher.)

S4.3

If the buffer is full, the packet would be dropped. // If the buffer is
full, a packet is dropped.

S4.4

"If an MPLS-encapsulated packet crosses a Diffserv domain boundary"

could this DS boundary be the edge of a CL-region? (CL-region =
DS-region where PCN operating). 

If yes, then one side could be doing AM/PM/NM & the other side
CM/Non-CM. Translating between these isn't so obvious. Especially you
don't really want to copy AM to CM, as would expect the CL-region to
handle pre-congestion within the CL-region rather than by reacting to
ECN-marking end-to-end. 

Maybe best just to preclude this case?

S4.6 

"Assuming an IP packet was exposed"

I think need to repeat the S1.2 caveat about these MUSTs only applying
IF the MPLS congestion notification is copied into the IP header for
onward transmission, but this is NOT mandated 

S4.8.5

Again the S1.2 caveat is needed. In fact, I think should point out that
you wouldn't expect to do this copying - instead you'd use the
congestion-level-estimate feedback stuff of PCN's adm control mechanism
to react to these markings (and similarly react to Pre-emption Marks via
sustainable-aggregate-rate etc)

S9

1st para, suggested re-phrase:

What are the consequences of marking a packet that is not ECN-capable?
If it is dropped by the domain's egress LSR, haven't resources then been
consumed unnecessarily?

"The problem only arises if there is congestion downstream of an earlier
congested node." 
Also it only arises if you copy the marking into the IP header at the
egress LSR - it doesn't arise if you do shayman/pcn feedback.

I agree with the comparison of [ecn-mpls] and [floyd] marking.

S13.2

The [I-D.xxx] refs need updating for authors &, in case of
cl-architecture, title. And dates of course now out-of-date

Best wishes, 

phil

 

Philip Eardley

Networks Researcher

BT Group 

Phone:              +44 (0)1473 645938

Fax :                 +44 (0)1473 640929

Email:               [email-masked]
<mailto:[email-masked]> 

BT MeetMe:      +44 (0)870 241 2994 

Passcode:         16851189#

BT Group plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England and Wales no. 4190816   This electronic message
contains information from BT Group plc which may be privileged or
confidential. The information is intended to be for the use of the
individual(s) or entity named above. If you are not the intended
recipient be aware that any disclosure, copying, distribution or use of
the contents of this information is prohibited. If you have received
this electronic message in error, please notify us by telephone or email
(to the numbers or address above) immediately. Activity and use of the
BT Group plc E-mail system is monitored to secure its effective
operation and for other lawful business purposes. Communications using
this system will also be monitored and may be recorded to secure
effective operation and for other lawful business purposes.

---

From: Bruce Davie <[email-masked]>
Date: Tue, 8 Aug 2006 12:32:59 -0400

Phil,
  Thanks for the comments. Replies in line:

On Aug 4, 2006, at 2:30 PM, <[email-masked]>  
<[email-masked]> wrote:

> Basically I think it's very good and agree with it, so these  
> comments are fairly minor.
>
>
> S1 - just some nits
>
> way-side // wayside
>
> pre-emption[I-D.briscoe-tsvwg-cl-architecture] // pre-emption [I- 
> D.briscoe-tsvwg-cl-architecture]
>

No problem. Will fix in the next rev.

> I agree with francois's comment to tsvwg ML [17jul] that “it is  
> useful that the ecn-mpls doc does discuss, as an example, how PCN  
> requirements could be met.” Especially useful where it explains the  
> motivation for ecn-mpls (S2, 8.4 & maybe needs adding to S9).
>
>

I agree. My current plan is to make sure that we don't depend on the  
PCN drafts as normative references, while keeping useful informative  
references to PCN.

> don’t really mind though.

Seems reasonable.

>
> "While such an approach seemed potentially palatable for  
> traditional ECN"
>
> doesn’t your argument also make it unpalatable for any scheme that  
> uses marks to drive edge-to-edge domain feedback (such as  
> [shayman])? (It's more unpalatable with PCN as marking rates are  
> higher.)

First of all, note that there is a bug in the current draft:  
[Shayman] recommended the approach described here (use one bit for  
CE, worry about ECT on egress) not the approach of [Floyd] (use one  
codepoint for both CE and Not-ECT).

The current draft isn't making a broad statement about when the  
[Floyd] approach is or is not palatable; it's simply saying that we  
no longer recommend it because of the bad effects it has when marking  
rates are relatively high. I don't see a need for a change to the  
sentence you picked out above.

>
> S4.3
>
> If the buffer is full, the packet would be dropped. // If the  
> buffer is full, a packet is dropped.

Yes.

> could this DS boundary be the edge of a CL-region? (CL-region = DS- 
> region where PCN operating).
>
> If yes, then one side could be doing AM/PM/NM & the other side CM/ 
> Non-CM. Translating between these isn’t so obvious. Especially you  
> don’t really want to copy AM to CM, as would expect the CL-region  
> to handle pre-congestion within the CL-region rather than by  
> reacting to ECN-marking end-to-end.
>

Yes, I should clean up the text to say that we are talking about a DS  
domain boundary that is NOT the edge of a CL region.

Given our desire to avoid normative references to PCN, it might be  
best to put a statement earlier in the section to say that everything  
in Section 4 relates to ECN, which would then automatically preclude  
the case you mention.

> I think need to repeat the S1.2 caveat about these MUSTs only  
> applying IF the MPLS congestion notification is copied into the IP  
> header for onward transmission, but this is NOT mandated

Yes.

>
> S4.8.5
>
> Again the S1.2 caveat is needed. In fact, I think should point out  
> that you wouldn’t expect to do this copying - instead you'd use the  
> congestion-level-estimate feedback stuff of PCN's adm control  
> mechanism to react to these markings (and similarly react to Pre- 
> emption Marks via sustainable-aggregate-rate etc)

I agree with the caveat. You seem to be assuming however that the  
edge of the MPLS domain would coincide with the edge of the  CL- 
region, and I don't see any reason to assume that. We probably need  
to be explicit about the two cases (the edges do and do not coincide.)

> What are the consequences of marking a packet that is not ECN- 
> capable? If it is dropped by the domain’s egress LSR, haven’t  
> resources then been consumed unnecessarily?
>
> “The problem only arises if there is congestion downstream of an  
> earlier congested node.”
> Also it only arises if you copy the marking into the IP header at  
> the egress LSR - it doesn’t arise if you do shayman/pcn feedback.

OK.

> The [I-D.xxx] refs need updating for authors &, in case of cl- 
> architecture, title. And dates of course now out-of-date
>
>

xml2rfc will fix that.

Regards

Bruce

> Registered in England and Wales no. 4190816   This electronic  
> message contains information from BT Group plc which may be  
> privileged or confidential. The information is intended to be for  
> the use of the individual(s) or entity named above. If you are not  
> the intended recipient be aware that any disclosure, copying,  
> distribution or use of the contents of this information is  
> prohibited. If you have received this electronic message in error,  
> please notify us by telephone or email (to the numbers or address  
> above) immediately. Activity and use of the BT Group plc E-mail  
> system is monitored to secure its effective operation and for other  
> lawful business purposes. Communications using this system will  
> also be monitored and may be recorded to secure effective operation  
> and for other lawful business purposes.
>
>