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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

HI Yuchung, Marcello

> -----Original Message-----
> From: Yuchung Cheng [mailto:[e-mail]]
> Sent: 15. august 2016 18:49
> To: Karen Elisabeth Egede Nielsen <[e-mail]>
> Cc: marcelo bagnulo braun <[e-mail]>; TCP Prague List
> <[e-mail]>; tcpm IETF list <[e-mail]>
> Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt
>
> On Mon, Aug 15, 2016 at 2:00 AM, Karen Elisabeth Egede Nielsen
> <[e-mail]> wrote:
> > Hi Yuchung,
> >
> >> >
> >> > An additional comment is  that new approaches to retransmissions -
> >> > like TCP TLP and TCP RACK (also SCTP TLR which however is not
> >> > progressing at the moment) might fundamentally alter the picture.
> >> > I.e., if retransmissions are sent pro-actively in tail loss
> >> > situations then more conservative RTOs may be kept for situations
> >> > where it is prudent to wait longer. Don't know if TCP TLP is so
> >> > widely deployed that it is something that you should relate to even
> >> > if it may be superseded by RACK. Just a thought.
> >> TLP and RACK help reduce timeout cases in DC environment for sure.
> >> But still it can not completely avoid timeouts.
> >
> > [Karen Elisabeth Egede Nielsen] Agreed.
> >
> > For SCTP TLR we still see RTO-timeouts when also
> > probes/retransmissions are lost.
> > I assume that it would be something like this also for Rack/TLP -
> > though potentially depending on how many consecutive probes that are
> allowed.
> > The role of RTO-timeouts are different when RACK/TLP is enabled and it
> > might be counterproductive to have RTO-timeouts be too aggressive as
> > the function indeed with TLP/RACK becomes something much closer to the
> > original intend
> > (read: how I understand the original intend) - namely to introduce a
> > pause for the network to recover when things are really (consistently)
> > bad.
> >
> > If the RTO is lowered down to be comparable in order of magnitude with
> > the RTT (with some delay_ack considerations) we are narrowing the
> > situation where TLP/RACK probing is able to kick in before
> > RTO-retransmissions starts anyway.
> >
> > I understand that RTOs should be adjusted to the network dynamics, but
> > I do think that it is important to understand - for the DC environment
> > - if the need for the low RTOs in DC's is motivated mainly by having
> > RTO-retransmissions fix the tail loss recovery deficiencies of TCP,
> > which RACK/TLP addresses, or more generally for a need for more timely
> > probe and reactivation for/after network recovery.
> >
> > Or perhaps you see the TLP probe timeout and the RTO timeout
> > eventually being driven by the same timer, the reactions (e.g. CC
> > reactions)  then possibly depending on state (probe already sent or
> > not).
> I agree with your thought here.
>
> More generally, I'd like to evolve the state of art recovery with these
> principles:
> 1. React with ack events as much as possible
>
> 2. Send tiny probes to trigger (1) after 2-3 RTTs
>
> 3. Have conservative  RTOs that (exp-backoff) expire at an order of RTT to
> repair the head for reliability.
>
>
> On thing about RTO: RTO current reset cwnd to 1 upon firing no matter
> what.
> We should ONLY reset cwnd to 1 if no news (acks/data) for a long duration.
> This is quite important for performance: today cwnd is reset to 1 even if
> every packet but the first one has been recently delivered. This
> unnecessarily conservative because the ack clock isn't lost yet. But the
> collateral damage to performance is huge on large BDP networks. This
> results
> work-arounds to shorten and avoid RTOs.
>
>
> I'd like to address these points in the upcoming RACK/TLP draft.
>
>
[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" ?

BR, Karen