Subject: [aqm] questions for draft-welzl-ecn-benefits

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Fri, 23 May 2014 09:40:48 +0800

Hi Michael and Gorry,
 
I am following the ECN progress at IETF, and heard your presentation for draft-welzl-ecn-benefits in London. I am highly interested in this topic.
 
As you might know that 3GPP had long completed ECN specification for audio/video service on the base station for congestion notification over the wireless link, but there is few experience in real practice. I am therefore interested in your draft and would like to see how it may help us with cellular scenario.

In particular, I believe the following questions regarding complications on ECN enabling from the network side are also relevant to this draft. 

1, There are various middle-boxes along the end-to-end path where ECN signal is supposed to be communicated but actually partitioned at the middle-boxes. What are your recommendations regarding these boxes would also be part of the conclusion. For instance, TCP/HTTP/RTP proxy.

2, Tunnels, where end-to-end congestion status is separated in different headers and need to be combined or dropped at the tunnel exit. For example, GRE/IPSec tunneling.

3, Deployment considerations, it is somehow related to the first two, do we have to assume a unified deployment of consistent end-to-end ECN behavior in order to achieve the optimal gain? If so, the above issues need to be addressed. Otherwise, how can one choose between end-to-end and hop-by hop?

Looking forward to your reply and thanks in advance.

Regards,

Lingli

---

From: Michael Welzl <[email-masked]>
Date: Fri, 23 May 2014 10:18:06 +0200

Hi,

Thanks for your interest! More below:

> 1, There are various middle-boxes along the end-to-end path where ECN signal is supposed to be communicated but actually partitioned at the middle-boxes. What are your recommendations regarding the…

Such boxes terminate TCP connections,right? So you can have ECN for each of them, influencing each congestion controller separately; in other words, I don't think you need to do anything special for these boxes.

> 2, Tunnels, where end-to-end congestion status is separated in different headers and need to be combined or dropped at the tunnel exit. For example, GRE/IPSec tunneling.

There is draft-briscoe-tsvwg-ecn-encap-guidelines

> 3, Deployment considerations, it is somehow related to the first two, do we have to assume a unified deployment of consistent end-to-end ECN behavior in order to achieve the optimal gain? If so, th…

If ECN is ignored by non-supportive systems (as they should), ECN only needs to operate at the bottleneck. This actually makes for a nice deployment situation in principle, given that the bottleneck is often the access link.  There are, of course, other deployment issues with ECN, and they are discussed at length in various recent and not-so-recent papers. I think citing them and discussing the current state of things briefly in this draft could be a good idea.

Cheers,
Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 23 May 2014 12:07:28 +0000

[as individual]

Hi Lingli,

If you mean by „unified deployment” that you need similar AQM schemes with the same parameters/goals, then no;

For ECN to achieve its goal (provided the end hosts are reactive), only the marking probability needs to be roughly proportional to the level of congestion. If a path has multiple congestion points at different levels, the ECN marks will indicate the appropriate end-to-end congestion level that path should react upon. So, deploying AQM with entirely different behaviour (ie. one to keep queue sojourn time down, and another that simply tries to keep the queue length slightly below maximum) is just fine.

There are other aspects – in the end hosts – that should be improved upon, though. Not all transports feature granular enough feedback mechanisms, and not all transports support granular responses to varying levels of ECN feedback. Having consistency there is important.