Subject: Re: [v6ops] simplfying Happy Eyeballs further

From: Cameron Byrne <[email-masked]>
Date: Sat, 18 Jun 2011 07:47:36 -0700

On Jun 18, 2011 6:54 AM, "Brian E Carpenter" <[email-masked]>
wrote:
>
> I prefer
>
> > a. initiate two simultaneous connection attempts
>
> or even three. Some studies we've done on SHIM6/REAP and MPTCP performance
> suggest that probing up to 3 addresses in parallel doesn't create
> a significant load but does improve the time to establish a connection.
>

Just like cell phones that constantly turn off and on their data connections
to optimize battery life, but in turn wreck the network with a flood of
signalling to attach and detach.

Please no.

Some of us are thinking about cgn exit strategies, and these ipv4
connections will be enough noise that I cannot properly dimension the ramp
down.

Sorry, we cannot always engineer the system to optimize on just the user
experience and expect all the other elements to scale and perform well

Cb

> Regards
>   Brian
>
> On 2011-06-18 12:25, Dan Wing wrote:
> > Since publishing draft-ietf-v6ops-happy-eyeballs-02, most of the
> > feedback we have received is along the lines of:
> >
> >   * simplify further
> >   * don't worry about sending excessive packets
> >   * prefer IPv6, unless it's failing "a lot"
> >
> > To that end, there seem to be three approaches.  We would like
> > feedback on which direction to document:
> >
> > After calling getaddrinfo(), v6ops needs to decide if we should:
> >     a. initiate two simultaneous connection attempts (first IPv6
> >        address and first IPv4 address).  Both connections can be used
> >        by HTTP.  Subsequent connections to that same hostname would
> >        use whichever address family connected quicker.
> >     b. initiate one connection attempt to the first address returned.
> >        If it isn't successful after NNN milliseconds, initiate a
> >        connection attempt to the first IPv4 address returned by
> >        getaddrinfo().  (This is what Chrome is doing.)
> >     c. initiate one connection attempt to the first address returned.
> >        If it isn't successful after NNN milliseconds, initiate a
> >        connection attempt to the next address returned by
> >        getaddrinfo().
> >
> > To deal with cases where "IPv6 is failing a lot", we might consider
> > ways to pick a good initial "NNN" value.  For example, we might
> > use a default of 200-300ms, and also define a DHCPv6 option so
> > the network could convey a different default.   This seems
> > useful for all sorts of situations, most notably 3G wireless
> > (which wouldn't use DHCPv6, but could use the same idea to
> > provide the same sort of information in IPCP or whatever it
> > likes.)
> >
> > We might also consider ways to automatically tune NNN up or
> > down.  For example, if IPv6 connected successfully, we can
> > increase NNN.  If an IPv6 connection times out and IPv4 wins,
> > we decrease NNN.  This is similar to what we are doing today
> > in Happy Eyeballs -00, -01, and -02.  But we would simplify
> > this from what is described in Happy Eyeballs today (which
> > has a Tolerance Interval and suchlike, based on previous
> > feedback).
> >
> >
> > Any thoughts on the various ideas above?
> >
> > -d
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Jun 2011 17:39:59 +0000

On Jun 18, 2011, at 10:48 AM, "Cameron Byrne" <[email-masked]> wrote:
> Some of us are thinking about cgn exit strategies, and these ipv4 connections will be enough noise that I cannot properly dimension the ramp down.

Why would you expect to see additional connection attempts on the CGN?  Don't v4-only clients already launch multiple connections?

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 18 Jun 2011 12:04:45 -0700

> Why would you expect to see additional connection attempts on the CGN?  Don't v4-only clients already launch multiple connections?

Yes.

I am only scoping HE in my head for scenarios where the resources are
dual-stack on both sides, thus there is an opportunity for a v6 e2e
connection which can result in a net reduction in the v4 connection
growth rate if the v6 connection quality is "ok" (that said, v4
connection growth rate is still very very high, and any help in
reducing it is advantageous to the CGN operator).

CB

---

From: Philip Homburg <[email-masked]>
Date: Sun, 19 Jun 2011 00:46:51 +0200

>reducing it is advantageous to the CGN operator).

Yes. If you do HE as 'just an IPv4 and an IPv6 connect at the same time' then
any increase dual stack support will never result in a reduction of the
number of IPv4 connection attempts.

So in my opinion, it is important that HE will avoid an IPv4 connect if
an IPv6 is likely to work well.