Subject: RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it

From: [email-masked]
Date: Thu, 24 Nov 2005 23:55:26 -0000

more follow-up in-line
best wishes
phil
-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]]
Sent: Thu 24/11/2005 09:28
To: Eardley,PL,Philip,CXR9 R
Cc: [email-masked]; [email-masked]
Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP re-markingcan do it
 
Hi Phil

Please see in line!

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 24, 2005 1:23 AM
Subject: RE: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP 
re-markingcan do it

> hit send too early last time,
>
>>>What is the technical reason of using ECN for edge-toedge congestion 
>>>control?
> The use of Ecn seems natural to me, since we wnat the network to indicate 
> incipient congestion and that's what ECN is supposed to do. Note that the 
> semantics are the same as rfc3168 (ECN) - ie same codepoints of ECN field 
> and CE codepoint indicates incipient congestion. I also think it can help 
> with migration to a fully ecn world. As operators get experience of using 
> ecn, whilst not requiring all nws / end hosts to be using it.

Georgios: yes I understand but the ECN semantics apply end-to-end, not 
edge-toedge,
please see the previous discussions on this issue!

[phil] your original question was "why use edge-to-edge ECN re-marking when DSCP re-marking can do it". i think from your reply ["yes i understand"] you're saying that you agree edge-to-edge ECN re-marking is better than DSCP re-marking, providing your end-to-end concern is addressed. 

>
> Second, using DSCP re-marking seems to need a lot of DSCPs. According to 
> your draft, admission control implies 2 per traffic class (one for 
> re-marked pkts, one for other pkts passing thru the same router). Plus 
> another for the severe congestion indication. In addition, in the core 
> network an interesting future extension is to use the mechanisms in a 
> network with MPLS-TE (see our framework draft for brief discussion) - 
> there isnt sufficient space in the label for these extra dscps.

Georgios: regarding the number of DSCP's you are right, but there are ways
of reducing this number, please see the RMD draft.

[phil] actually i already took account of the reduction explained in the draft. which is that all 3 drop precedences of AF are re-marked to the same dscp. do you have any other suggestions how to reduce the number of dscps required?

Please also note that the streaming aplication example that has been 
discussed in
the tsvwg and nsis mailing lists shows that it is usefull to use
end-to-end ECN based congestion control for reserved traffic.

[phil] i dont think anyone answered louise's question - that excess traffic above the reservation level will be dropped or treated as best effort by an operator?

This streaming application example can very efficiently use RSVP and the
DCCP protocol (which uses the end-to-end ECN concept).

[phil] why do you mention dccp in particular? after all rfc3168 includes stuff about how to add ecn reactivity to tcp.

Please also note that the support of this type of this type of streaming 
application that
combines the end to end ECN semantics
with reserved minimum bandwidth is needed not only
in the backbone network but also in the wireless network as well.
Therefore the rate-adaptation function of ECN (DCCP functionality)
combined with minimum bandwidth reservation can be very important.

> Third, (as bob has pointed out) that it's easy to overcome the end-to-end 
> vs edge-to-edge
marking issue (if that's really needed, which I'm inclined to think it isnt)

Georgios: regarding this point I am not sure if it is easy! It depends on 
the
imposed additional complexity.

[phil] note that the additional complexity is at teh edge of the core network, where it should be ok (at least it's the point where complex things are done).
also, i think the migration point that i made in my previous email is very important. at present, even if both end terminals are ecn capable, the chances are that at least one of the networks in between isnt. how do we move to a situation where all the networks have deployed ecn? the edge-to-edge case provides a good reason for an operator to deploy ecn capability. so it makes it more likely that your end-to-end ecn case can happen - as people gain experience in ecn.

Best regards,
Georgios

>
> ________________________________
>
> From: [email-masked] on behalf of [email-masked]
> Sent: Wed 23/11/2005 23:48
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP 
> re-markingcan do it
>
>
>
> some comments below.
>
> best wishes, phil
>
> ________________________________
>
> *       To: <rbriscoe at jungle.bt.co.uk <mailto:[email-masked]> >
> *       Subject: [Tsvwg] why use edge-to-edge ECN re-marking when DSCP 
> re-marking can do it
> *       From: "Georgios Karagiannis" <karagian at cs.utwente.nl 
> <mailto:[email-masked]> >
> *       Date: Mon, 21 Nov 2005 10:52:22 +0100
> *       Cc: tsvwg at ietf.org <mailto:[email-masked]> , nsis at 
> ietf.org <mailto:[email-masked]>
>
> Hi Bob
>
> In addition to the previous discussion I would like to
> discuss and ask you the following.
>
> [chop]
> What is the technical reason of using ECN for edge-toedge congestion 
> control,
> when the same solution (on providing admission control
> based on congestion notification and severe
> congestion [pre-emption]) can be provided by using DSCP re-marking?
>
>
>
>
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
>
>
> 

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