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

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

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).

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