Subject: [Tsvwg] Possibilities to make progress on the re-ECN work

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 21 Feb 2006 09:27:23 +0100

Dear Bob,

Sally Floyd mentioned that she "think(s) it is interesting, and has a fair amount of promise." I would appreciate if re-ECN work were to make progress within the TSV WG based on Sally's relatively positive judgement (that's how I perceive it, at least).

I'm a QoS expert and re-ECN is a promising attempt to keep backbone routers free of any reservation state. That's why I personally would appreciate if the work on re-ECN is continued within the TSV WG.

There's been another part of the discussion, which has been whether or not DSCPs could be used for re-ECN and whether or not re-ECN is superior to ECN. To me, re-ECN is a rather useful contribution based on what it may offer conceptually. I'm a bit worried that the discussion on the usage of DSCP's versus ECN codepoints and whether re-ECN is superior to todays ECN drains a lot of energy or may even put the whole re-ECN idea on hold (but maybe I'm too pessimistic here). I can't contribute much on that discussion, but I'd like to mention that my company operates an MPLS based backbone. The solution space for DiffServ and congestion related packet marking we discuss there is the three MPLS header EXP bits, I guess. Without some pragmatism, a transfer of any ECN mechanism to MPLS may be difficult. 

Best regards,

Rüdiger

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 21 Feb 2006 16:24:40 +0100

Bob,

thanks for pointing out, I correct my statement in line.

Regards, Rüdiger

|Rüdiger,
|
|Thanks for the supportive comments.
|
|I think there may be some confusion here with two ECN-related 
|items of work 
|we have in the Transport Area at the moment:
|i) Admission control over Diffserv using pre-congestion notification 
|<draft-briscoe-tsvwg-cl-architecture-01.txt>
|ii) Re-ECN: Adding Accountability for Causing Congestion to TCP/IP 
|<draft-briscoe-tsvwg-re-ecn-tcp-00.txt>
|
|I think you're using the term re-ECN for (i), when it applies 
|to something different defined in (ii). Can you just confirm 
|(perhaps cc the list)?

Sorry if I mixed up things. Then I'd like to correct myself and express 
the hope that discussions on Re-ECN don't have an influence on the 
progress of draft-briscoe-tsvwg-cl-architecture.

|Just to complicate matters, I am nearly finished writing a new 
|draft that extends i) using ii)! Or you could think of it as a 
|use-case of ii) applied to the scenario of i). It enables 
|admission control over multiple domains without per-flow policing 
|at borders, instead using re-ECN as a bulk anti-cheating mechanism 
|to prevent one network failing to admission control 
|traffic that is causing congestion in other people's networks.

Avoiding per flow policing at border routers is one of the most useful 
features of measurement based admission control applying on packet 
marking.

|Bob
|
|
|At 08:27 21/02/2006, Geib, Ruediger wrote:
|>Dear Bob,
|>
|>Sally Floyd mentioned that she "think(s) it is interesting, 
|and has a fair 
|>amount of promise." I would appreciate if re-ECN work were to make 
|>progress within the TSV WG based on Sally's relatively 
|positive judgement 
|>(that's how I perceive it, at least).
|>
|>I'm a QoS expert and re-ECN is a promising attempt to keep backbone 
|>routers free of any reservation state. That's why I personally would 
|>appreciate if the work on re-ECN is continued within the TSV WG.
|>
|>There's been another part of the discussion, which has been 
|whether or not 
|>DSCPs could be used for re-ECN and whether or not re-ECN is 
|superior to 
|>ECN. To me, re-ECN is a rather useful contribution based on 
|what it may 
|>offer conceptually. I'm a bit worried that the discussion on 
|the usage of 
|>DSCP's versus ECN codepoints and whether re-ECN is superior 
|to todays ECN 
|>drains a lot of energy or may even put the whole re-ECN idea 
|on hold (but 
|>maybe I'm too pessimistic here). I can't contribute much on that 
|>discussion, but I'd like to mention that my company operates 
|an MPLS based 
|>backbone. The solution space for DiffServ and congestion 
|related packet 
|>marking we discuss there is the three MPLS header EXP bits, I guess. 
|>Without some pragmatism, a transfer of any ECN mechanism to 
|MPLS may be 
|>difficult.
|>
|>Best regards,
|>
|>Rüdiger
|
|_______________________________________________________________
|_____________
|Bob Briscoe, <[email-masked]>      Networks Research 
|Centre, BT Research
|B54/130 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.   
|+44 1473 645196 
|
|