Subject: [aqm] Draft Agenda for IETF89

From: "Scheffenegger, Richard" <[email-masked]>
Date: Thu, 13 Feb 2014 19:24:54 +0000

Hi,

The draft agenda for this IETF meeting in London has currently the following points.

Please let me know if you disagree with the ordering, length or anything else!

Best regards,

Richard Scheffenegger (aqm-chair)

*************************************************************************************

 AQM Agenda
 IETF 89 in London, United Kingdom
 Tuesday, March 4, 2013, 14:20-15:50 BST (Sovereign)
 ******************************************************

 WG status
 ---------

 14:20
 Agenda bashing
 AQM status
 Chairs
 10 min

 WG items
 --------

 14:30
 draft-ietf-aqm-recommendation
 Fred Baker / Gorry Fairhurst
 10 min

 Charter items
 -------------

 14:40
 draft-fairhurst-ecn-motivation
 Gorry Fairhurst
 15 min

 14:55
 draft-kuhn-aqm-eval-guidelines
 Nicolas Kuhn et. al.
 45 min

 if time permits:

 Algorithm Proposals
 -------------------

 15:40
 draft-lauten-aqm-gsp
 wolfram lautenschlaeger
 10 min

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Feb 2014 14:40:12 -0500

> Richard Scheffenegger (aqm-chair)

This is apparently not a published draft yet.

> draft-kuhn-aqm-eval-guidelines

I keep hoping for more discussion on the list.

> Algorithm Proposals

Nifty, got code?

>
>
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

---

From: Michael Welzl <[email-masked]>
Date: Sat, 15 Feb 2014 13:10:24 +0100

> This is apparently not a published draft yet.

It's draft-welzl-ecn-benefits,  http://tools.ietf.org/html/draft-welzl-ecn-benefits-00

Cheers,
Michael

---

From: Dave Taht <[email-masked]>
Date: Sun, 16 Feb 2014 14:35:57 -0500

On Sat, Feb 15, 2014 at 7:10 AM, Michael Welzl <[email-masked]> wrote:

> It's draft-welzl-ecn-benefits,
> http://tools.ietf.org/html/draft-welzl-ecn-benefits-00

It describes the benefits of ECN persuasively and well.

I would rather like a section discussing the negatives.

-- 
Dave Täht

---

From: Michael Welzl <[email-masked]>
Date: Mon, 17 Feb 2014 10:20:53 +0100

> It describes the benefits of ECN persuasively and well.

Thanks!!

> I would rather like a section discussing the negatives.

We point to one problem in the introduction:
   "Following a recommendation in
   [RFC3168], which says: "for a router, the CE codepoint of an ECN-
   Capable packet SHOULD only be set if the router would otherwise have
   dropped the packet as an indication of congestion to the end nodes",
   it has often been assumed that routers mark packets at the same level
   of congestion at which they would otherwise drop them (e.g. in
   [RFC2884]), but there are indications that this configuration is not
   ideal [KH13]."

With this configuration, which is a common default, e.g. also in Linux AFAIK, one sometimes gets more queue growth than without ECN because the very packets that an AQM mechanism marks with ECN don't free queue space (which they would do if they were dropped instead). However, even this disadvantage has to be put against the advantages that we tried to list, some of which can't be measured by looking at the delay of packets on the wire  (e.g., head-of-line blocking delay occurs in the receiver buffer).

Do you know about any other disadvantages?

Cheers,
Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 17 Feb 2014 14:40:28 +0000

Hi Michael, Gorry,

in section 3.2, you state that "it exposes the presence of
congestion". But ECN (on the IP layer) goes beyond that, and 
can expose not only the presence, but also the extent of congestion.

(It's just that very few transports have ways to carry that 
extent back to the sender - speaking as co-author of 
draft-kuehlewind-tcpm-accecn-reqs and 
draft-kuehlewind-tcpm-accurate-ecn).

> Do you know about any other disadvantages?

I think the biggest issue is the interaction between ECN and non-ECN flows (and packets; for TCP, only data segments are specified to optionally be ECN-enabled, not pure ACKs, and other control segments (some are allowed as experimental, i.e. SYN/ACK).

If ECN would have been seen as universally good (back in the day), it is odd that one L4 flow (TCP session) is constituted from both ECN- and non-ECN segments during it's lifetime.

The natural conclusion would be to assume that ECN on pure ACK, FIN, RST is detrimental in some way (personally I tend to disagree; there may not be any significant benefit, but it wouldn't break anything either - just the opposite, pure ACKs would serve as probes into the congestion state of the return path, once the data direction within the TCP flow reverses).

But these points are transport specific; 

However, guidance to transport protocol designers on the use of ECN with control segments etc seems like it could be in scope for this document?

In any case, to hash out the obvious, the interaction between ECN and non-ECN is complex and seen as potentially problematic. That may account for a real or perceived (depending on the AQM's use of ECN) problem with ECN...

Richard Scheffenegger (individual contributor)

> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]]
> Sent: Montag, 17. Februar 2014 10:21
> To: Dave Taht
> Cc: Scheffenegger, Richard; [email-masked]
> Subject: Re: [aqm] Draft Agenda for IETF89
> 
> 
> With this configuration, which is a common default, e.g. also in Linux
> AFAIK, one sometimes gets more queue growth than without ECN because the
> very packets that an AQM mechanism marks with ECN don't free queue space
> (which they would do if they were dropped instead). However, even this
> disadvantage has to be put against the advantages that we tried to list,
> some of which can't be measured by looking at the delay of packets on the
> wire  (e.g., head-of-line blocking delay occurs in the receiver buffer).
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 17 Feb 2014 14:41:58 +0000

Hi Michael,

Thanks for providing the correct draft name; I updated the agenda accordingly.

Richard Scheffenegger (co-chair).

Charter items
-------------

14:40

---

From: John Leslie <[email-masked]>
Date: Mon, 17 Feb 2014 12:46:26 -0500

Scheffenegger, Richard <[email-masked]> wrote:
> [Michael Welzl <[email-masked]> wrote:]
> 

   While I believe discussion of disadvantages would help, I see a more
fundamental question:

   "What modifications/extensions to RFC 3168 are appropriate to achieve
the benefits being discussed?"

   (Of course, RFCs 4301 and 6040 discuss handling of ECN in tunnels;
this much extension is hopefully a given.)

> I think the biggest issue is the interaction between ECN and non-ECN
> flows (and packets;

   I'm not quite sure what Richard means here -- there's an obvious
question about one starving the other (and I do think that's an issue,
but not quite a "disadvantage").

> for TCP, only data segments are specified to optionally be ECN-enabled,
> not pure ACKs, and other control segments (some are allowed as
> experimental, i.e. SYN/ACK).

   This is an obvious area for improvement; but I really can't see it as
a "disadvantage" of ECN.

> If ECN would have been seen as universally good (back in the day),
> it is odd that one L4 flow (TCP session) is constituted from both
> ECN- and non-ECN segments during it's lifetime.

   I don't see that as "odd" -- just "suboptimal".

> The natural conclusion would be to assume that ECN on pure ACK, FIN, RST
> is detrimental in some way (personally I tend to disagree; there may not
> be any significant benefit, but it wouldn't break anything either -
> just the opposite, pure ACKs would serve as probes into the congestion
> state of the return path, once the data direction within the TCP flow
> reverses).

   Again, an obvious area for improvement...

> But these points are transport specific; 

   Exactly! It makes very little sense to blame "ECN" for these issues.

> However, guidance to transport protocol designers on the use of ECN
> with control segments etc seems like it could be in scope for this
> document?

   I don't agree.

   The Abstract says:
" 
" This document describes the potential benefits to applications when
" they enable Explicit Congestion Notification (ECN).

which implies to me that it should discuss benefits regardless of the
particular transport protocol (and I think it does).

   The document describes setting the ECT(0) or ECT(1) codepoint in the
IP header and how routers may react to that. Not until Section 4 does
it mention particular transports; and IMHO those are listed strictly
as examples.

   I believe the document intentionally avoids questions about the
design of transport protocols; and I think it should continue to avoid
those.

   But the document _does_ mention several times the desirability of
ECN-marking packets which would not otherwise be dropped.

   I quite agree that is desirable; but it is a fundamental change to
RFC 3168; and I think we need to justify it considerably more than
this document does. This will not be a trivial change to deploy.

   It will indeed require deployment in routers and transport stacks,
but the question is quite independent of the transport _protocols_ --
and I strongly suggest we don't confuse the two.

--
John Leslie <[email-masked]>

---

From: [email-masked]
Date: Mon, 17 Feb 2014 21:28:15 -0000

> this much extension is hopefully a given.)
That's a good topic - but that's surely one for tsvwg if you are
suggesting a change to ECN.

> but not quite a "disadvantage").
I think maybe we are off-topic for the draft I was envisaging - which was
"what are all the things that ECN can offer to applications".

>    This is an obvious area for improvement; but I really can't see it as
I'm lost here too about the issue, unless you mean that packets may be
queued separately when ECN is enabled and this results in a flow being in
multiple queues - is that what you mean?

>    I don't see that as "odd" -- just "suboptimal".
Is this the same as above?

>> with control segments etc seems like it could be in scope for this
I think this is something that needs to be done when we update ECN -
should tsvwg decide to do this - my hope was that this ID would be useful
to people designing apps/networks - not transport protocol people.

> design of transport protocols; and I think it should continue to avoid
OK - that's what we were thinking.

> and I strongly suggest we don't confuse the two.
This probably lies in a different document - but that is not to say we
shouldn't progress the two ideas in parallel if both are good.

Gorry