[v6ops] review: draft-pauly-v6ops-happy-eyeballs-update-01

["Bajpai, Vaibhav" <[e-mail]>]

> An Update to Happy Eyeballs
> draft-pauly-v6ops-happy-eyeballs-update-01

The draft is trying to do 2 things at once (describe Apple's implementation
and provide a RFC 6555 update) which is mixing things up. For instance, 
after having read the draft, I end up getting more confused on what Apple's
implementation actually does. See below for details.

My suggestion would be to shelf this draft for now, but first describe 
Apple's implementation as an informational RFC. This should go quick and be
very useful to the community. I agree that RFC 6555 needs an update (see [a]
for details), but perhaps it is easier to do once ^ is done, so that we can 
cherry pick good parts from Apple's experience (and from others who have 
longitudinal HE datasets, implementation experience) to update RFC 6555.

[a] https://doi.org/10.1145/2959424.2959429

-- Vaibhav



details
-------


-- The draft needs to explicitly state what is the problem with current RFC
6555 description and why it needs an update.

-- It is not clear how the recommendations made in this draft [b] relate to
Apple's [c] implementation.

[b] https://tools.ietf.org/html/draft-pauly-v6ops-happy-eyeballs-update-01
[c] https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html




// §3: Hostname Resolution Query Handling

-- 'If one query fails to return, or takes significantly longer to return'

how long is significantly long?



-- 'This delay will be referred to as the "Resolution Delay".  The RECOMMENDED
value for the Resolution Delay is 50 milliseconds.’

how is this value of 50 ms determined? Doesn't Apple's implementation use a 
25 ms timer instead? [a]



[a] https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html

-- what is a 'staggered' connection?

-- In what % of cases you see that DNS queries are made over v6 transport?

-- In what % of cases, you see that AAAA queries not cached, but A queries
are? Is this invariant of the underlying transport?



// §4: Sorting Addresses

-- 'If the client is stateful and has history of expected round-trip
   times (RTT) for the routes’

How long should be the history?


-- 'This historical data MUST NOT be used across networks, and SHOULD be
flushed on network changes.’

Unclear what you mean by network change, an example here would be nice.


// §5: Connection Attempts

-- 'This delay is referred to as the "Connection Attempt Delay".  One
recommended value for this delay is 250 milliseconds.’

How is this value determined? This is not what Apple's implementation [a] 
does right? Then how do you recommend this value?

[a] https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html

-- 'The recommended formula for calculating the delay after starting a
connection attempt is: MAX( 1.25 * RTT_MEAN + 4 * RTT_VARIANCE, 2 * RTT_MEAN
), where the RTT values are based on the statistics for previous address
used.’

How is this formula determined? Why does this give good results?

-- '... all other connections attempts that have not yet
   succeeded SHOULD be cancelled.’

I think you mean terminated.



--------------------------
Vaibhav Bajpai
www.vaibhavbajpai.com

Postdoctoral Researcher
TU Munich, Germany
--------------------------