[tcpm] Vicious or Virtuous circle? Adapting reordering window to reordering degree

[Bob Briscoe <[e-mail]>]

Yuchung,

What I was trying to say at the tcpm mic just now.
This could be considered as a first draft of the text you asked me to 
write...


      The Bigger Picture

The reordering degree of a link is not a constant. It evolves (over 
years) dependent on TCP.

  *  From a link designers viewpoint, parallelizing (eg. link bonding)
    is the easiest way to get their link to go faster
      o So their main constraint on speed is reordering and there is
        huge pressure on them to relax that constraint
      o The /only/ thing that is holding them back from introducing more
        reordering is the 3 dupacks in TCP or the RTT/4 rule in RACK-02
  * It is likely RACK will become widespread
  * Given RACK-03 now adapts to the reordering window, link designers
    will introduce more reordering
  * That is GOOD (virtuous circle), but only up to a point (vicious circle).
      o We need to write down what that point is
      o We need to ensure the algorithm stops adapting at that point.

Put in IETF process terms, the draft needs to state the WG's consensus 
of what the goal of the experiment is. Otherwise:

  * we can't judge whether the experiment has succeeded.
  * we can't invent alternative algorithms to better reach the goal.


      TCP Specifics:

TCP cannot tell immediately whether a hole is reordering or loss.
It only knows in hindsight (if the hole gets filled later).

It is good (up to a point) to allow more reordering in the network, and 
repair the reordering within the receive buffer instead.
It is also good (up to a point) for TCP to be able to deem that a loss 
has occurred as quickly as possible.

However,

  * the longer the reordering window, the longer it takes to repair losses
  * the faster loss is repaired, the more spurious retransmissions

These two represent a trade-off between latency and bandwidth efficiency.

Given the reordering window could evolve to grow without bound (see 'the 
bigger picture'),...
...Where is the best trade-off point?

What assumption about the answer to this problem did you make when 
designing the algo in RACK-03?



Bob

On 05/03/18 23:11, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.
>
>          Title           : RACK: a time-based fast loss detection algorithm for TCP
>          Authors         : Yuchung Cheng
>                            Neal Cardwell
>                            Nandita Dukkipati
>                            Priyaranjan Jha
> 	Filename        : draft-ietf-tcpm-rack-03.txt
> 	Pages           : 25
> 	Date            : 2018-03-05
>
> Abstract:
>     This document presents a new TCP loss detection algorithm called RACK
>     ("Recent ACKnowledgment").  RACK uses the notion of time, instead of
>     packet or sequence counts, to detect losses, for modern TCP
>     implementations that can support per-packet timestamps and the
>     selective acknowledgment (SACK) option.  It is intended to replace
>     the conventional DUPACK threshold approach and its variants, as well
>     as other nonstandard approaches.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tcpm-rack-03
> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-03
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/