Subject: Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG item

From: [email-masked]
Date: Mon, 5 Feb 2007 00:17:03 +0100

Bruce Davie <[email-masked]>
26/01/2007 14:38
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     [email-masked]
        Subject:        Re: [Tsvwg] Making draft-davie-ecn-mpls a TSVWG 
item

On Jan 25, 2007, at 7:07 PM, [email-masked] 
wrote:

> lars -
>
> i am more generally questioning cost/perf. gain & value for 3
> major reasons (they would deserve imho further discussion - or
> at least further proof of evidence)
>
> o) if it is to come up with a forwarding paradigm that becomes
> equivalent to IP probably we should then start questioning the
> need for MPLS itself (in part. in the present case focusing on
> intra-domain operations where i always thought that data-traffic
> and resource-oriented perf. objectives were taken into account
> for edge-to-edge MPLS path provisioning)

I think the need for MPLS is to support capabilities like VPNs and 
constraint-based routing. Giving MPLS the ability to support Diffserv 
(as was done in RFC3240) did not take away the need for VPNs or 
constraint-based routing. It simply enabled an operator to deploy 
MPLS to gain the extra capabilities of MPLS, without giving up the 
ability to do Diffserv. The same reasoning applies here: we want to 
allow an operator to deploy MPLS for the purposes of VPNs, TE, etc., 
without forcing him to give up the ability to do ECN. Of course, an 
operator who has no interest in ECN can leave this functionality 
disabled, just as RFC3270 functionality can be disabled for those 
operators who don't care for it.

In short, adding more capabilities to MPLS does not negate the 
advantages that MPLS brings.

[dp] that's not the point, you assume that CN is needed hence MPLS
we should incorporate, my point is if the TE mechanisms and the
related operations to MPLS-TE are not enough, then, one should 
question their real value and why not just stay w/ the pure-IP 
only techniques that are already delivering the goodies required,
indeed, this comes very close to the argument that MPLS is simply
becoming useless

> o) MPLS paradigm assumed "intelligence@edges" we progressively
> enter into a mode where intermediate LSRs will become (see end
> of section 3) progressively require/result again more selective
> processing of traffic
>

I'm not at all convinced that view is universally held. The task of 
assigning packets to FECs is indeed done at the edges, but I don't 
believe there is a grand principle that says MPLS core devices must 
do nothing other than forward packets based on the label. In fact, as 
one of the people who  designed the MPLS shim header, I can say that 
the reason for reserving the 3 "EXP" bits was to allow for queueing 
treatment to be applied to packets independent of the label. That is 
exactly what both RFC3270 and this mpls-ecn draft do with those bits.

[dp] i don't think i stated that label value independent queuing 
shall not be possible on intermediate nodes, the question is why
is there a value to put more functionality on these nodes ? what
i see is that we are lacking proven arguments in that direction

> o) initial MPLS-ECN based its reasoning on expectations from
> experience - quoting:
>
> "We believe the benefits from ECN of better overall performance
> for a wide range of applications because of reduced packet loss
> (especially those using non-TCP transports) and reduced queueing
> delay is sufficiently significant. Furthermore, there seems to
> be no reasons for LSRs to lack this capability as it becomes
> available in other (non-label switched) IP routers."
>
> it would have been interesting to sustain the reasoning with
> more tangible proofs - with the underlying question are we here
> waiting for this doc. to make such experiment possible ?

It is certainly true that ECN has yet to be proven to be universally 
useful. That is one reason why the draft goes to some lengths to 
specify this as optional behavior. But I can't see what bad thing 
will happen if TSVWG starts working on an MPLS ECN draft now. If 
proven utility is the standard that we have to reach before embarking 
on a working group draft, then a lot of work at the IETF should be 
stopped now.

[dp] the point is to come at least with one good thing shared by
the whole community - unique reason to put a functionality present
at a higher level down the stack -

Bruce

>
> much thanks,
> - d.
>
>
>
>
>
>
> <[email-masked]>
> 18/01/2007 11:49
>
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     [email-masked]
>         Subject:        RE: [Tsvwg] Making draft-davie-ecn-mpls a 
> TSVWG
> item
>
>
> < Attachment smime.p7s removed >
>
>
> Dimitri,
>
>> discussion was led on the list mid november - no real
>> conclusion or action where derived from the concerns
>> expressed at that time
>
> thanks for pointing out that this draft was also discussed elsewhere!
>
> As for your specific points:
>
>>> 1. CN marking in the EXP bits of the MPLS header falls imho under
> the
>>> MPLS change process that states for an optional problem statement
> and
>>> a mandatory prior requirements statement I-D to commit for any
>>> specific change or extension to MPLS
>>>
>>> see section 2.1.1 and 4.2 of
>>>
> <http://www.ietf.org/internet-drafts/draft-andersson-rtg-gmpls- 
> change-06
> .txt>
>
> The process described in that document isn't official procedure 
> yet, and
> has raised significant concern in parts of the IESG. IMO it is 
> unlikely
> to proceed without major changes. Hence, it's questionable that we
> should apply it here and now.
>
>> [dp] the same section 7 mentions
>>
>> "[RFC3168] does not give any reasons against conveying CE information
>>  from the inner header to the outer in the "full functionality" 
>> mode."
>>
>> nor the other way around - which leaves the point open for ECN itself
>> -> the issue i am raising is that in absence of evidence current the
>> processing should be left per RFC3168 and not inline with the 
>> expected
>> PCN needs (even if it does not affect the former)
>
> I'm not quite sure I understand your point - are you saying that the
> benefits of ECN for MPLS are unclear?
>
> Thanks,
> Lars
> --
> NEW EMAIL: [email-masked]
> NEW MOBILE: +358 50 48 24461
> NEW JABBER: [email-masked]
>
>
>
> <smime.p7s>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 05 Feb 2007 19:23:37 +0000

Dimitri,

I think I now understand your concerns from your latest posting, and 
hopefully can reassure you...

You are concerned that we shouldn't have to put a function into a lower 
layer (MPLS) that is already in a higher layer (IP). In most cases I would 
agree with you. Usually a request to do something goes from upper layer to 
a lower layer. So if IP offers some function and the transport or app asks 
IP to do it, it should just do it.

But ECN is the response, not the request. It's a message that travels 
upwards, not downwards. It enrichens the response from the lower layers to 
a request to forward a packet. Instead of the response being inferred from 
"delivered" or "lost", ECN adds the ability for the lower layers to say, 
"delivered but congestion approaching". Then we don't have to have drop in 
order to manage congestion. (Yes, TE also manages congestion without drop, 
but there are good reasons why ECN is far simpler for fine-grained 
per-microflow control.)

This congestion information is about physical resource depletion. Therefore 
it effectively rises up through the layers from the very bottom (physical). 
Indeed, congestion information has to continue to rise up the layers above 
the transport in some cases (e.g. HTTP's "server busy" at the app layer).

Many link technologies are simply point to point, so the IP layer can 
sufficiently model congestion of these simple links using the length of its 
queue into the link. But they are the exception, not the rule.

Other link layer technologies can involve blocking - where there is a layer 
2 network, not just a point-to-point link. For instance an ethernet or MPLS 
switched network. Or a shared wireless link.

If an MPLS switch becomes congested, we want to allow it to say "delivered 
but congestion approaching" upwards to the layers above. If there's nowhere 
to say this in the MPLS shim, the MPLS switch has to say it in the IP 
header. I don't want MPLS switches to have to understand IP. The 
appropriate place to say this is in the MPLS shim. (Similarly, the IEEE 
have activities to add ECN to ethernet switches for the same reason.)

---------
On the more general point concerning MPLS switches having to do more 
complicated stuff, the idea of adding ECN is so they have to do less. The 
idea is to use the ultra-simple AQM algorithms like RED to ship congestion 
information from LSRs to the edge of the network where more complicated 
fine-grained per-microflow rate control can be done. Either by the 
end-points (as in TCP-ECN), or perhaps by edge boxes (as in PCN admission 
control).

OK, MPLS-ECN joins a line of functions that MPLS switches might "do in 
order that they can do less". E.g. Diffserv was added on the same promise. 
So this begins to sound like a suspicious excuse... But it may reassure you 
that, back in 2002, I wrote that only three protocol building blocks are 
necessary and sufficient to provide QoS:
1) a signalling protocol (e.g. RSVP)
2) per-packet class of service tags (DSCP)
3) per-packet congestion notification (ECN)
The list still stands at 3 items in 2007 and I don't expect it to increase 
any further.

Anyway, each vendor can choose whether it adds ECN. (I wouldn't buy from 
one that didn't though!)

So I can assure you we've carefully thought about how this /should/ be done 
architecturally. We're not just adding kludges.

Are you reassured enough to allow ECN-MPLS to become a WG item?

Summaries of the above responding to each of your points inline...

>Bruce Davie <[email-masked]>

ECN is for info to travel upwards through all layers from the very bottom 
of the stack.

>i see is that we are lacking proven arguments in that direction

ECN is an ultra-simple addition to LSRs that ships congestion info out to 
where the complex rate control is done at the edges, reducing the need for 
complex fine-grained (per-flow) QoS functions on LSRs.

>at a higher level down the stack -

One good reason: In order for endpoints to manage congestion per flow 
without /requiring/ drop, you need ultra-simple AQM algorithms at any lower 
layer forwarding function that could block without the higher layers being 
aware.

Cheers

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196