Subject: [aqm] Status after the IETF

From: Martin Stiemerling <[email-masked]>
Date: Thu, 8 Aug 2013 16:37:03 +0200

Dear all,

Just to let you know that the AQM BOF proposal is now in the datatracker 
for the IESG's internal review, i.e., it is a proposed WG by now:
https://datatracker.ietf.org/doc/charter-ietf-aqm/

You can find the current proposed charter and milestones in the 
datatracker page.

Regards,

   Martin

-- 
IETF Transport Area Director

[email-masked]

NEC Laboratories Europe
NEC Europe Limited
Registered Office:
Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB
Registered in England 2832014

---

From: John Leslie <[email-masked]>
Date: Thu, 8 Aug 2013 18:02:32 -0400

> https://datatracker.ietf.org/doc/charter-ietf-aqm/

   I note desideratum (2):
" 
" help flow sources control their sending rates without unnecessary losses,
" e.g. through ECN

   Is this just "motherhood and apple pie" or is there an intent to allow
alternatives/modifications to ECN which _wouldn't_ be rejected by nearly
all operators?

--
John Leslie <[email-masked]>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Fri, 9 Aug 2013 08:58:53 +0000

Hi John,

this was shortly discussed. If you are thinking about changing the semantics of ECN, a different signaling scheme for congestion, etc, that would be considered out-of-scope for the AQM WG (TSVWG would be the place to take this).

However, an AQM utilizing such a modification / extension to the congestion signaling would be in-charter, but any draft with such a dependency would probably take a long time to pass... So, the charter doesn't explicitly exclude this, but at this point, it's hard to envision a combined ECN modification / AQM scheme that could find fast support.

After all, there are many kinds of different signaling / AQM schemes one can come up with, if designing on a green field...

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John
> Leslie
> Sent: Freitag, 09. August 2013 00:03
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: Re: [aqm] Status after the IETF
> 
> > Just to let you know that the AQM BOF proposal is now in the
> > datatracker for the IESG's internal review, i.e., it is a proposed WG by
> now:
> " help flow sources control their sending rates without unnecessary
> losses, " e.g. through ECN
> 
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: John Leslie <[email-masked]>
Date: Fri, 9 Aug 2013 12:47:29 -0400

Scheffenegger, Richard <[email-masked]> wrote:
> To: John Leslie <[email-masked]>
> 	<[email-masked]>
> 
>>    I note desideratum (2):
>> "
>> " losses, " e.g. through ECN
>> 
> this was shortly discussed. If you are thinking about changing the
> semantics of ECN, a different signaling scheme for congestion, etc,
> that would be considered out-of-scope for the AQM WG (TSVWG would be
> the place to take this).

   No doubt... but what is this language doing in an AQM charter, then?

> However, an AQM utilizing such a modification / extension to the
> congestion signaling would be in-charter, but any draft with such
> a dependency would probably take a long time to pass...

   Sounds like you're recommending against this, absent a recharter...

> So, the charter doesn't explicitly exclude this, but at this point,
> it's hard to envision a combined ECN modification / AQM scheme that
> could find fast support.

   Define "fast"...

> After all, there are many kinds of different signaling / AQM schemes
> one can come up with, if designing on a green field...

   Actually, there's no need for a "green field": anything a forwarding
node does is so far de-coupled from what a transport sender does as to
really belong in separate standards.

   The fatal problem with the ECN standard is that it tries to combine
what a node does with what a transport does.

   (The problem created by
] 
] ... MUST be essentially the same as the congestion control response
] to a *single* dropped packet

is a lesser problem, more easily corrected.)

   ECN as described in RFC 3168 has been un-deployable since day one:
because the transport can't know what forwarding nodes may do, and
forwarding nodes can't know what the transport may do.

   Folks have dutifully implemented it, both in transports and in
forwarding stacks, but have found themselves forced to turn it off
by default.

   To be deployable, we need something where forwarding nodes have
no reason to worry what transports may do with it.

   Likewise, transports must be allowed to guess at what forwarding
nodes mean by it.

   The essential point of ECN is that it's _explicit_ -- thus it
requires only one RTT to get back to the sender.

   "So what?" too many folks ask when I say that. :^(

   Anything that comes back _faster_ than you can infer a drop gives
better information -- thus, it _should_ allow a faster but less
drastic response.

   Generic TCP starts in "slow-start" mode, with an obviously-bad
guess for an Initial Window, increasing that each time an ACK is
received. Thus, it turns out to be exponential growth in _time_.
This is _bad_! It nearly guarantees overshoot by a factor of two
when a loss has to be inferred.

   OTOH, we now have real-time flows -- what AQM is being chartered
to consider -- that have no desire to grow exponentially. They need
to co-exist with large-transfer TCP sessions which are happy to
grow exponentially.

   The signal a transport _wants_ from forwarding nodes is that
we've reached the time at which exponential growth of sending rate
deserves to stop. (Obviously, we can't receive it at the same
moment; but a transport has enough information to make a good
guess at what that moment corresponds to in its sending history.)

   The reaction to such a signal should be to stop the exponential
growth and cut the sending rate back to where it was when the
signal was generated. For bulk-transfer TCP, this would be a bit
higher than the current algorithm; but for a real-time stream it
might be almost no reduction.

   The necessary _and_ sufficient change to ECN for forwarding
nodes is that the ECN signal be given _before_ packets need to be
dropped -- it really doesn't have to be _much_ before. Granted,
3168 explicitly forbids that now; but so long as the actual
behavior is documented, any TCP stack can compensate -- and in
many cases, no significant compensation is needed.

   Once the forwarding stacks signal ECN _before_ drop, all worries
about senders using ECN to game the system (at forwarding nodes)
disappear.

====

   Why am I posting this here, instead of in TSVVG? Simply,
because it needs to be considered by people who _care_!

   But beyond that, I believe the work of modifying ECN needs to
be _done_ by people who care -- and this looks to be the place to
find them.

   I am willing to lobby Martin and Spencer; and I'm willing to
run interference when the charter goes to External Review. The
first question needs to be "Is this worth doing?" rather than
"How do we make folks deploy it?"

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 26 Aug 2013 10:25:37 +0000

Hi group,

we, the BoF chairs, have asked for a tentative slot for AQM, assuming that AQM will be chartered as a WG by the time of IETF88. Our responsible AD did start the necessary preparations already!

At this time, this is just a heads-up. To plan a proper slot, we'd like to encourage early feedback.

Best regards,

Richard Scheffenegger