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

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
> <karen.nielsen@tieto.com> 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

> 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

>
>> BR, Karen
>>
>>> -----Original Message-----
>>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of marcelo bagnulo
>>> braun
>>> Sent: 8. juli 2016 23:19
>>> To: tcpm IETF list <tcpm@ietf.org>
>>> 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:   internet-drafts@ietf.org
>>> Responder a:  internet-drafts@ietf.org
>>> Para:         i-d-announce@ietf.org
>>>
>>>
>>>
>>> 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
>>> I-D-Announce@ietf.org
>>> 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
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>