Subject: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go from here

From: Fred Baker <[email-masked]>
Date: Mon, 7 Feb 2011 19:50:49 -0800

Question for the assembled throng: We have been having an active discussion for the past coupe of weeks on Happy Eyeballs. What do people want to see happen in draft-wing-v6ops-happy-eyeballs-ipv6? I presume that we need an updated draft, and I have invited the posting of draft-ietf-v6ops-happy-eyeballs-ipv6. 

I think the most important question is: what needs to be done before we decide we are done with this draft? Note that there is a corollary draft in bmwg, which could probably also use your comments. 

http://tools.ietf.org/html/draft-baker-bmwg-testing-eyeball-happiness
  "Testing Eyeball Happiness", Fred Baker

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Feb 2011 23:11:22 -0500

The next step is for the working group to adopt it (IMHO).   And then Section 4.2.4 needs to be updated or deleted, and a security considerations section needs to be added, which would require some thought.

I would like to see all the references to threads taken out of section 4.1, because you don't need threads to implement happy eyeballs.   It should just be stated in terms of scheduling of events and receipt of results.

I've already stated a preference for a non-heuristic solution, where you just try everything at once.   I think a heuristic solution that tracks past performance is going to be difficult to implement, and ultimately won't see wide implementation.   However, I realize that there are strong arguments in favor of using heuristics as well.   I don't think we came to any consensus on this point.

One way or another, we ought to try to make progress on this work.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 7 Feb 2011 20:41:58 -0800

On Mon, Feb 7, 2011 at 7:50 PM, Fred Baker <[email-masked]> wrote:
> Question for the assembled throng: We have been having an active discussion
> for the past coupe of weeks on Happy Eyeballs. What do people want to see
> happen in draft-wing-v6ops-happy-eyeballs-ipv6? I presume that we need an
> updated draft, and I have invited the posting
> of draft-ietf-v6ops-happy-eyeballs-ipv6.
> I think the most important question is: what needs to be done before we
> decide we are done with this draft? Note that there is a corollary draft in

Is it possible that happy eyeballs is not feasible to implement within
the short time frame that it may be useful?  A few weeks back there
was a lively implementation discussion.  I am not an expert in this
area, but it looked like there was a lot of disagreement to me.  We
don't have to agree on how to implement it, but it would be
interesting to know the level of confidence that i can and will be
implemented.

I personally do not care for these happyeyeballs issues ... i find the
problem set further entrenches me into the single stack camp.

Cameron

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 Feb 2011 11:09:28 +0100

Le 8 févr. 2011 à 04:50, Fred Baker a écrit :

> Question for the assembled throng: We have been having an active discussion for the past coupe of weeks on Happy Eyeballs.

> What do people want to see happen in draft-wing-v6ops-happy-eyeballs-ipv6?

IMHO, this document makes a lot of sense, and its becoming an RFC asap is most useful.

Yet, I wonder whether it should better be informational than standards track.

The reason is that it only concerns implementation in hosts, and that many variants are possible.
Describing what the proposed technique solves is IMHO both important and sufficient.
OS vendors will continue to decide what to do, without any particular variant being considered the standard.

Regards,
RD

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Feb 2011 09:01:31 -0500

On 2011-02-07 23:41, Cameron Byrne wrote:
> the short time frame that it may be useful?

Even in a pure IPv6-only world, happy eyeballs would still be useful.
When a name resolves to multiple addresses, trying them in parallel has
advantages over trying them in sequence.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Erik Kline <[email-masked]>
Date: Tue, 8 Feb 2011 14:11:39 +0000

> advantages over trying them in sequence.

Even is takes 2 years to get out there and broadly adopted by applications /
OSes, does anyone think that IPv4 will be virtually eliminated by the 2 year
mark?  I suppose I could be (pleasantly) surprised, but...

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Feb 2011 09:18:18 -0500

On 2011-02-07 22:50, Fred Baker wrote:
> decide we are done with this draft?

IMHO, we need to decide whether we want to recommend happy eyeballs or
not. There were concerns about it breaking determinism, breaking
prioritization, etc. Are these issues "deal-breakers", or can happy
eyeballs be modified to fix/mitigate them?

Simon

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 08:36:17 -0600

On 2/7/2011 10:11 PM, Ted Lemon wrote:
> I've already stated a preference for a non-heuristic solution, where you just try everything at once.

The problem with that outside of server load is the IPv4 CGN load as we 
move into a more IPv6 world. I haven't had time to fully read the draft, 
but I do hope that it properly closes all channels it won't use for the 
sake of CGN tables.

Jack

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Feb 2011 06:39:45 -0800

> eyeballs be modified to fix/mitigate them?

</chair>
Speaking strictly for myself, I think the determinism and prioritization (by which I presume you meant RFC 3484) were solutions to a problem that Arifumi et al (draft-ietf-6man-rfc3484-revise) have been very clear remains unfixed. Happy Eyeballs is a different and (IMHO) better fix for that problem. The problem is that if a system has multiple addresses (multiple IPv6 addresses, IPv4 along with IPv6, or multiple IPv4) and that path associated with one is broken (failure, filter, whatever), and if we agree that ultimately the objective is to open a session with that system, then we need to quickly identify an address pair that works in the context of the actual working path and the various routing policies enacted along it. From my perspective, RFC 3484 and its bis should be about the order in which addresses are tried, but we also need to deal with the failure cases, which H.E. points out remain broken.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 09:40:04 -0500

> eyeballs be modified to fix/mitigate them?

Happy Eyeballs as written actually doesn't break determinism, because it prefers the means of connection that worked last time.   I argued against this last night because I couldn't figure out a good way to implement it, but sometime last night it sunk in to me what problem the preference algorithm in Happy Eyeballs was meant to solve, and I realized that it isn't as hard to implement as I'd assumed (there's no need to implement host-wide state).

I think you're right that we do need to decide whether to recommend Happy Eyeballs.   I do not think there are any deal-breakers.   I think there are a few tweaks needed to the draft before it's done, but we are on the right track.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 09:42:40 -0500

On Feb 8, 2011, at 9:36 AM, Jack Bates wrote:
> The problem with that outside of server load is the IPv4 CGN load as we move into a more IPv6 world. I haven't had time to fully read the draft, but I do hope that it properly closes all channels it won't use for the sake of CGN tables.

Okay, that's an excellent argument for not deploying CGNs without parallel IPv6 connectivity.   I don't think it says anything about Happy Eyeballs, though.   Since typically you'd be trying an IPv4 and an IPv6 connection in parallel, the total state maintained by the CGN ought to be the same--just the IPv4 part.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 09:12:47 -0600

On 2/8/2011 8:42 AM, Ted Lemon wrote:
> Okay, that's an excellent argument for not deploying CGNs without
> parallel IPv6 connectivity.   I don't think it says anything about
> Happy Eyeballs, though.   Since typically you'd be trying an IPv4 and
> an IPv6 connection in parallel, the total state maintained by the CGN
> ought to be the same--just the IPv4 part.
>

You still have to properly close the connections. A proper IPv4 
connection through CGN answers the request, transmits data, and then 
closes. You will turn TCP into UDP if you don't close the connection 
properly so that the CGN can remove the entry.

Also, this has nothing to do with IPv6 connectivity while running a CGN. 
Happy eyeballs will happily use both protocols at the same time.

Jack

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 10:38:03 -0500

On Feb 8, 2011, at 10:12 AM, Jack Bates wrote:
> You still have to properly close the connections. A proper IPv4 connection through CGN answers the request, transmits data, and then closes. You will turn TCP into UDP if you don't close the connection properly so that the CGN can remove the entry.

Are you proposing that I might somehow just leave the connection dangling open, or something else?   Even in the case where I leave the socket open, the load is the same as without happy eyeballs, since no additional IPv4 connections have been opened.   But I don't even see how I'd do that--as soon as I have a valid connection, I'm going to close the socket, at which point the O.S. should start closing the connection, and that should delete the state from the NAT.

Can you expand on the failure mode you're concerned about here?

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 09:46:59 -0600

On 2/8/2011 9:38 AM, Ted Lemon wrote:
> Are you proposing that I might somehow just leave the connection
> dangling open, or something else?   Even in the case where I leave

Every case I've seen discussing happy eyeballs implementation has 
pointed out that the modification needs to be made in the stack itself, 
so the application wouldn't be closing the socket, as the application 
would have a single socket.

Jack

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Feb 2011 10:49:29 -0500

> pointed out that the modification needs to be made in the stack itself,

That would be wrong. Happy eyeballs should define externally-observable
host behaviour, not implementation details.

Simon

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 10:04:04 -0600

> advantages over trying them in sequence.

Correct me if I'm wrong, but where does it say that you should connect 
to ALL addresses within a family?

Also, I'd prefer the round robin effect back, personally.

Jack

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 11:04:06 -0500

On Feb 8, 2011, at 10:46 AM, Jack Bates wrote:
> Every case I've seen discussing happy eyeballs implementation has pointed out that the modification needs to be made in the stack itself, so the application wouldn't be closing the socket, as the application would have a single socket.

Then you haven't been following the discussion very closely, because that's certainly not how I would propose to implement happy eyeballs, nor is it how the happy eyeballs draft proposes to implement it (although it does propose a different implementation than I would).

I think Fred suggested a library or system call called "connect_to_name" that someone may have suggested would take a socket descriptor as an input.  I would agree that that's the wrong way to solve the problem.   But Fred's solution works fine as long as connect_to_name *returns* the socket that connected, and takes no sockets as input.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Feb 2011 11:10:05 -0500

> to ALL addresses within a family?

You're right. The text should make this explicit. Adding an example with
multiple IPvX addresses would also be nice.

> Also, I'd prefer the round robin effect back, personally.

With appropriate randomization and (small) delay between connection
attempts, it won't go away.

Simon

---

From: Javier Ubillos <[email-masked]>
Date: Tue, 08 Feb 2011 17:12:56 +0100

> I think Fred suggested a library or system call called "connect_to_name" that someone may have suggested would take a socket descriptor as an input.  I would agree that that's the wrong way to solv…

For what it's worth, we are currently working on a happy-eyeballs
implementation for name-based sockets.
It takes a name (FQDN) as an input, and provides a socket (AF_NAME).

It uses "normal" BSD-semantics. The name is provided in an sockaddr
struct (sockaddr_name to be specific).

The application opens up a single socket. THe socket in turn tries two
subsockets (one for each address family). And whichever is _not_ chosen
is gracefully closed (RST).

// Javier

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: james woodyatt <[email-masked]>
Date: Tue, 08 Feb 2011 08:22:40 -0800

This comment reminds me strongly of an aphorism the great Canadian science fiction author William Gibson coined: "the street find its own uses for things."

Operators who expect even well-intentioned applications to be fair in their dealings with scarce resources in subscriber aggregating NAT gateways, to say nothing of the malicious applications, are whistling past a graveyard.

In this particular case, we can expect that happy-eyeballs implementations will more often than not close unused connection attempts in an orderly fashion, but hosts and networks get interrupted all the time in the real world, and exceptions will be frequent. I wouldn't want to be swimming against that tide.

--jhw (sent from my phone)

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 10:23:15 -0600

> attempts, it won't go away.

Actually, some address selection implementations completely broke it. 
See google concerning Vista and DNS.

Jack

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 11:28:28 -0500

> In this particular case, we can expect that happy-eyeballs implementations will more often than not close unused connection attempts in an orderly fashion, but hosts and networks get interrupted al…

It sounds like you're saying CGN can't work.   :)

(Although, to be fair, I will reiterate that in the worst-case scenario happy eyeballs as currently documented presents no more load to CGN than non-happy-eyeballs, and in the usual case it presents less load.)

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Feb 2011 06:54:31 +1030

On Tue, 8 Feb 2011 11:28:28 -0500

> (Although, to be fair, I will reiterate that in the worst-case scenario happy eyeballs as currently documented presents no more load to CGN than non-happy-eyeballs, and in the usual case it present…

CGNs will have to be robust against this sort of thing anyway. As they
maintain connection or traffic driven state, they'd be vulnerable to
DoSes if they don't. I'd expect total active connections and possibly
connection set up rate limits will be applied on a per downstream
client basis.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Feb 2011 09:32:54 +1300

> mark?  I suppose I could be (pleasantly) surprised, but...

We've needed something like happy eyeballs for many years
and we will continue needing it for, oh, let me take a SWAG,
another ten years at least.

I am in favour of adopting this and getting it out as Informational
ASAP - it really isn't necessary to sweat over making it normative,
because the real work is in getting it into half a dozen key operating
systems.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Feb 2011 07:04:54 +1030

On Tue, 8 Feb 2011 09:40:04 -0500

> I think you're right that we do need to decide whether to recommend Happy Eyeballs.   I do not think there are any deal-breakers.   I think there are a few tweaks needed to the draft before it's do…

It's worth noticing that a few transport layer protocols are or
starting to look at doing this sort of thing "within" themselves,
specifically SCTP and multipath-TCP -

http://datatracker.ietf.org/wg/mptcp/charter/

So doing it across multiple protocol families and multiple transport
protocols is only really a generalisation of that idea. I therefore
think happy eyeballs is worth recommending. 

Regards,
Mark.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 15:37:15 -0500

> connection set up rate limits will be applied on a per downstream

Of course, functional CGN that doesn't produce random dropped connections is essentially antithetical to DoS attack avoidance.   So the upshot of what you've said, with which I agree, is that CGN is not going to be a satisfactory solution, and that we'd bloody well better be able to offer IPv6 as an alternative.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 15:05:42 -0600

On 2/8/2011 2:37 PM, Ted Lemon wrote:
> Of course, functional CGN that doesn't produce random dropped
> connections is essentially antithetical to DoS attack avoidance.   So
> the upshot of what you've said, with which I agree, is that CGN is
> not going to be a satisfactory solution, and that we'd bloody well
> better be able to offer IPv6 as an alternative.

Which in turn defeats the purpose of happy eyeballs. That's the problem. 
LSN is horrid. It will force people into IPv6 connectivity quickly to 
avoid the brokenness of LSN. In doing so, it defeats the necessity of 
happy eyeballs. In 2 years (when we'd expect a large enough deployment 
of happy eyeballs implementations), IPv4 will be isolated pockets of 
deadness.

Jack

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Feb 2011 16:19:13 -0500

On Feb 8, 2011, at 4:05 PM, Jack Bates wrote:
> Which in turn defeats the purpose of happy eyeballs. That's the problem. LSN is horrid. It will force people into IPv6 connectivity quickly to avoid the brokenness of LSN. In doing so, it defeats the necessity of happy eyeballs. In 2 years (when we'd expect a large enough deployment of happy eyeballs implementations), IPv4 will be isolated pockets of deadness.

If that turns out to be true, then the small effort spent on happy eyeballs will be less valuable than we'd anticipated.   If it turns out not to be true, then the work on happy eyeballs will have been worthwhile.   History is not smiling on people who anticipated rapid IPv6 ubiquity; I see no reason to assume that it will suddenly start smiling in the next two years.

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Feb 2011 07:51:10 +1030

On Tue, 08 Feb 2011 15:05:42 -0600

> of happy eyeballs implementations), IPv4 will be isolated pockets of 

It still provides benefits in a pure IPv6 scenario. Mobile and
multi-homed hosts are becoming common (i.e. smartphones, laptops etc.).
At any time, there may be multiple possible avenues for successful
connectivity to a destination (e.g. via active wired, wifi and 3g
interfaces). Trying all of them in parallel, rather than sequentially,
provides the best chance of success within a shorter time frame.

I'm reminded a bit of the John Gilmore quote -

"The Net interprets censorship as damage and routes around it."

It seems to me that networked application developers have
somewhat similar motives. Their fundamental goal and motive is to have
their application communicate, so if there is a way for that to happen,
they'll pursue mechanisms within their applications that will provide
it. NAT traversal mechanisms like Skype's supernode model, or using
HTTP as a substrate for more general communications than pure HTML are
examples. These mechanisms are better placed lower in both the software
and network stack so they are more widely available, re-implemented
far less often, likely to be less buggy through far more common use and
will be more predictable to troubleshoot. For those reasons I'm glad to
see SCTP is one of the candidate transport protocols in the happy
eyeballs draft.

Regards,
Mark.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 15:30:00 -0600

On 2/8/2011 3:19 PM, Ted Lemon wrote:
>> Which in turn defeats the purpose of happy eyeballs. That's the
>> problem. LSN is horrid. It will force people into IPv6 connectivity
>> quickly to avoid the brokenness of LSN. In doing so, it defeats the
>> necessity of happy eyeballs. In 2 years (when we'd expect a large
>> enough deployment of happy eyeballs implementations), IPv4 will be
>> isolated pockets of deadness.
>
> If that turns out to be true, then the small effort spent on happy
> eyeballs will be less valuable than we'd anticipated.   If it turns
> out not to be true, then the work on happy eyeballs will have been
> worthwhile.   History is not smiling on people who anticipated rapid
> IPv6 ubiquity; I see no reason to assume that it will suddenly start
> smiling in the next two years.
>

Money. It's all about the money. That is why IPv6 has not even had 
market pressure until recently.

Don't get me wrong. I appreciate the work on happy eyeballs, and it's 
still not a bad idea to push. If we don't need it, we will all be happy. 
If we do need it, we'll be thankful for it being there.

Jack

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 15:36:24 -0600

> provides the best chance of success within a shorter time frame.

Where is this provided for in the draft? I keep hearing people state 
things about happy eyeballs that don't appear to be in the draft. The 
draft seems to support connecting to an IPv4 address and an IPv6 address 
and seeing which works. It doesn't appear to support connecting out 
every combination of IPv6 destination/Source combination.

Jack

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Feb 2011 13:41:18 -0800

> The problem with that outside of server load is the IPv4 CGN load as we move into a more IPv6 world. I haven't had time to fully read the draft, but I do hope that it properly closes all channels i…

To my understanding, it does; it closes the relevant socket or sub-socket, which results in a RST.

That said, imagine it didn't. The Happy Eyeballs model would result in a SYN Attack, which is to say that the receiving host would see more SYNs than sessions it actually used. That would have the effect of consuming TCB slots unproductively.

We solved SYN attacks a long time ago. Most if not all host implementations maintain a doubly linked list of TCBs; when a datagram is handed to a TCB, the TCB is removed from the list and enqueued at the end. Net effect, the TCB at the head of the list is the least recently used TCB. In the event that the system runs out of TCBs and receives a new SYN, it removes and re-uses the TCB at the head of the list. Voila, SYN attacks are now ineffective.

And by the way, this is consistent with the way many http/https services work. If you use a pipelined TCP, rather than close a session (FIN, FIN-ACK, ACK) or drop it (FIN, RST), they simply leave it open. If the web application comes back with another GET, so be it, and if not, the TCB eventually gets subsumed by the SYN Attack logic.

I don't see the down side of Happy Eyeballs in this context, even if it doesn't close the redundant sessions.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 15:49:24 -0600

> I don't see the down side of Happy Eyeballs in this context, even if it doesn't close the redundant sessions.

LSN in-betweens may not be so friendly. They will probably establish 
connection limits, and start failing connections when those limits are 
reached. This would pose problems for happy eyeballs if it doesn't 
properly handle connections.

Which as previously stated, the discussed implementation models current 
do send RST.

Jack

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 22:58:55 +0100

> it doesn't close the redundant sessions.

I'm not really into TCP SYN attack mitigation strategies, but from a LSN
scenario perspective, it would tie up (LSN-)central resources. That is:
NAT table entries and - possibly worse - outside ports. Every open or
half open TCP connection would require a port mapped on the NAT outside,
and this is a somewhat critical resource pool. There isn't much
(well/publicly known) experience about that yet. What we _do_ know is
that we want to ideally avoid short-living superfluous NAT sessions
(impacts connection setup rate scaling on LSN) and reallyreally avoid
a lot of long-living idle sessions binding session table entries AND
outside LSN pool port numbers.

They way I understand H.E. we cannot avoid the short-living "probe"
connections (it's the basic operating model). But we need to make sure
that any implementation really closes off all unused connections
properly so session/port resources are freed up again as quickly as
possible. How big the problem would be is difficult to guesstimate.

Best regards,
Daniel

-- 
-- CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Feb 2011 14:31:13 -0800

> possible. How big the problem would be is difficult to guesstimate.

No problem.  

Before replaying to Jack's previous message, I verified that I knew what I was talking about. I have a largish number of sites that I monitor daily, and have a little script that does that. I took said list of sites, cleared my web cache, started tcpdump, opened each of those URLs, closed tcpdump, and then did a bit of analysis. In the following, stealth-10-32-244-222.cisco.com is my computer, which is a Mac running MacOSX 10.6.6; the browser I used was Google Chrome.

I have 239 TCP sessions in total, some of which were IPv4 and some were IPv6, and some of which were pretty short and some were pretty long.

I saw a number of sessions for which the final few messages were per RFC 793:

12:48:41.728730 www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [.],
12:48:41.733051 stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [.],
12:48:41.733447 www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [.],
12:48:41.733450 www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [FP.],
12:48:41.733471 stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [.],
12:48:41.733480 stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [.],
12:48:41.734286 stealth-10-32-244-222.cisco.com.65535->www-14.nist.gov.http [F.],
12:48:41.872167 www-14.nist.gov.http->stealth-10-32-244-222.cisco.com.65535 [.],

I saw several that appeared to have closed the socket. When they received a message, they replied with a RST.

12:48:56.044372 stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [P.],
12:48:56.126974 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [P.],
12:48:56.127053 stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [.],
12:48:56.133520 stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [F.],
12:48:56.244610 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [.],
12:48:56.244681 stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [.],
12:48:56.245276 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [P.],
12:48:56.245330 stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [R],
12:48:56.245922 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49182 [F.],
12:48:56.245935 stealth-10-32-244-222.cisco.com.49182->xfe-rcd3.cisco.com.https [R],

I saw a whole lot that simply let the session lie. The following is an entire https session. Where's the FIN or the RST?

12:48:59.432947 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [S],
12:48:59.517297 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [S.],
12:48:59.517352 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.],
12:48:59.517752 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.],
12:48:59.605263 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [.],
12:48:59.608952 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.],
12:48:59.609010 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.],
12:48:59.609664 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.],
12:48:59.609720 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.],
12:48:59.610269 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.],
12:48:59.610342 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.],
12:48:59.611640 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.],
12:48:59.611920 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.],
12:48:59.612054 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.],
12:48:59.699125 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [.],
12:48:59.705711 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.],
12:48:59.705783 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.],
12:48:59.706462 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.],
12:48:59.706519 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.],
12:48:59.706742 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [P.],
12:48:59.797729 xfe-rcd3.cisco.com.https->stealth-10-32-244-222.cisco.com.49184 [P.],
12:48:59.797791 stealth-10-32-244-222.cisco.com.49184->xfe-rcd3.cisco.com.https [.],

Yes, those are in fact the same two machines as the previous.

If you're worried about Happy Eyeballs tripping up CGN, I submit that we have a lot more to think about than Happy Eyeballs.

---

From: Jack Bates <[email-masked]>
Date: Tue, 08 Feb 2011 16:39:54 -0600

On 2/8/2011 4:31 PM, Fred Baker wrote:
> If you're worried about Happy Eyeballs tripping up CGN, I submit that
> we have a lot more to think about than Happy Eyeballs.

I won't argue the point. There are a lot of things which don't play 
friendly with LSN, and even more things that LSN doesn't play friendly with.

However, happy eyeballs can trip up an LSN when normal policy selection 
would have connections going via IPv6. The last resting piece of LSN is 
to handle v4 only connectivity while most traffic goes via IPv6. Happy 
Eyeballs can cripple this final picture if it isn't careful.

Jack

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 8 Feb 2011 23:46:53 +0100

On Tue, Feb 08, 2011 at 02:31:13PM -0800, Fred Baker wrote:
> I saw a whole lot that simply let the session lie. The following is an
> entire https session. Where's the FIN or the RST?

:-(

I guess xfe-rcd3 is a HTTP proxy? Might it be a proxy-specific behaviour
which wouldn't be relevant in the LSN scenario, as the LSN isn't between
the endpoints and a HTTP proxy, but endpoints directly connecting to
HTTP servers thru the LSN? Do you see the same effects when not using a
web proxy?

> we have a lot more to think about than Happy Eyeballs.

We do. I was/am worried about making the problem even bigger by
advocating detrimental behaviour (or more precisely: not advocating
friendly behaviour).

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 9 Feb 2011 07:37:01 +0100

> On Tue, Feb 08, 2011 at 02:31:13PM -0800, Fred Baker wrote:
<snip>
> advocating detrimental behaviour (or more precisely: not advocating

I think you might overlook another _maybe_ more important point to
consider. This might not be technical but more timedepending.
Will Happy Eyeballs get out in time or not?

I see people trying to get things perfect, that's great but takes time,
are we sure there is enough time to get things perfect?
Would a 90% solution work NOW? And in ~6-12months time get a
version 2 out that is 98%?

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 8 Feb 2011 22:42:28 -0800

That's largely a question of testing and service updates. Apple and Microsoft, at least for their major applications, could have it in their next service packs if they chose to.

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 9 Feb 2011 08:27:23 +0100

to correct/update my own post - the maybe most important question,
Do we think its usefull?

I would say yes. And it can't do much harm that can't be fixed in the next
update from any OS provider... ~30days of pain/learning how to do it
correct, 90% vs 98%.

--- Roger J ---

-- 

Roger Jorgensen           |

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Feb 2011 10:17:54 +0100 (CET)

> version 2 out that is 98%?

As I said earlier happy eyeball idea requires to rewrite every application 
which is relying on socket calls. The socket is an endpoint of a 
bidirectional inter-process communication flow. The most important 
differentiator here is the flow. In happy eyeball you might have dozens of 
flows initially, which is eventually reduced to 1 flow. This asynchronous 
connection setup, selective tear down, has to have different API than the 
current socket API, something like:

int tcp_connect(const char *host, const char *serv)

It has some early implementation without the asynchronous connection 
setup and selective tear down from W. Richards Stevens:
http://www.kohala.com/start/unpv12e.html

---

From: Simon Perreault <[email-masked]>
Date: Wed, 09 Feb 2011 09:36:06 -0500

> Will Happy Eyeballs get out in time or not?

Happy eyeballs is already out. There are implementations out there that
predate the draft. The draft is actually documenting and encouraging
existing practice.

Simon

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 14:48:21 +0000

I very recently tested web browsers on broken IPv6 access with: Symbian^3, Android 2.3.1, iOS4 4.2.1, OS/X 10.6.6, Windows 7, Ubuntu 10.10 and Maemo5.

None of these had happy eyeballs at least for the browsers use-case.

Could you point me to this implementation so that I can give it a try as well?

Thanks,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Simon Perreault
> Sent: 09. helmikuuta 2011 16:36
> To: [email-masked]
> Subject: Re: [v6ops] draft-wing-v6ops-happy-eyeballs-ipv6 - where to go
> from here
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 09 Feb 2011 10:02:56 -0500

> None of these had happy eyeballs at least for the browsers use-case.

That's right. None of them do it as far as I know.

> Could you point me to this implementation so that I can give it a try as well?

Apple's core foundation API:
http://www.ietf.org/proceedings/72/slides/plenaryw-6.pdf
http://www.ietf.org/proceedings/79/slides/nbs-8.pdf

libevent also implements something very similar.

Other people have mentioned Java stuff on this mailing list, but I don't
know anything about that.

Simon

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Feb 2011 17:33:58 +0100 (CET)

> libevent also implements something very similar.

Unfortunately libevent() evdns extension was written very badly. The IP 
address is represented in long int (32 bit).

Best Reagrds,
 	Janos Mohacsi

---

From: Simon Perreault <[email-masked]>
Date: Wed, 09 Feb 2011 11:36:13 -0500

> address is represented in long int (32 bit).

I believe you are talking about an old version. The newest ones do not
do that.

Simon

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Feb 2011 18:15:44 +0100 (CET)

> I believe you are talking about an old version. The newest ones do not

Yes, I am talking about the stable version. You are right the new 
libevent2, which is currently the alpha version has ipv4 and ipv6 address 
resolution functions. However the

int evdns_base_nameserver_add ( struct evdns_base * base,
 		unsigned long int  	address
 	        )

function should be deprecated in favor of
int evdns_base_nameserver_ip_add 	( 	struct evdns_base *  base,
 		const char *  	ip_as_string
 		)

Best Regards,
 	Janos Mohacsi

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Feb 2011 10:29:16 +1300

On 2011-02-10 04:02, Simon Perreault wrote:
..
> know anything about that.

Java doesn't really do this; what it does (afaik) is hide the address
family from the application programmer, who only uses the FQDN. But
it doesn't do all the happiness stuff. Actually if the Java runtime could
do so, it would be a great leap forward IMHO.

   Brian