Subject: TLP in recovery-17 draft

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 17 Jan 2019 23:44:37 -0800

Hello,
I might overlook something, but I cannot find TLP logic in the pseudo codes
in the draft. I mean timeout seems to be determined by conventional way.
Is this intentional or am I missing something?

Thanks,
--
Yoshi

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 18 Jan 2019 02:55:49 -0500

Look for PTO. RTO and TLP were merged into the one concept. Jana can provide all the nasty details. 

On Fri, Jan 18, 2019, at 20:45, Yoshifumi Nishida wrote:
> Hello,
> I might overlook something, but I cannot find TLP logic in the pseudo 
> codes in the draft. I mean timeout seems to be determined by 
> conventional way.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 19 Jan 2019 04:13:08 -0800

Yep, I think I'm aware of the merging. The code looks cleaner and simpler.
But, it seems to me that this code will react slowly in tail loss
situations.. It would be great if someone could clarify.
--
Yoshi

---

From: Ian Swett <[email-masked]>
Date: Sat, 19 Jan 2019 08:57:01 -0500

Can you clarify what you mean by slowly?

Are you concerned the first PTO timeout will be substantially longer than
what the first TLP was?  If so, I believe that should be mostly mitigated
by moving from a fixed min RTO to one that includes the explicitly
communicated max ack delay, along the lines of the TCP MAD proposal(
https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00).

In cases when the rtt variance is large, PTO will definitely be longer than
TLP was, but I think that's a feature, since it recognizes that sometimes
TLP is too aggressive in those cases.

On Sat, Jan 19, 2019 at 7:13 AM Yoshifumi Nishida <[email-masked]>
wrote:

>> Look for PTO. RTO and TLP were merged into the one concept.. Jana can
>> provide all the nasty details.
>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sat, 19 Jan 2019 14:01:46 -0800

Hi Ian,

Thanks for the response. Yes, that was my point.
But, I think I got it now.
In the previous draft, kMinRTOTimeout was 200ms and kMinTLPTimeout was
10ms, but now only lower bound is kGgranularity and it's 1ms.
So, new PTO can be smaller than the previous version of RTO unless there's
no large variation in RTT samplings.
--
Yoshi

On Sat, Jan 19, 2019 at 5:57 AM Ian Swett <[email-masked]> wrote:

> In cases when the rtt variance is large, PTO will definitely be longer
> than TLP was, but I think that's a feature, since it recognizes that
> sometimes TLP is too aggressive in those cases.
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 22 Jan 2019 12:42:16 -0800

Hi,
Please allow me to continue this a bit more.
I am thinking that we might need a certain lower boundary for the timeouts
in 17 draft.
It uses exponential backoff algorithms, but I think it won't be very
conservative in case the timeout value is small.

This is just an idea, but to be clear, belows are what I am thinking.

In case of crypto timeout:

  timeout = crypto_count > 0 ? max(timeout, kMinCryptoRTO) * (2 ^
crypto_count) : timeout

   kMinCryptoRTO ... 100ms?

In case of PTO:

  timeout = pto_count > 0 ? max(timeout, kMinPTO) * (2 ^ pto_count) :
timeout

   kMinPTO ... 200ms?

BTW, I would like to clarify the behavior of loss_detection_timer.
When set() is called while the timer is running, the current timer
value is replaced with the new value or else?

--
Yoshi

---

From: Ian Swett <[email-masked]>
Date: Tue, 22 Jan 2019 17:02:59 -0500

On Tue, Jan 22, 2019 at 3:42 PM Yoshifumi Nishida <[email-masked]>
wrote:

>    kMinPTO .... 200ms?
Personally, I'd prefer to not add more minimums to these calculations,
because I've seen cases when minimums, especially the rather conservative
values you're proposing, cause large performance regressions in TCP,
particularly in datacenter environments.

> When set() is called while the timer is running, the current timer value is replaced with the new value or else?
>
>
Yes, would it be more intuitive if we used update() instead of set()?

>> So, new PTO can be smaller than the previous version of RTO unless
>> there's no large variation in RTT samplings.
>> --
>> Yoshi
>>
>>> Are you concerned the first PTO timeout will be substantially longer
>>> than what the first TLP was?  If so, I believe that should be mostly
>>> mitigated by moving from a fixed min RTO to one that includes the
>>> explicitly communicated max ack delay, along the lines of the TCP MAD
>>> proposal(https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00
>>> ).
>>>
>>> On Sat, Jan 19, 2019 at 7:13 AM Yoshifumi Nishida <
>>> [email-masked]> wrote:
>>>
>>>>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 22 Jan 2019 22:22:20 -0800

Hi Ian,

On Tue, Jan 22, 2019 at 2:02 PM Ian Swett <ianswett=
[email-masked]> wrote:

>> I am thinking that we might need a certain lower boundary for the
>> timeouts in 17 draft.

Right.. I agree that this is too conservative for data center environments.
I feel a bit guilty and feel like being a villain.
But, I'm totally fine that people don't use these boundaries inside data
centers or some companies try more aggressive settings on their own.
Because in this case, people there should understand exactly what they are
doing in controlled environments.

What I'm wondering is whether if we should write down this logic in a
standard track RFC or not.
Because I feel this may mean IETF will endorse these settings over various
network environments.

Anyway, this is just my personal preference. But, I might want to see some
discussions on this point.

> Yes, would it be more intuitive if we used update() instead of set()?

Yes, update() looks good to me. Thanks!
--
Yoshi