Subject: [iccrg] Fwd: Review of draft-khademi-alternativebackoff-ecn-01.txt

From: Michael Welzl <[email-masked]>
Date: Thu, 8 Oct 2015 08:54:36 +0200

Dear all,

This message was sent to the ICCRG list yesterday but somehow didn’t make it through. We’re investigating why.

Cheers,
Michael

> Begin forwarded message:
> 
> From: Bob Briscoe <[email-masked]>
> Subject: Re: [iccrg] Review of draft-khademi-alternativebackoff-ecn-01.txt
> Date: 7. oktober 2015 kl. 15.19.12 CEST
> To: Michael WELZL <[email-masked]>
> Cc: <[email-masked]>
> Resent-From: <[email-masked]>
> 
> ICCRG chairs and list,
> 
> My main concern from reviewing the ABE I-D and paper is the justification logic.
> 
> I have paraphrased the authors' logic below:
> * The base RTT of a TCP flow might be greater than the RTT assumed in the configuration of an AQM on the path.
> * So, optimize TCP for the case when the RTT /is/ greater than that believed to be used in current AQMs
>  (but only when it's certain that there's an AQM at the bottleneck, which must be true if there's only CE not loss).
> 
> If the authors want to use a higher beta for ECN flows, I have no objection. But they shouldn't use this misguided logic to justify it.
> 
> Why optimize TCP for a greater RTT than that which AQM designers have assumed is most likely?
> * I think AQM designers chose these low RTTs because most traffic these days comes from CDNs, and therefore such low base RTTs are typical.
> * If the authors believe that typical base RTTs are higher, they ought to produce some evidence before asserting that standard TCP should be re-written around an assumption of higher RTTs.
> * If they really think the RTT that AQM designers chose was too small, they should just tell them. Why change TCP to try to correct an error of judgement in AQMs that are only just starting to be deployed? Even those that are already deployed can be reconfigured.
> 
> 
> 
> Anyway, TCP doesn't have to pick just one RTT to optimize against. Unlike an AQM, TCP knows its own RTT. So why not use a higher value of beta when TCP measures a higher RTT? Why use a higher value of beta whatever the RTT, when under-utilzation is only a problem with high RTT?
> 
> There are other problems with the justification logic, but IMO the above is the most critical.
> 
> Regards
> 
> 
> 
> Bob
> 
> On 22/09/15 12:34, Michael Welzl wrote:
>> <chair hat on - just sayin', because I'm also a co-author>
>> 
>> 
>> Dear all,
>> 
>> The proposal "TCP Alternative Backoff with ECN" (ABE) was presented to TCPM at the last IETF. Some comments were given there, and on the TCPM mailing list before the meeting ( see: https://mailarchive.ietf.org/arch/search/?email_list=tcpm&qdr=y&q=TCP+Alternative+Backoff+with+ECN  ).
>> The meeting concluded with this statement by a chair:
>> 
>> ***
>> Michael S: seems like a perfect topic for ICCRG. Can be discussed
>> there, clarify Mark Allman's proposal of binding beta to a loss
>> multiplication factor, see if it is applicable to more congestion
>> controls than just Reno. Coming up with a beta factor is in ICCRG's
>> scope.
>> ***
>> 
>> => now we're doing this evaluation on behalf of TCPM. As you can see below, the draft has just been updated. As usual for such evaluations, I also created a Wiki page for it:
>> http://wiki.tools.ietf.org/group/irtf/trac/wiki/ICCRG_abe
>> 
>> where you can, for now, find the draft, slides & minutes from Prague, and the technical report:
>> http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf
>> 
>> This is a short draft, so please consider reading it and offer your comments on the ICCRG mailing list. Thanks!!
>> 
>> Cheers,
>> Michael
>> 
>> 
>> 
>>> Begin forwarded message:
>>> 
>>> From: <[email-masked]>
>>> Subject: New Version Notification for draft-khademi-alternativebackoff-ecn-01.txt
>>> Date: 22 Sep 2015 13:08:45 CEST
>>> To: Michael Welzl <[email-masked]>, Grenville Armitage <[email-masked]>, Michael Welzl <[email-masked]>, Gorry Fairhurst <[email-masked]>, Naeem Khademi <[email-masked]>, Godred Fairhurst <[email-masked]>, Grenville Armitage <[email-masked]>, "Naeem Khademi" <[email-masked]>
>>> Resent-From: <[email-masked]>
>>> 
>>> 
>>> A new version of I-D, draft-khademi-alternativebackoff-ecn-01.txt
>>> has been successfully submitted by Michael Welzl and posted to the
>>> IETF repository.
>>> 
>>> Name:		draft-khademi-alternativebackoff-ecn
>>> Revision:	01
>>> Title:		TCP Alternative Backoff with ECN (ABE)
>>> Document date:	2015-09-21
>>> Group:		Individual Submission
>>> Pages:		10
>>> URL:            https://www.ietf.org/internet-drafts/draft-khademi-alternativebackoff-ecn-01.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-khademi-alternativebackoff-ecn/
>>> Htmlized:       https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-01
>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-khademi-alternativebackoff-ecn-01
>>> 
>>> Abstract:
>>>   This memo provides an experimental update to RFC3168.  It updates the
>>>   TCP sender-side reaction to a congestion notification received via
>>>   Explicit Congestion Notification (ECN).  ECN-marking can allow a
>>>   network device to signal congestion at a point before a transport
>>>   experiences congestion loss or additional queueing delay.  The
>>>   updated method is less conservative than the TCP reaction in response
>>>   to loss.  The intention is to achieve good throughput when the queue
>>>   at the bottleneck is smaller than the bandwidth-delay-product of the
>>>   connection.  This is more likely when an Active Queue Management
>>>   (AQM) mechanism has used ECN to CE-mark a packet, than when a packet
>>>   was lost.  Future versions of this document will discuss SCTP as well
>>>   as other transports using ECN.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>>> 
>> _______________________________________________
>> iccrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/iccrg
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>

---

From: grenville armitage <[email-masked]>
Date: Tue, 13 Oct 2015 11:34:32 +1100

Hi Bob,

>> Date: 7. oktober 2015 kl. 15.19.12 CEST
	[..]

I'll re-order things a little to address some common ground first:

>> If the authors want to use a higher beta for ECN flows, I have no objection.

Nice to start with a point of agreement ;-)

>> But they shouldn't use this misguided logic to justify it.

Perhaps not surprisingly, I disagree. More precisely, I disagree with your version of our reasoning. I'm still happy with the rationale articulated in https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-01 (and http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf).

To your questions...

	[..]
>> Why optimize TCP for a greater RTT than that which AQM designers have assumed is most likely?

I don't agree with that characterisation. Rather, ABE recognises that an existing tool (ECN) can let TCP detect, and compensate for, the case where an AQM-managed bottleneck would otherwise lead to poor performance.

>> * I think AQM designers chose these low RTTs because most traffic
>> these days comes from CDNs, and therefore such low base RTTs are
>> typical.

AQM designers might well consider low base RTTs to be 'typical'. And TCP connections will 'typically' work well when the base RTTs are a consequence of connections to local CDNs. But there's a bigger world out there. ABE is an incremental change to TCP that improves things when an AQM'd bottleneck might otherwise degrade things -- i.e. when connections are not limited to one's local CDNs.

>> * If the authors believe that typical base RTTs are higher, they
>> ought to produce some evidence

I'm biased -- my work desktop in Melbourne is a long way from most interesting places around the Internet:

[gja@garmitage] ~% ping -c 10 cisco.com
PING cisco.com (72.163.4.161): 56 data bytes
	[..]
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 206.837/208.044/210.559/1.304 ms
[gja@garmitage] ~%
[gja@garmitage] ~% ping -c 10 bbc.co.uk
PING bbc.co.uk (212.58.244.18): 56 data bytes
	[..]
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 299.367/299.576/300.040/0.237 ms
[gja@garmitage] ~%

I know, Australia's a long way from anyone, and we're probably not typical. But the truth is out there ;)

>> before asserting that standard TCP
>> should be re-written around an assumption of higher RTTs.

I agree with your aversion to rewriting TCP. Fortunately, our Linux and FreeBSD implementations of ABE were trivial tweaks to existing code paths.

>> * If they really think the RTT that AQM designers chose was too
>> small, they should just tell them.  Why change TCP to try to correct
>> an error of judgement in AQMs that are only just starting to be
>> deployed? Even those that are already deployed can be
>> reconfigured.

I'd phrase it this way: ABE lets AQMs do what they've been designed to do in the typical case. By simply relaxing TCP backoff when ECN-enabled flows see marks, ABE also produces the nice result that ECN-enabled TCP connections over long RTT paths wont be degraded as much as they would be otherwise.

>> Anyway, TCP doesn't have to pick just one RTT to optimize against.
>> Unlike an AQM, TCP knows its own RTT. So why not use a higher value
>> of beta when TCP measures a higher RTT? Why use a higher value of
>> beta whatever the RTT, when under-utilzation is only a problem with
>> high RTT?

Adding RTT sensitivity where it doesn't already exist would seem dangerously close to the sort of re-writing of TCP you eschew above.

TL;DR -- ABE introduces a trivial way to enhance the mutual benefit of ECN + AQM using code paths that already exist.

cheers,
gja

---

From: John Leslie <[email-masked]>
Date: Wed, 14 Oct 2015 14:35:49 -0400

grenville armitage <[email-masked]> wrote:
> Perhaps not surprisingly, I disagree. More precisely, I disagree with your 
> version of our reasoning. I'm still happy with the rationale articulated in 
> https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-01 (and 
> http://caia.swin.edu.au/reports/150710A/CAIA-TR-150710A.pdf).

   alternativebackoff starts from the idea that the backoff ratio is worth
experimenting with; and IMHO adequately supports that idea.

   I do support experimenting in this direction.

   I wouldn't call it "misguided logic," but I do think of the issue
differently than grenville. To me, all AQMs have to guess at the Bandwidth-
Delay-Product because they have no reasonable way to measure RTT. OTOH,
the sender can measure RTT quite precisely.

   Classic TCP (Reno) is based on a simple-minded theory -- that you drop
a packet when your buffer fills; and by the time that disturbance reaches
the sender, it's appropriate to cut the sending rate in half (details
available elsewhere).

   Modern AQMs are based on a theory that we can generate a signal earlier
than tail-drop; thus a gentler drop in sending rate would work nicely if
we could signal it. Alas: we saw no way to signal it at the time.

   But today we have modern AQMs that can generate ECN marks; and they
turn out to be essentially the _only_ source of ECN CE marks. Thus it
is obviously appropriate to apply a gentler correction factor when an
ECN-CE mark is detected than when a drop is detected.

   Alas, it's not yet clear "how much gentler"...

   Grenville et al have done experiments to hone in on "how much gentler".
This is good. This should continue.

   But we lack a theoretical basis for "how much gentler". :^( :^(

   I have tried to hint at a direction for "how much gentler".

   I theorize that we should model our AQMs to give a signal we can treat
as "arrival rate exceeds processing rate". (Obviously, any real AQM will
try to "de-noise" that signal to avoid signaling "too-short" periods when
this is true but unlikely to continue.)

   If we can consider an ECN-CE mark as such a signal, the right thing
to do is immediately drop our sending rate to slightly less what it was
when that signal was generated; and hold off on increasing our sending
rate for some multiple of the RTT. (This cannot be a fixed fraction of
current sending rate, regardless of RTT.)

   Using this paradigm, we could be more friendly to real-time traffic
(since if we haven't been probing for more capacity, we wouldn't have
to reduce sending rate at all for a single CE mark.)

   NB: It's premature to say exactly what we should do if CE marks
persist: I plead guilty to hand-waving in the "slightly" above...

>>> Why optimize TCP for a greater RTT than that which AQM designers have 

   Because the sender has a far better idea of what RTT actually is.

>>> these days comes from CDNs, and therefore such low base RTTs are

   Regardless, they're chosen in the absence of real-time measurments.

>>> ought to produce some evidence

   What would such evidence prove: obviously RTTs are sometimes higher
and sometimes lower...

> interesting places around the Internet:

   Yes, grenville's RTTs are often higher...

>>>should be re-written around an assumption of higher RTTs.

   I don't see that as the proposal at all.

   The proposal, as I understand it, is that the sender should use
information available to it (but not the AQM) to adjust based upon
actual RTTs.

> I agree with your aversion to rewriting TCP. Fortunately, our Linux and 
> FreeBSD implementations of ABE were trivial tweaks to existing code paths.

   This is strictly proposing to experiment. By the time we get around
to proposing "permanent" changes to TCP, it will probably look quite
different.

>>> deployed? Even those that are already deployed can be

   Sometimes the AQM will guess too small; sometimes too large.
Arguing what number to use sounds like bikeshedding to me...

>>> beta whatever the RTT, when under-utilzation is only a problem with

   Yes, the TCP sender knows its own RTT. Yes, the AQM doesn't.

   Yes, a higher value of beta_{ecn} makes sense for some values oF RTT,
and perhaps nonsense for others. This IMHO should become part of the
experiment.

--
John Leslie <[email-masked]>