Re: [tcpm] rto-consider updated

[Yuchung Cheng <[e-mail]>]

On Wed, Oct 21, 2015 at 7:55 PM, Mark Allman <[e-mail]> wrote:
>
>> I am interested.
>
> :)
>
>> Following the spirit of reflecting the reality,
>
> The reality I meant to reflect was that the details of RTO
> implementations have diverged a bit from anything that is
> standardized.  And, that seems to be OK.  So, by standard it seems
> to me that perhaps we should just decide there are a few things that
> we'd like to see hold and not pretend that all the details are
> important enough to tightly specify.  Because the world has shown us
> that this is simply not true.
>
>> * (3) MUST exp. backoff: I agree on expback off is needed for safety.
>> But MUST "eventually" exp backoff reflects the reality
>> better. AFAIK Linux has the "thin-stream" optimization that
>> optionally use linear back for the first 6? retries. And I recall
>> vaguely some stacks do so based on some (old) research paper.
>
> I dunno ... I guess I still think exponential backoff is the
> ultimate bit that protects us and so I am a little wary of adding
> too many wiggle words here (the draft does suggest that exponential
> doesn't have to be 2x).  But, if the WG wants to take this up and
> the WG consensus is for some sort of eventual exponential backoff
> then I guess that is OK.
>
>> * Would be nice to talk about the well-known tricks for data-center
>> communications to lower the delayed ACK and RTO.
>
> This is what I don't really want to talk about.  I don't want to
> codify tricks.  I want to give an umbrella under which various
> estimators could flourish.
OK. but worth articulate these non-goals in the draft.

>
>> * Knowing the delayed ACK time of the remote matters. Some RFC (1122?)
>> suggests 500ms. I think everyone uses lower value 40ms - 200ms.
>
> Well, ...
>
>   - I am not sure what you're proposing.  Some option to let the
>     receiver give the delayed ACK time?  Or, a "delayed" / "not
>     delayed" bit?  Whatever it is I think it is beyond the scope of
>     high level guidance.
>
>   - This does bring to mind a pet peeve which I have sort of fallen
>     into.  We talk about the RTO in terms of RTT, but it really
>     should be in terms of expected feedback time.  I.e., the sender
>     should not care about the delayed ACK timer.  But, the estimator
>     needs to understand when to expect an ACK for a given piece of
>     data.  That ACK might be delayed.  Or, it might not.  But,
>     calling the time between data transmission and ACK reception the
>     "RTT" is sort of mis-leading because it isn't just network
>     latency we care about.
agreed. that's also worth discussing in the draft. perhaps a fallacy
on designing "RTT" estimator.


Another point to consider: Linux is moving toward the model of
aggressive timeout to probe (TLP) then a conservative timeout to reset
cwnd when entire flight is surely lost. AFAIK QUIC also takes this
approach. https://tools.ietf.org/html/draft-tsvwg-quic-loss-recovery-00
I don't know where to fit in your draft, just FYI.

>
>> * I saw lots of (naive) attempts to lower the RTO for latency, it
>> would be nice to talk about the implication of spurious RTO.
>
> I try to sketch this tradeoff.  I guess I could go back and see if
> it could be improved.
>
> Thanks!
>
> allman
>
>
>