Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt

[Yuchung Cheng <[e-mail]>]

On Thu, Aug 18, 2016 at 1:05 AM, Karen Elisabeth Egede Nielsen
<[e-mail]> wrote:
> [Karen Elisabeth Egede Nielsen] I agree completely with your view and
> approach.
>
> In respect to the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the given
> recommendations for low RTO
> is that they do not (likely) take 2. Into account - meaning that they are
> looking for the low RTO to solve 2 for tail recovery.
> The bad thing is that they then also get the CWND reductions (as you also
> say).
>
>
> I would like for that this aspect is taken into consideration/given thoughts
> in the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the general 4LS
> effort.
> If we end with very low recommendations for RTO in order to handle 2. we
> risk undermining the RTO-retransmission function as well as the TLP function
> for now and forever.
>
> It might be that one for TCPs, that do not support TLP(/RACK), need to
> operate with very low RTOs to handle tail loss's "fast enough", but the
> recommendation for
> "future standard ?" TCP with TLP always enabled might be different. In this
> context lowering the RTO to handle 2. should be considered as a "temporary
> hack" ?

One feature worth discussion in the draft is the penalty of cwnd=1 on
spurious timeouts.

For DC, the RTT is so fairly low that we may consider a false reset of
cwnd to 1 is not a big deal. But consider in world of 100Gbps BDP will
still be hundreds of packets so it is going to be a non-trivial
penalty.

Therefore it is important to discuss the timeouts with the remedy
operations: how well can the connection detect spurious timeouts:
F-RTO or Eifel are the two algorithms by IETF, Linux also supports
DSACK-based undo.

However, both F-RTO and Eifel have their limitations: F-RTO requires
the sender to have new data to transmit after the first DUPACK of
timeout. In the DC world, the requests or responses are often short
enough to prevent that. Eifel relies on timestamps which is ticked at
an interval higher than the DC RTT (e.g., Linux == jiffies == 1ms
often), therefore the timestamps fail to distinguish original and
retransmit if RTO was fired before the next tick.

I plan to cover these aspects in next RACK rev.

>
> BR, Karen