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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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 <[e-mail]>:
> 
> 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://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 <[e-mail]> wrote:
>> 
>> 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.
> 
> 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.
> 
>> 
>> 
>> ----------------------------------------------------------------------
>> 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.
> 
> 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.
> 
>> 
>> I also don't think that is is necessary to talk about exponential backoff. To
>> 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.
> 
>> 
>> 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?
> 
> 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!
> 
>> 
>> 
>