Subject: [aqm] ECN use statement

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 5 Nov 2013 23:04:47 +0000

Hi,

In today's discussion it became apparent, that we might need a stronger statement around the expected use of the IP ECN signaling, and encourage future implementers to support this, and also agree around the way how ECN should be used.

I would like to encourage discussion around that interaction here on list...

Richard Scheffenegger

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 8 Nov 2013 20:22:02 +0000

On Nov 5, 2013, at 3:04 PM, "Scheffenegger, Richard" <[email-masked]> wrote:

> Hi,
>  
> In today’s discussion it became apparent, that we might need a stronger statement around the expected use of the IP ECN signaling, and encourage future implementers to support this, and also agree around the way how ECN should be used.
>  
> I would like to encourage discussion around that interaction here on list…

Part of the discussion, of course, should be exactly what words we want to say about it. Section 4.2.1 of draft-ietf-awm-recommendations is entirely on ECN, and in part says

   Network devices SHOULD use an AQM algorithm that marks ECN-capable
   traffic when making decisions about the response to congestion.
   Network devices need to implement this method by marking ECN-capable
   traffic or by dropping non-ECN-capable traffic.

Bob's comments this morning in tsvwg (which I wasn't present for but have been appraised of since) were in effect that ECN signals should be far more aggressive than loss signals. While loss is an effective signal, it also has QoE issues as identified in a separate thread, while ECN has no QoE impact. I have two views on that, diametrically opposed:

1) I wish everything would use ECN, so that we could achieve 100% utilization with statistically zero queuing delay and without loss.

2) Would that have the same effect as delay-based TCPs experience with respect to loss-based ones - they back out of the way too early? 

It would be good to get some experience on that.