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

From: grenville armitage <[email-masked]>
Date: Wed, 7 Oct 2015 09:04:22 +1100

Hi Michael,

On 09/22/2015 22:25, Scharf, Michael (Michael) wrote:
> <chair hat off - just sayin', because of the context>
>
> IMHO it would be good to run some sanity checks with HW switches or
> routers. HW switches (and in particular MPLS/IP routers) may have an
> internal buffer architecture that can be quite different to a
> Linux/FreeBSD machine, e.g., with several dynamically sized
> buffers/queues (e.g., ingress and/or egress), two-rate or three-rate
> rate policers, multiple (W)RED slopes, hierarchical schedulers, et
> al. I think there are Ethernet switches that support ECN and that
> could be used for such experiments - provided somebody has access to
> HW.
>
> Personally, I don't expect big surprises, and I doubt that a yet
> another comprehensive test study is needed. But it would be good to
> know whether ABE performance with actual hardware is reasonably close
> to the known/expected results.

I'm curious about what you think would be revealed by looking at paths with HW bottlenecks that you describe above.

The idea behind ABE is that ECN-enabled flows whose packets are ECN-marked in a small bottleneck queue will gain benefit. So long as ECN marking occurs at the equivalent of a small(-ish) bottleneck queue, the details of actual queue implementation seem orthogonal (such as whether software or hardware, dynamically sized or otherwise, augmented by rate shapers or not, and so forth). ABE does assume that ECN is implemented reasonably (e.g. along the lines advised in https://tools.ietf.org/html/rfc7567#section-4.2.1), and ABE doesn't propose any changes to endpoint behaviour in the face of packet loss.

cheers,
gja

>
> Michael
>
>
>> -----Original Message-----
>> From: iccrg [mailto:[email-masked]] On Behalf Of Michael Welzl
>> Sent: Tuesday, September 22, 2015 1:35 PM
>> To: [email-masked]
>> Subject: [iccrg] Review of draft-khademi-alternativebackoff-ecn-01.txt
>>
>> <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+A
>> lternative+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
>
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

-- 
Professor Grenville Armitage
Director, Centre for Advanced Internet Architectures
School of Software and Electrical Engineering
Faculty of Science, Engineering and Technology
Swinburne University of Technology, Australia
http://caia.swin.edu.au

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 7 Oct 2015 08:27:14 +0000

For the IETF it may also be quite relevant insight if a real-world measurement just confirms that everything is as to be expected if the scheme hits actual network equipment. For instance, it could also be interesting to describe an example device configuration for which the scheme works (well). It is obvious that this is not the kind of material to be published in a paper. But e.g. network admins might be quite interested in that sort of information. But, to be explicit, this is really my personal view as engineer only.

Much more important would be to narrow down the algorithm and parameter design space and come up with a recommendation what TCPM should exactly standardize.

Michael

-----Original Message-----
From: iccrg [mailto:[email-masked]] On Behalf Of grenville armitage
Sent: Wednesday, October 07, 2015 12:04 AM
To: [email-masked]
Subject: Re: [iccrg] Review of draft-khademi-alternativebackoff-ecn-01.txt

Hi Michael,

On 09/22/2015 22:25, Scharf, Michael (Michael) wrote:
> rate policers, multiple (W)RED slopes, hierarchical schedulers, et al. 
> I think there are Ethernet switches that support ECN and that could be 
> used for such experiments - provided somebody has access to HW.
>

cheers,
gja

>> Subject: [iccrg] Review of 
>> draft-khademi-alternativebackoff-ecn-01.txt
>>
>> 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:
>> below, the draft has just been updated. As usual for such 
>> evaluations, I also created a Wiki page for it:

--
Professor Grenville Armitage
Director, Centre for Advanced Internet Architectures School of Software and Electrical Engineering Faculty of Science, Engineering and Technology Swinburne University of Technology, Australia http://caia.swin.edu.au

---

From: Michael Welzl <[email-masked]>
Date: Wed, 7 Oct 2015 10:57:41 +0200

Hi Michael,

> On 07 Oct 2015, at 10:27, Scharf, Michael (Michael) <[email-masked]> wrote:
> 

The scope of the proposed standardization is quite clear and quite narrow I think, at least in the recent update of the draft:
https://tools.ietf.org/html/draft-khademi-alternativebackoff-ecn-01#section-3.2

I have asked ICCRG folks to review the draft and related paper; however, I see this as a check to confirm whether the proposed update is appropriate and not as "narrowing down the algorithm and parameter design space":
IIRC, in Prague, you raised a concern about 1) using 0.8 as a value, and 2) the possibility to apply this to various congestion control algorithms.

For 1), this is what I'd like folks to check / confirm - material is available via http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_abe
For 2), the draft says: "for any given TCP algorithm the choice of beta_{ecn} is likely to be algorithm-specific"  and so trying to cover more than Reno in the specified update is broadening, not narrowing down the algorithm (which is not what we authors propose to do).

... or what am I missing?

Cheers,
Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 7 Oct 2015 09:27:12 +0000

For what it is worth, in Prague I raised the question whether the absolute value of 0.8 can be replaced by a (suggested) relative share, as suggested by Mark Allman.

So, the question is whether the document could make a more explicit recommendation than "for any given TCP algorithm the choice of beta_{ecn} is likely to be algorithm-specific". 

Michael

-----Original Message-----
From: iccrg [mailto:[email-masked]] On Behalf Of Michael Welzl
Sent: Wednesday, October 07, 2015 10:58 AM
To: Scharf, Michael (Michael)
Cc: [email-masked]; grenville armitage
Subject: Re: [iccrg] Review of draft-khademi-alternativebackoff-ecn-01.txt

Hi Michael,

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 7 Oct 2015 11:36:28 +0200

Hi,

Thanks for your response - it helps to narrow down the discussion so the question asked to ICCRG becomes clearer:

> On 07 Oct 2015, at 11:27, Scharf, Michael (Michael) <[email-masked]> wrote:
> 

This is addressed by section 2.2 in the draft update, specifically this text:

***
   The appropriate choice for beta_{loss} and beta_{ecn} values is a
   balancing act between path utilisation and draining the bottleneck
   queue.  More aggressive backoff (smaller beta_*) risks underutilising
   the path, while less aggressive backoff (larger beta_*) can result in
   slower draining of the bottleneck queue.

   The Internet is already running with at least two different
   beta_{loss} values, [RFC5681]'s 0.5, and Linux CUBIC's 0.7.  ABE
   proposes no change to beta_{loss} used by any current TCP
   implementations.

   beta_{ecn} depends on how we want to optimise the reponse of a TCP
   connection to shallow AQM marking thresholds. beta_{loss} reflects
   the preferred response of each TCP algorithm when faced with
   exhaustion of buffers (of unknown depth) signalled by packet loss.
   Consequently, for any given TCP algorithm the choice of beta_{ecn} is
   likely to be algorithm-specific, rather than a constant multiple of
   the algorithm's existing beta_{loss}.
***

If I interpret things correctly, we need ICCRG's views on exactly this matter. Right?

Cheers,
Michael