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

[Bob Briscoe <[e-mail]>]

Yuchung,

On 26/03/18 17:15, Yuchung Cheng wrote:
> There are two action items
> 1) clarify the reo_wnd policy further

At present the draft largely just states the algo without much 
rationale. Now I understand the DSACK-based algo, I have realized it 
contains subtleties that I try to articulate below (pls use as text if 
you want).

Correct me if I'm wrong, but over the years I have detected a (perhaps 
unstated) presumption from some in the TCP community that their aim is 
to eliminate all spurious retransmissions. The DSACK algo doesn't fall 
into that trap, but superficially it looks as if it does.

The subtle part is that it starts off with the 3 DUPACK rule {Note 1}, 
then grows the reordering window from there as long as at least one 
{Note 2} spurious retransmission per RTT is detected. So, for short 
flows (or the beginning of long flows), even if the degree of reordering 
is high:

  * losses will be repaired fast, which is important for short-flow latency
  * and spurious retransmissions will be tolerated, which is OK for a
    few RTTs

If a flow lasts longer, and if the reordering degree is high, the 
reordering window will grow, so:

  * losses will take longer to repair, which is not such a concern for
    elephants {Note 3}
  * spurious retransmissions will be reduced, because the bandwidth
    efficiency of elephants dominates overall bandwidth efficiency.

I think it's important for the draft to explain that it deliberately 
starts by tolerating more spurious retransmissions to keep repair delay 
low for short flows. IOW, it would not be entirely appropriate to cache 
the reordering window learned from prior connections over the same path.

Cheers


Bob

{Note 1}: Alternative initial rules
This could be replaced with a duration in units of time, e.g. SRTT/4, 
but I understand that you wanted to start with traditional behaviour, so 
as not to trigger intrusion detection systems or protocol compliance 
checkers that might punish non-traditional behaviour.

{Note 2}: At least one?
Rather than counting the existence of at least one spurious 
retransmission per RTT, I think it would be preferable to count their 
extent. Then the algo would be collecting the metrics it needs to trade 
off a residual rate of spurious retransmissions against longer delay to 
repair losses. Instead, it keeps on extending the reordering window in 
response to even one spurious retransmission per RTT, whatever the cost 
in delayed loss-recovery (up to the arbitrary hard limit of 1 SRTT).

{Note 3}: Not all elephants are the same.
If an elephant is a single bulk file download, the delay repairing 
losses has negligible effect on performance. However, what looks like an 
elephant from the outside might actually by numerous multiplexed small 
streams (e.g. http2). Then delay repairing losses remains significant, 
potentially holding back a small object with potential collateral damage 
to latency delivering other objects stuck behind the loss (HoL 
blocking). Conclusion: TCP still needs to trade off delay repairing 
losses against spurious retransmissions, even for elephants.


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/