Subject: [v6ops] Mirja Kühlewind's Discuss on draft-ietf-v6ops-rfc6555bis-05: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 16 Oct 2017 06:22:20 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-v6ops-rfc6555bis-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would totally be a yes on this document, but I would like to first discuss a
processing issue: I do not agree with the assessment that this draft should
obsolete RFC6555. The draft itself says: "This document expands on "Happy
Eyeballs" [RFC6555]..." which sounds to me like an update. Further I believe
RFC6555 is still a valid algorithm that can be used as specified, also RFC6555
provides probably more useful background info that is not captured by this new
draft. I would recommend to update instead. Also, in any case the obsolete or
update should to be mentioned in the abstract.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Question on the equation in section 5:
"MAX( 1.25 * RTT_MEAN + 4 * RTT_VARIANCE, 2 *RTT_MEAN )"
While it is not well explained how RTT_MEAN and RTT_VARIANCE are measured, I
would recommend to just use *3RTT instead (where RTT is the value you have
cached for a certain destination address, no matter how that has been
measured/calculated), as RFC2988 says:

"When the first RTT measurement R is made, the host MUST set

            SRTT <- R
            RTTVAR <- R/2
            RTO <- SRTT + max (G, K*RTTVAR)"

which translates to 3*R if you only have one value.

I also don't think that is is necessary to talk about exponential backoff. To
me that seems more confusing than helpful here.

However, it might be helpful to note that 3*RTT also means that in the best
case the handshake is already completed before you try the next address. And
further, I would assume that you might still want to have a fixed max default
value (of e.g. 300ms or 250ms?) because otherwise on paths where you have high
delay sequential probing might be too slow, no?

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 Oct 2017 14:51:22 -0700

Hi Mirja,

Thanks very much for the helpful feedback! I've just posted a new version here:

https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-06 <https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-06>
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-06 <https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-06>

Direct responses inline.

Thanks!
Tommy

> On Oct 16, 2017, at 6:22 AM, Mirja Kühlewind <[email-masked]> wrote:
> 

Based on our WG discussions and last call, we believe that obsoleting RFC 6555 is the correct status for this draft. A "simple" implementation of the 6555bis algorithm is still aligned with the algorithm in 6555, and we would like to see new implementations taking the nuances of the new algorithm description into account.

I added more explicit text to the Introduction to explain that this document is obsoleting RFC 6555, which should read more clearly now.

Very good point! The formula is what our implementation uses, but you're correct that it was not clear how to calculate the values described (which for us come from historical data).

I've re-worked that paragraph to simply make the point that the delay should correspond to the first SYN retransmission of the previous attempt, and point to RFC 6298 to describe the calculations involved.

> me that seems more confusing than helpful here.

This comment was added based on some discussion in the WG. I've re-worked this sentence to clarify that the delay should only be approximating the first SYN retransmission, and not any other RTT calculation or back off.

> delay sequential probing might be too slow, no?

The following paragraph does indicate that implementations MUST have min and max values, and gives recommended values for these. I believe this should address your concern!

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Sat, 21 Oct 2017 02:35:40 +0200

Hi Tommy,

I will have a closer look on Monday. Just one small nit that can be fixed later as well: the abstract should also mention that this doc obsoletes 6555.

Mirja

> Am 20.10.2017 um 23:51 schrieb Tommy Pauly <[email-masked]>:
> 
> Hi Mirja,
> 
> https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-06
> https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-rfc6555bis-06
> 
> Direct responses inline.
> 
> Thanks!
> Tommy
>

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 20 Oct 2017 20:21:47 -0700

> On Oct 20, 2017, at 5:35 PM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> Hi Tommy,
> 

Sounds good, I will add that to the abstract in the next revision. I’ll wait for any more of your feedback and that of the others before posting an update.

Best,
Tommy