Subject: [v6ops] Happy Eyeballs v2

From: David Schinazi <[email-masked]>
Date: Mon, 10 Apr 2017 10:43:45 -0700

Hi v6ops,

We've updated our "Update to Happy Eyeballs" document to address feedback received so far:
https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00 <https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00>

Main changes since the previous version:
- Draft is now a v6ops working group document
- Draft name is now rfc6555bis
- Title changed to "Happy Eyeballs Version 2: Better Connectivity Using Concurrency"
	The rationale here is that this is different enough from RFC6555 that it warrants
	a slightly new name, however we didn't want to completely change the name
	since people always refer to the old name which causes confusion (e.g. SSL/TLS).
	For reference RFC6555 has title "Happy Eyeballs: Success with Dual-Stack Hosts"
- Draft now obsoletes 6555 (if approved)
- Changed wording to be more generic than IPv6/v4 fallback
- Added details on timeout computation and bounds
- Added possibility to change timeout without updating document
- Added a limitations sections declaring PMTUD and application-layer failures out of scope

Diff viewer:
https://tools.ietf.org/rfcdiff?url1=draft-pauly-v6ops-happy-eyeballs-update-01&url2=draft-ietf-v6ops-rfc6555bis-00.txt <https://tools.ietf.org/rfcdiff?url1=draft-pauly-v6ops-happy-eyeballs-update-01&url2=draft-ietf-v6ops-rfc6555bis-00.txt>
https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-pauly-v6ops-happy-eyeballs-update-01&url2=draft-ietf-v6ops-rfc6555bis-00.txt <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url1=draft-pauly-v6ops-happy-eyeballs-update-01&url2=draft-ietf-v6ops-rfc6555bis-00.txt>

Thanks to everyone who sent feedback, and please let us know if this addresses yours.
David

> Begin forwarded message:
> 
> 
> A new version of I-D, draft-ietf-v6ops-rfc6555bis-00.txt
> has been successfully submitted by David Schinazi and posted to the
> IETF repository.
> 
> Name:		draft-ietf-v6ops-rfc6555bis
> Revision:	00
> Title:		Happy Eyeballs Version 2: Better Connectivity Using Concurrency
> Document date:	2017-04-08
> Group:		v6ops
> Pages:		9
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-v6ops-rfc6555bis-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc6555bis/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-rfc6555bis-00
> 
> 
> Abstract:
>   Many communication protocols operated over the modern Internet uses
>   host names.  These often resolve to multiple IP addresses, each of
>   which may have different performance and connectivity
>   characteristics.  Since specific addresses or address families (IPv4
>   or IPv6) may be blocked, broken, or sub-optimal on a network, clients
>   that attempt multiple connections in parallel have a higher chance of
>   establishing a connection sooner.  This document specifies
>   requirements for algorithms that reduce this user-visible delay and
>   provides an example algorithm.

---

From: "Bajpai, Vaibhav" <[email-masked]>
Date: Wed, 19 Apr 2017 13:24:26 +0000

Hello,

> On 10. Apr 2017, at 19:43, David Schinazi <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-ietf-v6ops-rfc6555bis-00
> 
> [...]
> 

I read draft-ietf-v6ops-rfc6555bis-00. 
It seems my concerns still exist, while I also added few more:

-- Vaibhav

details
-------

-- The title is much better.

// § Abstract

-- 'Many communication protocols operated over the modern Internet'

What is modern Internet?

-- 'These often resolve to multiple IP addresses, each of which may have
different performance and connectivity characteristics.'

I don't think IP addresses have performance characteristics. The IP paths do.

// §1: Introduction

The first paragraph is verbatim copied from abstract.

'Now that this approach has been deployed at scale and measured for several
years, the algorithm specification can be refined to improve its reliability
and generalization.'

This is not a convincing argument to update a specification. Think about how
many specifications deserve an update according to ^ reasoning.  The draft
needs to explicitly state what is the problem with current RFC 6555
description and why it needs an update.  I think you should mention the
shortcomings Stuart pointed out in [a].

[a] https://mailarchive.ietf.org/arch/msg/v6ops/PncnS9KwfKxsya35cHx2PH7Fm8w

// §2: Overview

'If the host is configured differently, the recommendations in this document
can be easily adapted.'

How?

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

[a] 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? and I think you mean 'one query response fails
to return' -- This is repeated at multiple places in the draft.

-- '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?

-- 'Client systems SHOULD NOT have an explicit limit to the number of DNS
   servers that can be configured, either manually or by the network.
   If such a limit is required by hardware limitations, it is
   RECOMMENDED to use at least one address from each address family from
   the available list.'

How is a candidate address from each AF chosen?

// §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.

-- 'While TCP implementations often leverage an exponential backoff when they
    detect packet loss, the "Connection Attempt Delay" SHOULD NOT such an
    aggressive backoff, as it would harm user experience.'

This statement needs to be backed up by evidence.

-- 'More specifically, a subsequent connection MUST NOT be started within 10
    milliseconds of the previous attempt.  The recommended minimum value is 100
    milliseconds, which is referred to as the "Minimum Connection Attempt Delay".
    This minimum value is required to avoid congestive collapse in the presence of
    high packet loss rates.  The Connection Attempt Delay SHOULD have an upper
    bound, referred to as the "Maximum Connection Attempt Delay".  The current
    recommended value is 2 seconds.'

How are these values determined?

// §8: Connection Attempts

-- 'Since Happy Eyeballs is only active during the initial handshake and
   TCP does not pas the initial handshake'

I think you mean HE does not take effect beyond the TCP handshake. There is
also a typo here.

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

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