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

[Yuchung Cheng <[e-mail]>]

On Fri, Aug 12, 2016 at 12:40 PM, marcelo bagnulo braun
<[e-mail]> wrote:
> Karen, Yuchung,
> Thanks for the comments.
> Replies below.
>
>
> El 12/08/16 a las 21:16, Yuchung Cheng escribió:
>
>> 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/?include_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.
>>
>
> Right.
>
> I guess we should could say that the min RTO should be in the order of the
> RTT of the considered network when there is zero queueng delay.
> But if the draft is aiming to be a reccomendation for imeplenters of DC
> network TCP stacks, then i guess it should provide a guidance that is
> independent of the DC network itself, since the implementation should work
> for a variety of DC networks, no?
>
>
> I guess the more general question is whether we need this document i.e. a
> document describing reccoemndation about how to set TCP for low RTT
> networks. If people think it is a good idea to have such a document, we then
> figure how if this is
my conundrum is that DC tcp stuff is usually not an inter-op issue for
the Internet so this draft is more of a "how to tune your DC tcp
stack". but I can be convinced either ways.

>
>> 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.
>>
> Right, If i understood correctly Bob's paper (cited in the draft) this is
> exactly what they are proposing.
> I dont think this document is the right place to define the behaviour of
> CWND less than 1 MSS. I think this should be done in a separated document,
> which is then referred by the low-rtt draft.
>
> Are you aware of other documents (draft or papers others than the one from
> Bob) describing mechanisms to achieve this?
>
>> 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.
>>
> I am not sure if a follow.
> What is the benefit of allowing dynamic negotiation of the delay ack time?
> Thanks, marcelo
the receiver may decide to delay ack up to certain time. it could be
based on DC implementation or host limit. It'd be good for sender to
learn about that to adapt his RTO.

For example, say it's a cloud VM. VM of OS1 may use a max delay for
d-ack say 2ms. but VM of OS2 may use 40ms. The lack of such
information makes the sender to these VMs use something  conservative
of known max of all, otherwise he risks spurious RTOs.

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