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

[Praveen Balasubramanian <[e-mail]>]

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

Yeah this is a real problem in IaaS environment today since TCP sender picks minrto and receiver picks delayed ACK timeout independently and can cause spurious RTOs if the minrto is too aggressive. Windows server tries to use the connection handshake RTT (< 10 msec) to auto pick the DC values but this is a heuristic that can fail and doesn't really work in the Linux interop cases. 

-----Original Message-----
From: tcpm [mailto:[e-mail]] On Behalf Of Yuchung Cheng
Sent: Friday, August 12, 2016 12:17 PM
To: Karen Elisabeth Egede Nielsen <[e-mail]>
Cc: tcpm IETF list <[e-mail]>; TCP Prague List <[e-mail]>
Subject: Re: [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt

On Fri, Aug 12, 2016 at 4:30 AM, Karen Elisabeth Egede Nielsen <[e-mail]> wrote:
>
> Hi Marcello,
>
> I very much appreciate your draft.
>
> Even more so as it addresses one of the things I find to be a bit 
> "disturbing"  in the l4s drafts - Namely the claim that the finer saw 
> tooth functionality of l4s/DCTCP alone solves the latency problems 
> (while DCTCP indeed also is tuning the RTO timeout aggressively).
> E.g., the formulation in  section 1.1 of 
> https://datatracker.ietf.org/doc/draft-briscoe-tsvwg-ecn-l4s-id/?inclu
> de_t
> ext=1
>
> It turns out that a TCP algorithm like DCTCP that solves TCP's
>    scalability problem also solves the latency problem, because the
>    finer sawteeth cause very little queuing delay.  A supporting paper
>    [DCttH15] gives the full explanation of why the design solves both
>    the latency and the scaling problems, both in plain English and in
>    more precise mathematical form.  The explanation is summarised
>    without the maths in [I-D.briscoe-aqm-dualq-coupled].
>
> could benefit from a reference to your draft or the issue that you 
> addresses here (at least for comprehensiveness).
>
> 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. 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

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm