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

[Yuchung Cheng <[e-mail]>]

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.



>
> BR, Karen
>
>  So I agree we should keep
>> timeouts conservative, but the current RFCs are way too conservative:
>> min RTO of 1 second is 4-5 orders of magnitude of DC RTTs.
>>
>> The issue is, the "right" min-RTO depends on the actual DC and stacks:
>> they all have different RTTs and timer granularity. The draft cites
>> Glenn's paper, but Morgan Stanley's DC could be different than others.
>>
>>
>> Other comments on the draft:
>>
>> 1. min ssthresh or cwnd: with very large incast ((tens of) thousands
>> of senders into one receiver), cwnd of 0.1 pkt can still be too big. the
>> only way is to pace the packets over N*RTT intervals.
>>
>>
>> 2. delayed acks:
>> as mentioned the actual time depends a lot on the DC implementation,
>> which is really "vender/owner"-specific. instead of perhaps an option
>> during setup to inform the sender about the max delay in the ack works
>> better.
>>
>>
>>
>> >
>> > BR, Karen
>> >
>> > > -----Original Message-----
>> > > From: tcpm [mailto:[e-mail]] On Behalf Of marcelo
>> bagnulo
>> > > braun
>> > > Sent: 8. juli 2016 23:19
>> > > To: tcpm IETF list <[e-mail]>
>> > > Subject: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt
>> > >
>> > > Hi,
>> > >
>> > > We just submitted this draft for consideration of the WG. Comments are
>> > > appreciated.
>> > >
>> > > Regards, marcelo
>> > >
>> > >
>> > >
>> > >
>> > > -------- Mensaje reenviado --------
>> > > Asunto:       I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt
>> > > Fecha:        Fri, 08 Jul 2016 14:16:35 -0700
>> > > De:   [e-mail]
>> > > Responder a:  [e-mail]
>> > > Para:         [e-mail]
>> > >
>> > >
>> > >
>> > > A New Internet-Draft is available from the on-line Internet-Drafts
>> > directories.
>> > >
>> > >
>> > >          Title           : Recommendations for increasing TCP
>> > performance in low RTT
>> > > networks.
>> > >          Authors         : Marcelo Bagnulo
>> > >                            Koen De Schepper
>> > >                            Glenn Judd
>> > >       Filename        : draft-bagnulo-tcpm-tcp-low-rtt-00.txt
>> > >       Pages           : 7
>> > >       Date            : 2016-07-08
>> > >
>> > > Abstract:
>> > >     This documents compiles a set of issues that negatively affect TCP
>> > >     performance in low RTT networks as well as the recommendations to
>> > >     overcome them.
>> > >
>> > >
>> > > The IETF datatracker status page for this draft is:
>> > > https://datatracker.ietf.org/doc/draft-bagnulo-tcpm-tcp-low-rtt/
>> > >
>> > > There's also a htmlized version available at:
>> > > https://tools.ietf.org/html/draft-bagnulo-tcpm-tcp-low-rtt-00
>> > >
>> > >
>> > > 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/
>> > >
>> > > _______________________________________________
>> > > I-D-Announce mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/i-d-announce
>> > > Internet-Draft directories: http://www.ietf.org/shadow.html or
>> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> > >
>> > >
>> > > _______________________________________________
>> > > tcpm mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/tcpm