Subject: [v6ops] Happy Eyeballs

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 05:09:34 -0600

Let me invite review and comment on draft-wing-v6ops-happy-eyeballs-ipv6. Pursuant to the survey outcome, I have asked Dan and Andrew to repost as a working group document. That said, I personally feel that it is close to being ready to pass along. 

The question, apart from any edits that folks feel are needed, would be "at what status". Would we want to call this "informational" or "best current practice"?

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 3 Dec 2010 12:15:48 +0100

I would be inclined to bring this to BCP as its more than just a
'informative' paper.
On the other hand I have no clue on the requirements for a BCP instead
of informative for the IETF

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fred Baker (fred)
Sent: Friday, December 03, 2010 12:10 PM
To: IPv6 Ops WG
Subject: [v6ops] Happy Eyeballs

Let me invite review and comment on
draft-wing-v6ops-happy-eyeballs-ipv6. Pursuant to the survey outcome, I
have asked Dan and Andrew to repost as a working group document. That
said, I personally feel that it is close to being ready to pass along. 

The question, apart from any edits that folks feel are needed, would be
"at what status". Would we want to call this "informational" or "best
current practice"?
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 06:47:47 -0600

On Dec 3, 2010, at 5:15 AM, Gunter Van de Velde (gvandeve) wrote:

> I would be inclined to bring this to BCP as its more than just a 'informative' paper. On the other hand I have no clue on the requirements for a BCP instead of informative for the IETF

I have attached the verbiage from RFC 2026. An "informative" document is something we publish, end of discussion. A BCP is a standard, but instead of standardizing a technology (as we have done, for example, with IPv6) it standardizes a policy, practice, or procedure - we are defining and ratifying "the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some ... function".

I would argue that the statement of principle that Happy Eyeballs proposes is that "even in a complex environment, what the Internet should deliver to its user is simple: convenient and speedy access to the intended remote process or data." It applies that principle in the specific case, and suggests one particular approach to achieving that.  To my mind, the code design is more of a proof of concept than "the one true way to perform this function"; one could imagine a variety of possible implementations, from "send all the SYN/INIT messages simultaneously", as Randy Stewart reports that some Linux SCTP code does, to "send them sequentially in parallel at some rate". But in specifying this, we would be saying that we approve of the principle and we like the technical approach.

5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.

   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks.  However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.
   While these guidelines are generally different in scope and style
   from protocol standards, their establishment needs a similar process
   for consensus building.

   While it is recognized that entities such as the IAB and IESG are
   composed of individuals who may participate, as individuals, in the
   technical work of the IETF, it is also recognized that the entities
   themselves have an existence as leaders in the community.  As leaders
   in the Internet technical community, these entities should have an
   outlet to propose ideas to stimulate work in a particular area, to
   raise the community's sensitivity to a certain issue, to make a
   statement of architectural principle, or to communicate their
   thoughts on other matters.  The BCP subseries creates a smoothly
   structured way for these management entities to insert proposals into
   the consensus-building machinery of the IETF while gauging the
   community's view of that issue.

   Finally, the BCP series may be used to document the operation of the
   IETF itself.  For example, this document defines the IETF Standards
   Process and is published as a BCP.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Dec 2010 08:55:09 +1300

1. I am a fan of this document and don't have much to add.
Perhaps it would benefit from an appendix talking
about existing run-time packages that do at least part of
what is needed (Java? libevent? others?). Actually, sample
code would also be wonderful.

2. I think we'd need a bit of running code experience before
it should be a BCP.

Regards
   Brian Carpenter

---

From: Simon Perreault <[email-masked]>
Date: Fri, 03 Dec 2010 16:16:24 -0500

> Let me invite review and comment on draft-wing-v6ops-happy-eyeballs-ipv6. Pursuant to the survey outcome, I have asked Dan and Andrew to repost as a working group document. That said, I personally…

Overall I really like this document.

One comment I would have is that the term "thread" should be avoided. In 
most circumstances it is better to avoid threads and use non-blocking 
I/O instead. Section 4.2.7 on thread safety should be removed since 
thread-safety is a non-issue when using non-blocking I/O. Text dealing 
with threads should be reformulated so that it applies to any kind of 
implementation. Threads or no threads is an implementation detail. This 
document should focus on what goes on the wire. (And there are ways 
other than threads and non-blocking I/O to achieve the same (e.g. 
coroutines).)

Simon

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Dec 2010 17:04:49 -0600

Any reason why we excluded the document for Standards Track?  My guess
is then the document gets delayed and we need hosts to implement such a
proposal like yesterday?  Also, the document seems to include some
protocol related details and hence the document could also be reviewed
by 6man or any IETF WG that deals with protocols?

I do support the general idea of the document - after I have completed
reading the full documents I may have more comments.  

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fred Baker (fred)
Sent: Friday, December 03, 2010 6:10 AM
To: IPv6 Ops WG
Subject: [v6ops] Happy Eyeballs

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Dec 2010 17:08:49 -0600

Also, to the authors of this document - thanks much for putting this one
together!  It's a much needed document.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Friday, December 03, 2010 6:05 PM
To: Fred Baker (fred); IPv6 Ops WG
Subject: Re: [v6ops] Happy Eyeballs

Thanks,

Hemant

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 17:11:05 -0600

By "standards track", do you mean "proposed/draft/standard"?

BCP is a variety of standard, used for policies and other "we think this is the way to do it" standards. The P/D/F track is used for protocols, in which one might have a bug to fix or might want to go through a huge interoperability check. The issue in Happy Eyeballs is not interoperability, it's optimality.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Dec 2010 17:15:08 -0600

I meant standard like the same status as say, RFC 4861 (just a random
pick of an RFC).  However, you guessed it right that even I thought the
"standard" track takes longer and more interoperability testing.  Thus
BCP is preferable to me vs. Informational.

Thanks,

Hemant

-----Original Message-----
From: Fred Baker (fred) 
Sent: Friday, December 03, 2010 6:11 PM
To: Hemant Singh (shemant)
Cc: IPv6 Ops WG
Subject: Re: [v6ops] Happy Eyeballs

BCP is a variety of standard, used for policies and other "we think this
is the way to do it" standards. The P/D/F track is used for protocols,
in which one might have a bug to fix or might want to go through a huge
interoperability check. The issue in Happy Eyeballs is not
interoperability, it's optimality.

---

From: Stig Venaas <[email-masked]>
Date: Fri, 03 Dec 2010 15:39:25 -0800

> BCP is preferable to me vs. Informational.

While I think the approach is useful, I have some concerns about what
values of P are useful defaults. I'm a bit nervous of using say 0 as a
default, possibly causing a lot more connections being created and more
state in middleboxes. I don't know for sure whether this is an issue,
but until there is more experience with this, I feel BCP is a bit too
strong. Do we know at this point that the algorithm really is the best
current practice? I would also say that it is not current practice. I
feel informational is more appropriate for now.

I might support it being a BCP depending on the amount of field testing.

That said, I do support adopting the document.

Stig

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 3 Dec 2010 15:48:15 -0800

I support adoption of this document. 

--julien

> Of Fred Baker
> Sent: Friday, December 03, 2010 3:10 AM
> To: IPv6 Ops WG
> Let me invite review and comment on draft-wing-v6ops-happy-eyeballs-
> ipv6. Pursuant to the survey outcome, I have asked Dan and Andrew to
> repost as a working group document. That said, I personally feel that
> it is close to being ready to pass along.
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 3 Dec 2010 21:15:24 -0600

Stig,

Thanks for reminding me that this approach is not common practice and
thus I agree with you that Informational to begin with would be
recommended.   I read the document and here are some of my
comments/observations.  

1. I have a cable access concentrator that has 50K hosts deployed, one
each behind 50K cable modems.  In such a network IPv6 ND and DHCPv6 or
SLAAC will function with a randomized start time.  Hence different cable
modem and hosts behind the modems will start their Internet access at
different times.  Thus Happy Eyeballs does not need to devise its own
randomized delayed start for its algorithm.  

2. For multiple interfaces, each interface has its own P value that
works independent of any other interface.  Why should this document care
any multiple interfaces?

3. How do we deal with one situation I contrived.  The network actually
only supports IPv6.  However the IPv6 network is very congested when the
v6 probe went out.  The v6 probe fails.  Thus the algorithm takes P
closer to zero and causes more probes to go out in an already congested
network.  Some more though is needed when P gets closer to zero.  Maybe
we'd randomize sending of the IPv6 probe for future times when P is
close to zero.

Again, I do support this document.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stig Venaas
Sent: Friday, December 03, 2010 6:39 PM
To: [email-masked]
Subject: Re: [v6ops] Happy Eyeballs

Stig

---

From: Carlos Martinez-Cagnazzo <[email-masked]>
Date: Mon, 6 Dec 2010 10:02:54 -0200

I support this document. It is a very much needed document.

Warm regards

Carlos

-- 
--
=========================
Carlos M. Martinez-Cagnazzo
http://cagnazzo.name
=========================

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 6 Dec 2010 16:28:50 +0100

> Overall I really like this document.

Me too.

> Text dealing with
> threads should be reformulated so that it applies to any kind of
> implementation.

Agreed.

Richard