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

[Mirja Kühlewind <[e-mail]>]

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?