Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs WGLC]

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sat, 01 Oct 2011 10:02:55 +0300

I won't focus on the MUST/MAY selection, but i see a point in Lorenzo's comment about 
non-deterministic behavior when there is no preference between IPv4 and IPv6.
So, if there is going to be an option/knob/switch, it should probably provide just two 
options : disable (use system's preference policy), enable (if system's policy prefers 
IPv6, give X preference to IPv6 vs IPv4).
Nevertheless, i'm wondering...There is already an option to disable IPv6 in Chrome and 
Firefox (and probably other applications). Would a HE switch make any useful difference to 
users (besides troubleshooting IPv6)?
Do we expect to abandon the IPv6 switch in the future and use the HE switch only?
btw, is the application IPv6 switch described somewhere as a MUST/MAY/etc?

--
Tassos

Teemu Savolainen wrote on 1/10/2011 08:25:
> I object MUST for configuration option, as for some class of hosts,
> like embedded systems, it is not always feasible to have such settings
> supported.
>
> Teemu
>
> Sent from my Windows Phone
> From: Brian E Carpenter
> Sent: 28.9.2011 3:16
> To: Jeroen Massar
> Cc: [email-masked]
> Subject: Re: [v6ops] On/off switch [draft-ietf-v6ops-happy-eyeballs
> WGLC]
> Marc,
>
> On 2011-09-28 02:57, Jeroen Massar wrote:
>> On 2011-09-27 15:53 , Marc Blanchet wrote:
>>> Le 2011-09-27 à 09:47, Marc Blanchet a écrit :
>>>
>>>>>> I would like to see a knob that would have the possible values as:
>>>>>> - default  (HE no pref between v4 or v6)
>>>>>> - v6 (HE does pref v6 by some minimal increment)
>>>>>> - off  (disable HE)
>>>>>>
>>>>>> The way to implement this might be:
>>>>>> - off: value = 65535
>>>>>> - default: value = 0
>>>>>> - v6: value = number of ms "advantage for ipv6"
>> [..]
>>
>>> btw, I can provide text if there is support in wg for this idea.
>> I would say that it is a great thing to add, but just an on/off is
>> already good enough from my POV.
> I agree; maybe on/off as a MUST and the ms of bias as a MAY?
>
> I don't see anybody opposing the general idea, anyway.
>
>     Brian
>
>> The above proposal would give the advantage to be able to easily
>> distribute a site-wide (given that one control all the hosts involved)
>> bonus for IPv6 in case a site is connected over a tunnel or other
>> mechanism which causes a bit more latency on the IPv6 side.
>>
>> The other way to counter that disadvantage is just delaying IPv4 packets
>> at the moment, but that is far from a proper solution.
>>
>> Greets,
>>   Jeroen
>>
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> 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: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Oct 2011 08:01:10 +1300

On 2011-10-01 20:02, Tassos Chatzithomaoglou wrote:
> I won't focus on the MUST/MAY selection, but i see a point in Lorenzo's

I can see the argument for a SHOULD, since some low end systems might
find such a switch to be a burden (but they might find the whole
of HE to be a burden, too).

> comment about non-deterministic behavior when there is no preference
> between IPv4 and IPv6.
> So, if there is going to be an option/knob/switch, it should probably
> provide just two options : disable (use system's preference policy),
> enable (if system's policy prefers IPv6, give X preference to IPv6 vs
> IPv4).
> Nevertheless, i'm wondering...There is already an option to disable IPv6
> in Chrome and Firefox (and probably other applications). Would a HE
> switch make any useful difference to users (besides troubleshooting IPv6)?

We would be very arrogant to answer that question; users are entitled
to decide what's useful to them. An HE switch is quite orthogonal to
an "ignore IPv6" switch; both are needed (and there should be an
"ignore IPv4" switch too, for completeness).

> Do we expect to abandon the IPv6 switch in the future and use the HE

Why do we care what users choose to do? It's their business.

> btw, is the application IPv6 switch described somewhere as a MUST/MAY/etc?

Not that I'm aware of. I assume it was implemented to help users
who were impacted by IPv6 connectivity issues. I've used it myself for
exactly that reason, in both Firefox and Thunderbird.

I wonder how many people on this list are running a dual stack desktop
or laptop device continuously?

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 1 Oct 2011 13:42:00 -0700

On Sat, Oct 1, 2011 at 12:01, Brian E Carpenter <[email-masked]
> wrote:

> of HE to be a burden, too).

Maybe. To the best of my knowledge neither of the current working
implementations (OS X and Chrome) provide a switch, so if the RFC is
supposed to cover "running code", then there is none that does this.

The Firefox implementation added an on/off switch when they discovered it
was not working, but since it's not working I don't think it qualifies as
"running code" at this point.

> "ignore IPv4" switch too, for completeness).

Actually, we wouldn't be arrogant, we'd be doing our job. The vast majority
of users don't *want* to decide, and it's our job as engineers to find
something that works.

> or laptop device continuously?

What do you mean by continuously? I have IPv6 at work, I have it at home,
and I have it when I go to conferences. I don't have it when I attach to the
shuttle wifi network, but if I don't work on the shuttle then I suppose it's
continuous. Why do you ask?

Cheers,
Lorenzo

---

From: Gert Doering <[email-masked]>
Date: Sun, 2 Oct 2011 10:59:21 +0200

Hi,

> or laptop device continuously?

All our corporate desktops and all my home machines are dual-stack all
the time.  (They need to do IPv6, and the alternatives are dual-stack or
NAT64 - and NAT64 does not yet make sense *for us*).

My laptop takes what it's fed - right now I'm typing this on an IPv4 only
3G link, and it has encountered IPv6-only networks, but most of the time 
it has dual-stack as well...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Oct 2011 09:00:15 +1300

On 2011-10-02 09:42, Lorenzo Colitti wrote:
> On Sat, Oct 1, 2011 at 12:01, Brian E Carpenter <[email-masked] wrote:
...
> What do you mean by continuously? 

I guess "normally" instead of "continuously" would be a better question, but
I have found situations (see below) where switching off IPv6 is better.

> I have IPv6 at work, I have it at home,

Genuine curiosity. Here we all are giving strong opinions about v6 operations,
so I was wondering how many of us actually use it daily. I was quite sure that
you (Lorenzo) did. I do, but I have to use a tunnel from home and have found that
when on travel in IPv4-only land, the performance penalty for the tunnel is
usually unacceptable. So my suggestion that HE should be biased towards IPv6
but not too much, and the suggestion that it should have an on/off switch, are
both based on personal experience.

On 2011-10-02 21:59, Gert Doering wrote:
...
> it has dual-stack as well...

Would you want HE by default *always*?

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 2 Oct 2011 14:34:09 -0700

On Sun, Oct 2, 2011 at 13:00, Brian E Carpenter <[email-masked]

> both based on personal experience.

If you ask me I'd say that you're doing it wrong. If you don't have IPv6
connectivity, then you don't have it, and setting up host-to-router tunnels
halfway across the globe is not really going to give it to you. It will just
give you a slow, unreliable surrogate, and you might as well use IPv4, since
it's going to be much better.

Fortunately, you are part of the extremely small minority that knows what
IPv6 is, and the small minority of those who is willing to go to personal
effort to set it up manually even when it leads to worse performance. You're
not the type of user happy eyeballs needs to cater to; you can take care of
yourself perfectly well.

> Would you want HE by default *always*?

I use Chrome all the time, and I never feel the need to turn it off. If I
want to find out if IPv6 is working, I can use ping and traceroute.

---

From: Randy Bush <[email-masked]>
Date: Mon, 03 Oct 2011 09:44:36 +0900

> Fortunately, you are part of the extremely small minority that knows
> what IPv6 is, and the small minority of those who is willing to go to
> personal effort to set it up manually even when it leads to worse
> performance. You're not the type of user happy eyeballs needs to cater
> to; you can take care of yourself perfectly well.

we build the superhighway.  we do not design it for people who like to
use their cars to run over their own or others' bodies.

randy

---

From: Gert Doering <[email-masked]>
Date: Mon, 3 Oct 2011 22:56:45 +0200

Hi,

> Would you want HE by default *always*?

Yes.

We've seen a few incidents where important dual-stack web sites were
unreachable over IPv6 (due to network mishaps), and the then-standard
behaviour "try via v6, timeout, try via v4" really annoyed some of my
colleagues enough that they turned off IPv6 in their browser (firefox,
at that time).

I want a bias for IPv6, because I believe in deterministic choices 
regarding v4/v6, and since everything in our network is identical for
IPv4 and IPv6, anything that doesn't have a bias (either way) will 
end up randomly chosing one or the other protocol, which is not a
desirable characteristic.

So if I were to decide, our office machines would get "HE with a small
bias for IPv6 [100-200 ms or such], on-by-default".  I wouldn't mind
having a knob to turn off HE (for troubleshooting), but then, for 
troubleshooting I usually use "telnet -4 ..." or "telnet -6 ..." to
force things manually...

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Oct 2011 17:22:59 -0400

> Would you want HE by default *always*?

What I don't want is more knobs on software that have to be set correctly in order for that software to work well over the Internet.

For the specific limited case of web browsers, I'm convinced that HE works better than default address selection rules, if not in every case, then in the vast majority of cases.  If a browser vendor wants to include a knob that lets the user turn it off, that's fine with me, but I don't think this should be required.  Every additional knob is something else that can potentially break and an increased burden on those providing service.   Whether a particular browser uses HE, or default rules, or a different algorithm, is a judgment best left to the browser vendor or whoever has to support that product.

Note that I see HE as having very narrow applicability.   There are lots of reasons that make it inapplicable for network software in general.  One of the reasons that I find HE acceptable for web browsers is that web browsers are updated very frequently these days both to add new features and to cope with newly identified security holes.   So if network conditions change such that HE no longer works well, or such that there are better methods of selecting a path between browser and server, the browsers can quickly evolve to support the new methods.   For other kinds of software that gets updated less frequently and/or has different usage patterns, HE would not be appropriate.  That doesn't mean that address selection is the right answer.

Bottom line, applications developers have to do whatever it takes to make their apps work well.  If the network doesn't work well enough that there can be a clean separation of layers (i.e. if it can't be trusted to route packets by itself), applications will  necessarily get involved.  But the results won't be pretty.

Keith

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 3 Oct 2011 18:13:21 -0400

Le 2011-10-03 à 16:56, Gert Doering a écrit :

> bias for IPv6 [100-200 ms or such], on-by-default".

that is what I suggested. (frankly, I think 100-200 ms is way too high.):

- slight advantage to IPv6. if we don't do that, ipv4 will always win.
- capability to change the bias
- capability to put HE at off.

Marc.

>  I wouldn't mind

---

From: Sander Steffann <[email-masked]>
Date: Tue, 4 Oct 2011 02:47:50 +0200

Hi Marc,

> - slight advantage to IPv6. if we don't do that, ipv4 will always win.

Probably :)  If the value is too low the choice between IPv4 and IPv6 will become unstable and unpredictable. If the value is too high then the potential impact on the user experience increases. The people implementing this will probably care 99% for the end-user and 1% about us network people (and they probably should: the end-users are their customers) so the choice needs to be a balance between 'helping ipv6 deployment' and 'not bothering/annoying the user'. Maybe 50-100 ms would be better than 100-200 ms, but I'll leave the exact numbers to people who know where the border is between an (almost) unnoticeable delay and a noticeable one.

> - capability to change the bias

Do you really think a lot of users/admins will start fine-tuning this? I doubt it...

> - capability to put HE at off.

I think most users wouldn't care though, and admins have ping/traceroute for debugging. Having that switch in about:config or in the Develop menu would be nice though for those of us who want 100% predictable behaviour. I certainly would appreciate it!

- Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Oct 2011 14:08:02 +1300

Sander,

> Probably :)  If the value is too low the choice between IPv4 and IPv6 will become unstable and unpredictable. If the value is too high then the potential impact on the user experience increases. Th…

Exactly. We need to be able to find the right point, and we will
only do so by experience; there is no way to know it in advance.

> Do you really think a lot of users/admins will start fine-tuning this? I doubt it...

Users? No, except for a few obsessives like me ;-)

Admins? Don't underestimate them. If you're providing images for a few
thousand desktops, this would just be one among hundreds of settings
that you might choose to adjust.

> I think most users wouldn't care though, and admins have ping/traceroute for debugging. Having that switch in about:config or in the Develop menu would be nice though for those of us who want 100%…

Exactly. And we aren't really talking about debugging - more about finding
the best performance point for a user who's complaining. I don't see
why having such a switch is contentious.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 3 Oct 2011 22:40:13 -0700

On Mon, Oct 3, 2011 at 18:08, Brian E Carpenter <[email-masked]

> why having such a switch is contentious.

I don't think the idea of having a switch is contentious. I do think that
saying applications MUST provide the switch is contentious.

---

From: Fred Baker <[email-masked]>
Date: Tue, 4 Oct 2011 21:42:49 +0800

On Oct 2, 2011, at 3:01 AM, Brian E Carpenter wrote:

> I wonder how many people on this list are running a dual stack desktop or laptop device continuously?

I for one run IPv6 on my laptop continuously. If I don't have IPv6 in the network I happen to be in, the predictable result occurs. But if I am at home, and the other day when I was in a certain locale, I ran IPv6, and I noticed because Firefox told me I was connecting to an IPv6 address.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 05 Oct 2011 09:19:40 +1300

> saying applications MUST provide the switch is contentious.

I would readily settle for SHOULD.

   Brian

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 4 Oct 2011 16:30:33 -0400

> I would readily settle for SHOULD.

agreed. Marc.

---

From: "t.petch" <[email-masked]>
Date: Wed, 5 Oct 2011 09:26:46 +0200

---- Original Message -----
From: "Marc Blanchet" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 04, 2011 10:30 PM

agreed. Marc.

I agree, too.  I think that modern systems presume far too much on behalf of a
user and those users who have the wit to understand how to improve their lot
should be allowed to do so.

Tom Petch

---

From: Fred Baker <[email-masked]>
Date: Wed, 5 Oct 2011 17:05:29 +0900

> Would you want HE by default *always*?

I'm a little perplexed by the question. Yes, I always want to have applications make connections quickly. Are you asking how badly I want to see IPv6 preferred?

If we're going to discuss a switch, it might be worthwhile saying precisely what we want the switch to do. 

To my small mind, the thing that defines and distinguished Happy Eyeballs is the concept of opening sessions with several different addresses in parallel as opposed to serially. A Happy Eyeballs implementation calls getaddrinfo(), gets a list of addresses associated with a name, and in some manner tries those addresses in parallel. It can and may try them all at once, although that's probably not to be recommended. It can and may initiate sessions with some cadence (eg firing off a new request every N ms), keeping open attempts in process even though it is also starting the next attempt, until one of the attempts becomes an open session. It can prefer IPv6 in some way, prefer IPv4 in some way, or have no preference.

To my small mind, turning off Happy Eyeballs turns off the parallelism. The implementation calls getaddrinfo(), gets a list of addresses associated with a name, and tries the addresses serially, waiting until the transport gives up on each attempt before trying the next.

To my small mind, we don't want to turn off happy eyeballs, ever.

What we might want to do is adjust parameters - specify the cadence with which attempts are made, try all of the IPv4 addresses before any of the IPv6 addresses, try all of the IPv6 addresses before any of the IPv4 addresses, alternate between architectures starting with IPv6, alternate between architectures starting with IPv4, or try something statistical in which we remember which addresses have a history of success and try them first, or simply never use IPv4 or never use IPv6.

What do you want the switch to do?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Oct 2011 11:39:40 +1300

Fred,

I want to be able to revert to RFC3484 (or RFC3484bis) behaviour.
Most likely, five munutes later I'd want to re-enable HE behaviour.

I want to do this because I'm trying to understand a performance issue.
If I identify HE as the source of the issue, then I would want to start
doing explicit pings and traceroutes on the address pairs concerned.

I'm doing all this, not because I'm a regular user, but because I'm
a techie called in to fix a problem.

I'd want the equivalent switch if shim6, sctp or mptcp were in use, too.
Anything that tries to be smart about address pair selection will confuse
diagnosis.

Regards
   Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 06 Oct 2011 07:47:00 +0900

> I want to do this because I'm trying to understand a performance

yet another ubergeek design corner

randy

---

From: John Mann <[email-masked]>
Date: Thu, 6 Oct 2011 14:59:23 +1100

Hi,

I support being able to switch back to RFC3484* behaviour.

> doing explicit pings and traceroutes on the address pairs concerned.

I'm not worried about HE being the source of the issue,
I am worried about HE hiding some issues.

HE parallelism is like having 2 fan belts fitted to you car in case one
breaks.
The trouble is that you can't tell when one breaks, only when they have both
broken.

Sometimes, you really do want to able to test if IPv6 is working,
not "IPv6 didn't work, but we changed to IPv4 so quickly you shouldn't
notice".
It is not always easy to track down all the web sites involved in rendering
a web page, and test them one by one with dig, ping6, telnet -6 to see if
their IPv6 is working.

And, when doing inbound port scans e.g.
   http://www.employees.org/~dwing/scanme.cgi
I want to be able to "test IPv6", not "test the fastest protocol"
nor "test the protocol chosen by Mac OS X's complicated scheme".

[ Also swap IPv6 <=> IPv4 in the above. ]

Thanks,
    John

> > I'm a little perplexed by the question. Yes, I always want to have
> applications make connections quickly. Are you asking how badly I want to
> see IPv6 preferred?
> >
> > To my small mind, the thing that defines and distinguished Happy Eyeballs
> is the concept of opening sessions with several different addresses in
> parallel as opposed to serially. A Happy Eyeballs implementation calls
> getaddrinfo(), gets a list of addresses associated with a name, and in some
> manner tries those addresses in parallel. It can and may try them all at
> once, although that's probably not to be recommended. It can and may
> initiate sessions with some cadence (eg firing off a new request every N
> ms), keeping open attempts in process even though it is also starting the
> next attempt, until one of the attempts becomes an open session. It can
> prefer IPv6 in some way, prefer IPv4 in some way, or have no preference.
> >
> > To my small mind, turning off Happy Eyeballs turns off the parallelism.
> The implementation calls getaddrinfo(), gets a list of addresses associated
> with a name, and tries the addresses serially, waiting until the transport
> gives up on each attempt before trying the next.
> >
> > What we might want to do is adjust parameters - specify the cadence with
> which attempts are made, try all of the IPv4 addresses before any of the
> IPv6 addresses, try all of the IPv6 addresses before any of the IPv4
> addresses, alternate between architectures starting with IPv6, alternate
> between architectures starting with IPv4, or try something statistical in
> which we remember which addresses have a history of success and try them
> first, or simply never use IPv4 or never use IPv6.
> >

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 5 Oct 2011 21:12:06 -0700

On Wed, Oct 5, 2011 at 15:39, Brian E Carpenter <[email-masked]

> I want to be able to revert to RFC3484 (or RFC3484bis) behaviour.

Which is what? It seems to me that RFC 3484 doesn't say that connections
must be initiated in sequence, with a timeout between each one, right? It
only specifies the order in which getaddrinfo returns its results.

Applications don't have a setting that says "only try the first address
returned by getaddrinfo, and return an error if it fails"; they try all the
addresses in sequence, and I think we're happy with that. So I don't see why
we need to have a switch that says "don't parallelize connections, open them
serially".

Still, if it's SHOULD and not MUST then it doesn't matter so much. App
developers can always say "we're carefully weighed the full implications and
we're not implementing this because we think it's useless".

---

From: Joel jaeggli <[email-masked]>
Date: Wed, 05 Oct 2011 21:26:28 -0700

On 10/5/11 21:12 , Lorenzo Colitti wrote:
> On Wed, Oct 5, 2011 at 15:39, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> must be initiated in sequence, with a timeout between each one, right?
> It only specifies the order in which getaddrinfo returns its results.
> 
> returned by getaddrinfo, and return an error if it fails"; they try all
> the addresses in sequence, and I think we're happy with that. So I don't
> see why we need to have a switch that says "don't parallelize
> connections, open them serially".
> 
> developers can always say "we're carefully weighed the full implications
> and we're not implementing this because we think it's useless".

Much like when the document contained an algorithm there's a risk in
being too proscriptive when what you really want is to describe an
opportunity to tune for better performance.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 6 Oct 2011 08:28:03 -0400

Enterprise deployments are different than end-users. In the former case, I see many instances where HE would be either turned off or slightly changed to have a bias towards IPv6 or IPv4.  That switch can then be deployed enterprise wide or site wide or ... Therefore, there should be a knob to turn HE off or to add a bias towards one or the other AF.

Marc.

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Oct 2011 10:17:19 -0400

HE is basically a hack.  It's a useful hack in some situations, but it's still a hack.   I think we need to let hacks like this be able to evolve rather than trying to nail down their behavior.   Insisting that HE be tunable in a specific way has the effect of nailing down how HE works, and deterring its ability to evolve to something more general and more widely applicable.

Keith

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Oct 2011 11:34:01 -0400

> Most likely, five munutes later I'd want to re-enable HE behaviour.

I agree that the two should be related. Unfortunately, they're not.

If I am an application opening a session to somewhere, I 
   - open a socket, which is a way of talking with the OS
   - get a list of destination addresses associated with a name
   - try them in some sequence at some cadence
   - pass or fail.

RFC 3484 happens at a layer beneath me - given that an application is opening a connection to a stated address (during the third bullet), TCP-or-whatever decides what source address to use.

What makes things happening at different layers in different software either-or?

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Oct 2011 11:38:25 -0400

And RFC 3484 is...?

I tend to think that RFC 3484 is mostly pointless. It says to try native connections before transition mechanisms A, B, and C, which is good. It also says that if my peer and I happen to share a prefix, we should try that first, and that makes sense. In most cases, when I traceroute to someone else, I find that he is in a different network and he and I have different ISPs, so the likelihood of us having a common prefix is pretty low. If we lack a common prefix, RFC 3484 has nothing to say to me.

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Oct 2011 13:01:16 -0400

RFC 3484 (bis) is also of marginal value, IMO.    Overall it's good advice, but it only scratches the surface of a solution.  The place where it really fails is when dealing with ULIAs, because you really can't tell anything about them.   That's not the fault of RFC 3484, it does as much as can be done by looking only at address prefixes.

I see two problems with RFC 3484:  One is that people tend to think that it is, or should be, a complete solution to the deficiency in the IPv6 architecture resulting from having addresses with limited scope and/or limited reachability.  The second is that people tend to think that as long as network configuration works with some apps that use RFC 3484, it's "good enough" for all apps.

Keith

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 6 Oct 2011 12:21:51 -0700

Hi Fred, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Fred Baker
> Sent: Thursday, October 06, 2011 8:38 AM
> To: Keith Moore
> Cc: [email-masked]
> Subject: Re: [v6ops] IPv6-ness
> 
> And RFC 3484 is...?
> 
> I tend to think that RFC 3484 is mostly pointless. It says to 
> try native connections before transition mechanisms A, B, and 
> C, which is good. It also says that if my peer and I happen 
> to share a prefix, we should try that first, and that makes 
> sense. In most cases, when I traceroute to someone else, I 
> find that he is in a different network and he and I have 
> different ISPs, so the likelihood of us having a common 
> prefix is pretty low. If we lack a common prefix, RFC 3484 
> has nothing to say to me.

I don't think sharing a common prefix is always the best
means for determining which address(es) to try first. For
example, what if the two nodes share a common IPv6 prefix
on a 56kbps radio link with high loss/error rates, but
both also connect to an all-GigE IPv4 network with one
or more routers between them that can all forward at
line rates? There needs to be some way for the nodes
to know that the IPv6 link is the path of last-resort.

Thanks - Fred
[email-masked]

> > HE is basically a hack.  It's a useful hack in some 
> situations, but it's still a hack.   I think we need to let 
> hacks like this be able to evolve rather than trying to nail 
> down their behavior.   Insisting that HE be tunable in a 
> specific way has the effect of nailing down how HE works, and 
> deterring its ability to evolve to something more general and 
> more widely applicable.
> > 
> > Keith
> > 
> >> Enterprise deployments are different than end-users. In 
> the former case, I see many instances where HE would be 
> either turned off or slightly changed to have a bias towards 
> IPv6 or IPv4.  That switch can then be deployed enterprise 
> wide or site wide or ... Therefore, there should be a knob to 
> turn HE off or to add a bias towards one or the other AF.
> >> 
> >> Marc.
> > 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Oct 2011 08:32:41 +1300

Lorenzo and Fred,

We clearly have different ideas about how to perform systematic
analysis of connectivity and performance problems. I need to be
able to enable and disable specific host behaviours in order
to analyse such problems. In particular I don't want to be
confused by an application trying several address pairs
in parallel.

I am not getting through to you so I will shut up.

Regards
   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Oct 2011 16:30:05 -0400

It's been the case for a long time that you can see different behaviors at different layers.   ICMP packets can be blocked even if TCP packets get through.  Different TCP or UDP ports may experience different behavior, sometimes very subtly different behavior, while being routed through the network (cf the research that shows that port 80 traffic is more likely to break TCP options).   DNS interception proxies can create or mask connectivity problems.   So can http proxies, or any other kind of application-layer proxy.  You can also get inconsistent results between DNS, LLMNR, NIS, static host files, etc., that make it more difficult to understand why something works or doesn't work.  SRV records potentially introduce another way for things to break subtly and inconsistently from one host or application to another.   So any time you're trying to determine why a particular application doesn't work, it can require deep insight into how that application works.  And what works for one application might not work for another.  This is Not Good.

You're absolutely correct that HE provides yet another way that this can happen.  But somehow, replacing HR with 3484 doesn't seem like the solution.   

I'm tempted to say that the right solution involves clean separation between functional layers, with each layer making a best effort to do its job and to not do the job of other layers.    But that might be water under the bridge.  (That's one of the things I think widespread adoption of NAT destroyed, btw, because NAT widely promoted the idea that something in the network can break layering and try to be smarter than its endpoints.  It never was a sound idea, but now it's widely accepted, and now there are many more things than NAT that reflect this unfortunate belief.)

Failing that, it might be useful if applications could export some sort of profile that indicated how they used the network.   That profile could then be fed to a diagnostic tool that could mimic the app's behavior.   Though designing such a profile might be an interesting challenge given the increasingly wide range of behaviors exhibited by apps.

What I don't think will work is to say that everything should use 3484, even as a fallback behavior, because that's clearly not an appropriate behavior for all applications in all usage scenarios.  It's not a realistic test.

I'm not sure what problem it would solve, even for web browsers.  If an app that uses HE works with HE enabled and not with 3484 enabled, the app still works.  If an app fails with HE enabled and works with 3484 enabled, the app is still probably failing some of the time because 3484 isn't sufficient in general.   But if there's an underlying network problem, switching HE on or off won't reliably reveal much about that problem.  

If I were wishing for apps to have some sort of built-in diagnostic tool, I wouldn't wish for an HE-vs-3484 switch.  Instead, I'd want a switch that said "use only interface en0" or "use only the interface with source address foo".   Then I could test that app's behavior one interface at a time.   But what I'd rather have is a separate diagnostic tool that could mimic the behavior of various apps.

Keith

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 06 Oct 2011 15:07:37 -0700

>> I want to do this because I'm trying to understand a performance

I'm likely to switch to using an ipv6 or ipv4 literal because I don't
trust 3484 or for that matter the dns when I'm  trying to debug a layer
3 problem.

---

From: Keith Moore <[email-masked]>
Date: Thu, 6 Oct 2011 18:15:55 -0400

> trust 3484 or for that matter the dns when I'm  trying to debug a layer

which is fairly effective as long as the app doesn't use DNS names on the wire, as (for example) HTTP does.

Keith

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 06 Oct 2011 15:38:33 -0700

> which is fairly effective as long as the app doesn't use DNS names on the wire, as (for example) HTTP does.

it is trivial for the purposes of web application instrumentation to not
use the ip* literal in the get url request.  what's in the application
layer protocol in this case is a URI and not a dns name which is an
important distinction in particular because the application doesn't
know/care about the mapping of the name embedded in the URI by the time
a connection has been established.

This is something I do on a regular basis since I've got several
thousand load balancer vips along with api health to monitor in two
address families.

wget and curl are your friends.

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 7 Oct 2011 09:27:04 +0200 (CEST)

> And RFC 3484 is...?

I think RFC3484 is very valuable in the transition period, when not only 
native is available but 6to4 and teredo is very widely used.
Also very useful in the environment where ULA is used.

>
> I tend to think that RFC 3484 is mostly pointless. It says to try native 
> connections before transition mechanisms A, B, and C, which is good. It 
> also says that if my peer and I happen to share a prefix, we should try 
> that first, and that makes sense. In most cases, when I traceroute to 
> someone else, I find that he is in a different network and he and I have 
> different ISPs, so the likelihood of us having a common prefix is pretty 
> low. If we lack a common prefix, RFC 3484 has nothing to say to me.
>
>> HE is basically a hack.  It's a useful hack in some situations, but 
>> it's still a hack.  I think we need to let hacks like this be able to 
>> evolve rather than trying to nail down their behavior.  Insisting that 
>> HE be tunable in a specific way has the effect of nailing down how HE 
>> works, and deterring its ability to evolve to something more general 
>> and more widely applicable.
>>
>> Keith
>>

---

From: Rémi Després <[email-masked]>
Date: Fri, 7 Oct 2011 18:46:09 +0200

> I for one run IPv6 on my laptop continuously. If I don't have IPv6 in the network I happen to be in, the predictable result occurs. But if I am at home, and the other day when I was in a certain lo…

Many users of Free's network have been talking to Google in IPv6 without even knowing it, and without complaining.
Like Fred, I have been conscious of when my connections were IPv6, and it has been great to see that traffics with Google and with IETF were indeed IPv6.

Now, if HE breaks the preference for IPv6 even when IPv4 and IPv6 have comparable performances (which should be the rule for any IPv6 deployment by a responsible ISP), this will be a bad step backward: part of these IPv6 traffics will go back to IPv4 :-(.
Guarantee to traverse no NAT when there is an IPv6 e2e path will be lost!!
Enabling IPv6 won't protect against the increasing risk of port shortages in some NATs, a real pity.

IMHO, there is only one reasonable choice for HE: use IPv6 unless performance is found to be significantly lower than that of IPv4 (e.g. 25%).

The idea of a configurable option looks terrible to me, especially if there is already a possibility to completely disable IPv6.

In summary:
- Keep it simple to users
- Don't reduce cases where IPv6 nicely works. 

Regards,
RD

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 08 Oct 2011 08:00:39 +1300

> IMHO, there is only one reasonable choice for HE: use IPv6 unless performance is found to be significantly lower than that of IPv4 (e.g. 25%).

By using words like 'significantly' and 'e.g.' you are effectively asking for a
tunable parameter.

> The idea of a configurable option looks terrible to me, especially if there is already a possibility to completely disable IPv6.

Why? This is not something that 99% of users would be aware of or wish to use.
It would just be one more among the hundreds of configurable options in every device,
mainly left in their default setting.

> - Don't reduce cases where IPv6 nicely works. 

I completely agree, of course.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Oct 2011 15:18:48 -0400

> - Don't reduce cases where IPv6 nicely works. 

It seems like there's a conflict of interest between:

a) users' presumed interest in having good performance and reliability
b) the interest in preferring IPv6 over IPv4 (IETF and other IPv6 proponents wanting to show that IPv6 is "real";  ISPs wanting to minimize use of CGNs)

Though perhaps some bias toward IPv6 can be justified, even from the users' point-of-view, by a desire to avoid NAT.    It's in everybody's interest to avoid NAT, except perhaps the interests of those selling NATs.

Keith

---

From: Fred Baker <[email-masked]>
Date: Fri, 7 Oct 2011 15:31:56 -0400

> Though perhaps some bias toward IPv6 can be justified, even from the users' point-of-view, by a desire to avoid NAT.    It's in everybody's interest to avoid NAT, except perhaps the interests of th…

:-)

In my experience, there's a lot more pull than push. Andrew Yourtchenko was walking down the hall one day and took a video of just such a discussion in progress: http://www.xtranormal.com/watch/7011357/

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 7 Oct 2011 15:39:24 -0400

On Fri, Oct 7, 2011 at 15:00, Brian E Carpenter <[email-masked]

> mainly left in their default setting.

And that's the point exactly. Why implement a setting that 99% of people
won't ever use?

---

From: Randy Bush <[email-masked]>
Date: Sat, 08 Oct 2011 05:56:02 +0900

>> Why? This is not something that 99% of users would be aware of or
>> wish to use.  It would just be one more among the hundreds of
>> configurable options in every device, mainly left in their default
>> setting.
> And that's the point exactly. Why implement a setting that 99% of
> people won't ever use?

because if we don't have all that extra code for 100 knobs no one uses,
then the vendors would not be able to say "well, it's bloa^H^H^H^Hlarge
and has all those bugs because you asked for all those knobs and
features.

randy

---

From: Joel jaeggli <[email-masked]>
Date: Fri, 07 Oct 2011 14:33:28 -0700

On 10/7/11 12:18 , Keith Moore wrote:
>> IMHO, there is only one reasonable choice for HE: use IPv6 unless
>> performance is found to be significantly lower than that of IPv4
>> (e.g. 25%).
>> 
>> The idea of a configurable option looks terrible to me, especially
>> if there is already a possibility to completely disable IPv6.
>> 
>> In summary: - Keep it simple to users - Don't reduce cases where
>> IPv6 nicely works.
>> 
>> Regards, RD
> 

I don't have to presume that, I serve latency sensitive applications to
consumers. While there are several dimensions along which games are
monetized, it's easy enough to correlate latency to reveunue since we
track performance tweaks across millions of game sessions.

> b) the interest in preferring IPv6 over IPv4 (IETF and
> other IPv6 proponents wanting to show that IPv6 is "real";  ISPs
> wanting to minimize use of CGNs)

I'm an ipv6 proponent I think, and as far as I'm concerned a performance
tweak that reliably results in the fastest connection being used is a
very good thing. it allows me to deploy v6 on revenue properties without
being concerned the user experience will suffer.

> Though perhaps some bias toward IPv6 can be justified, even from the
> users' point-of-view, by a desire to avoid NAT.    It's in
> everybody's interest to avoid NAT, except perhaps the interests of
> those selling NATs.
> 
> Keith
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 7 Oct 2011 17:41:42 -0400

> track performance tweaks across millions of game sessions.

I don't disagree.  I just think we're on a bit of a slippery slope if we tell ourselves that we inherently know what's best for "users" in general.  A little bit of room for doubt, that allows us to have somewhat open minds, seems like a good thing.

Keith

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Oct 2011 17:31:50 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Keith Moore
> Sent: Friday, October 07, 2011 2:42 PM
> To: Joel jaeggli
> Cc: v6ops v6ops WG; Rémi Després
> I don't disagree.  I just think we're on a bit of a slippery slope if
> we tell ourselves that we inherently know what's best for "users" in
> general.  A little bit of room for doubt, that allows us to have
> somewhat open minds, seems like a good thing.

A compromise:  the specification will explain the benefit of making
the preference between IPv4 and IPv6 configurable.  It already has
text around that benefit, but we will make it clearer that the
value can be tweakable and explain an advantage or two of making
it tweakable.

I would expect that Firefox (being Firefox) will have a 
config: setting to tweak it.  I expect that Safari (especially
Mobile Safari) to not have a setting.  Other products (e.g., 
wget, IE, Opera, curl) will fall in one of those camps.

As already discussed in the draft, simply choosing the fastest 
connection can be harmful to the services deliverable to the 
user.  Using IPv4 address sharing can breaks services which cannot 
be provided as well with IPv4 address sharing -- such as 
better geolocation, which may be necessary for delivering live 
video of sporting events (which are often restricted to certain 
geographic areas, to encourage people to attend in person 
and all that), better advertising, location-based features 
such as "directions from where I am now", "nearest pizza", 
and so on.  Another harm of IPv4 address sharing is 
non-TCP/-UDP transports which aren't supported with IPv4 
address sharing -- such as RSVP, SCTP, DCCP, native 
IPsec ESP, and others.

-d

---

From: Rémi Després <[email-masked]>
Date: Sat, 8 Oct 2011 09:19:43 +0200

> By using words like 'significantly' and 'e.g.' you are effectively asking for a

Well, not in my understanding.
What I mean is that any value like 15%, 20%, 25%, or a range left to implementers like 10 to 25%, would do.

It's IMHO up to those who standardize to make good enough decisions.
Thus,  users aren't asked to configure parameters they don't understand. 
Especially if these parameters are supposed to be so difficult to understand that specialists couldn't choose their values, or range of permitted values.

For research, yes, playing with such parameters makes sense.
But, IMHO, it doesn't belong to a standardized behavior all products SHOULD support (with the administration and training that goes with it). 

> I completely agree, of course.

The point is that, by abandoning sheer preference for IPv6 unless it's performance is found to be significantly lower than that of IPv4,  one does reduce cases where IPv6 is used where it nicely works.

The idea of seeing my traffic with Google and IETF to become less IPv6 than before is IMHO very shocking.

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Sat, 8 Oct 2011 04:13:39 -0400

> value can be tweakable and explain an advantage or two of making

seems rational to me.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 08 Oct 2011 13:38:26 +0200

In your letter dated Mon, 3 Oct 2011 17:22:59 -0400 you wrote:
>Note that I see HE as having very narrow applicability.   There are lots =
>of reasons that make it inapplicable for network software in general.  =

Can you be a bit more specific? Let's assume for the moment that not using
HE would mean that the application falls back to the RFC-3484. I don't see
how HE makes it worse. 

I'm running HE on my outgoing mail server. And works fine. 

I'm trying to think of application where I would want RFC-3484 over HE, but
I can't find any.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 08 Oct 2011 13:45:40 +0200

In your letter dated Tue, 4 Oct 2011 02:47:50 +0200 you wrote:
>Probably :)  If the value is too low the choice between IPv4 and IPv6 =
>will become unstable and unpredictable. If the value is too high then =
>the potential impact on the user experience increases. The people =
>implementing this will probably care 99% for the end-user and 1% about =
>us network people (and they probably should: the end-users are their =
>customers) so the choice needs to be a balance between 'helping ipv6 =
>deployment' and 'not bothering/annoying the user'. Maybe 50-100 ms would =
>be better than 100-200 ms, but I'll leave the exact numbers to people =
>who know where the border is between an (almost) unnoticeable delay and =
>a noticeable one.

In my experience (with my own implementation), the main source of
instability is big buffers in routers. When the link is full, latency
increases and that causes HE to switch between IPv6 and IPv4.

In practice, with normal web browsing it is not a big deal, only a small
percentage of the connections goes out over IPv4 due to this effect.

I use a 30ms bias in favor of IPv6. That is more than enough to prefer 
IPv6 on an idle link.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 08 Oct 2011 13:52:28 +0200

>why having such a switch is contentious.

I think there is a lot of stuff we don't expect users to adjust. There is
an endless series of TCP parameters you can change. Which can also have 
serious negative effects.

I don't mind application/os/library writers, adding controls for performance
tuning and debugging. Personally, I think logging is even more important than
the ability to switch off HE.

I do mind the IETF telling them what they have to do. For that reason, I
think a MAY is more than enough. We want to explain the issues, but after that
it's about the application/os/library writers to think about what their
users want/need.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 08 Oct 2011 13:56:33 +0200

>to know that the IPv6 link is the path of last-resort.

I think there is a good chance stateful HE implementations will figure that
out. 

In the context of many short connection (the application area for HE), some
connections will take longer to establish due to packet loss and that will 
cause IPv4 to be preferred.

---

From: Fred Baker <[email-masked]>
Date: Sat, 8 Oct 2011 08:04:51 -0400

> it's about the application/os/library writers to think about what their

Makes sense to me...

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 8 Oct 2011 14:17:22 +0200

> Enterprise deployments are different than end-users. In the former case, I see many instances where HE would be either turned off or slightly changed to have a bias towards IPv6 or IPv4.  That swit…

Since I switched to OS/X Lion, Safari selects all by itself the protocol to use. While this is smart, I have a hard time testing IPv6 connectivity without hard-coding entries in /etc/hosts. Having a switch like the one Marc describes here would make sense for me as a debugger as well as within a network I manage.

/O

---

From: Philip Homburg <[email-masked]>
Date: Sat, 08 Oct 2011 14:56:00 +0200

In your letter dated Sat, 8 Oct 2011 14:17:22 +0200 you wrote:
>Since I switched to OS/X Lion, Safari selects all by itself the protocol to us
>e. While this is smart, I have a hard time testing IPv6 connectivity without h
>ard-coding entries in /etc/hosts. Having a switch like the one Marc describes 
>here would make sense for me as a debugger as well as within a network I manag
>e.

I agree that for Lion you need to be able to switch it off. But that's mostly
because Lion is good example of how not to implement HE.

For my own implementation, I find the logs generated by HE much more valueable
than an ability to switch it off.

I live in a boring part of the net. It just works, even 6to4.

So, the only part that is really interesting is remote destinations with 
high latency (or otherwise poor performance). 

If I just see an IPv6 destination with high latency, then I don't know if
it is because that site is just far away or poorly connected, or if it is
actually an IPv6 issue.

And that is exactly the kind of statistics HE keeps track of. If I see that
IPv4 is actually preferred over IPv6 then I know that I should take a closer
look.

---

From: Rémi Després <[email-masked]>
Date: Mon, 10 Oct 2011 09:35:10 +0200

>> value can be tweakable and explain an advantage or two of making

Although configurable options should IMHO be avoided as much as possible, this is IMHO an acceptable compromise, but only if IPv6 is the default preference.

Thus, ordinary users, who don't know how to configure IP-layer options, will work in IPv6 with all popular servers (Google's etc.) wherever normal quality IPv6 connectivity exists.
They will thus be immune from any consequence of port shortages in NAT44s, possibly more and more frequent in the future.

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Oct 2011 09:31:22 -0700

Hi Philip, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Saturday, October 08, 2011 4:57 AM
> To: Templin, Fred L
> Cc: [email-masked]

As in, test both paths once and then remember the
results of the test for all time? What if the good
path loses the first packet out, and the bad path
wins the race? There are certainly network devices
that deterministically drop the first packet out,
e.g., while establishing a virtual circuit.

> cause IPv4 to be preferred.

The point is that there may be links/paths that you
really don't want to run an initial test against but
rather save aside as a path of last resort in case
the good path fails. I wasn't kidding when I was
talking about 56Kbps radio links. Another example:
in modern multi-access devices you really don't want
a pay-as-you go service to win the race against a
free access service.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Mon, 10 Oct 2011 20:59:33 +0200

>e.g., while establishing a virtual circuit.

I think as general rule, don't add an IPv6 link that sucks to a well
performing IPv4 connection. You are just setting yourself up for a lot of
suffering.

But in my own implementation, I keep track of the connect times both per 
protocol and per destination.

If the 'good path' always drops the first packet out on every connection, 
then yes, my implementation would not consider it a good path.

Otherwise, a lossy, low speed IPv6 connection would quickly get a high value
for latency, and IPv4 would be preferred.

>> In the context of many short connection (the application area=20
>> for HE), some
>> connections will take longer to establish due to packet loss=20
>> and that will=20

Well, don't play those games with IPv4 versus IPv6. If you have backup IPv6
connection next the normal one, then it becomes a source address selection
issue, something which HE doesn't really care about.

I'd say, life is complex enough already. Don't try to solve those issue in
the host. If you have a single access point, like an application gateway,
then it may be a different story.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Oct 2011 12:51:08 -0700

Hi Philip, 

> Sent: Monday, October 10, 2011 12:00 PM
> To: Templin, Fred L
> Cc: [email-masked]

I can't recall whether LISP is currently dropping or
delaying the first packet out - or, maybe they route
it through an alternate topology which might impart a
significant additional delay. But aside from LISP, I
do know of operational networks where initial packets
toward new destinations are dropped while a VC is
established - and that is definitely on the "good"
path.

> for latency, and IPv4 would be preferred.

Right, but there are certain links on which I'd like
to run IPv6 but I would really rather not test every
time I try to connect to a new destination. So, if
there is some way for the implementation to be made
aware of links/paths to avoid before engaging HE,
then it seems like a configuration knob would be
useful. 

> then it may be a different story.

While I think it is true that we want to run IPv6
over all links, it is definitely not true that all
links are created equal. And, if there is a way to
know beforehand which links are "less equal" than
others then it might make much more sense to try
the connections serially instead of in parallel.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Mon, 10 Oct 2011 23:00:53 +0200

>established - and that is definitely on the "good"

So, you have system with a high initial packet loss for IPv4 and you pair
with a bad IPv6 connection.

I think that is the point where general purpose solutions just stop working.

That said, my implementation also probes individual IPv4 addresses, so it
may get IPv4 preferred after some time.

>> Otherwise, a lossy, low speed IPv6 connection would quickly=20
>> get a high value
>useful.=20

If IPv6 performs poorly, then my implementation doesn't try IPv6 for every 
connection. However, it will periodically probe all addresses. 

On the other hand, there are also websites that have IPv6-only links
to measure IPv6 connectivity. So there will be some amount of traffic anyhow.

Less probe traffic can be had by just keeping statistic per protocol instead
of per destination. But comes at the expense of a loss of accuracy.

>> I'd say, life is complex enough already. Don't try to solve=20
>> those issue in
>> the host. If you have a single access point, like an=20
>> application gateway,

I don't think HE is about doing things in parallel. It is about using
timeouts that are close to the expected performance of a connection.

As long as the one connects faster is the connection you want, and the
statistics are also relatively stable, HE is likely to work.

If, for policy reasons, you don't want the link that HE considers best, then
it is not going to work.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 10 Oct 2011 14:20:42 -0700

Hi Philip, 

> Sent: Monday, October 10, 2011 2:01 PM
> To: Templin, Fred L
> Cc: [email-masked]

This is just one example showing that what you have
in the general sense is heterogeneity, where a general
purpose solution may not always be desirable. I'm willing
to believe that HE works great except for when it doesn't;
at those times, it might be nice to have a configuration
knob to turn it off.

Thanks - Fred

---

From: Philip Homburg <[email-masked]>
Date: Tue, 11 Oct 2011 10:29:25 +0200

>at those times, it might be nice to have a configuration

I'm still at a loss as to why you would want a setup that is erratic to the
point that HE cannot deal with it (i.e. both IPv4 and IPv6 have to behave
quite badly)

But if such configurations are to be supported then yes, a knob to trun off 
HE would be required.

(I think such a knob would be akin to turning off congestion avoidance in TCP
because the links you are trying to use are too lossy)

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Oct 2011 06:27:04 -0400

> point that HE cannot deal with it (i.e. both IPv4 and IPv6 have to behave

are we now trying to define what's an appropriate network configuration in terms of whether HE works well with it?  seems backwards.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Oct 2011 06:38:09 -0400

> HE would mean that the application falls back to the RFC-3484. I don't see

I may have mis-remembered what the draft said, or maybe it changed since I last read it, because the 04 version doesn't bother me in this way as much as I remember some earlier version bothering me.  The main thing that comes to mind is that some applications are more bandwidth-sensitive whereas others are more delay-sensitive, so the choice made by HE might be good for some apps and bad for others.  I don't see this as a problem as long as HE is implemented within the application and not in the platform - each application will implement an algorithm that makes sense for it.   But that's part of why I see HE, as defined in the document, as being of narrow applicability.   A single round-trip SYN-SYN/ACK exchange is not a good predictor of path quality for all apps.

(No, it's not reasonable to assume that the application falls back to RFC 3484.  RFC 3484 is also not applicable to all apps.  But neither does it really get in the way of apps, because no app is forced to try addresses in the order returned by getaddrinfo)

Having said that, there are still some things about -04 that bother me.   I disagree that it's appropriate to inherently prefer v6 over v4.   It's quite normal these days for a host to have multiple active connections to the Internet.  Some of those connections might be v6 or dual-stack, and some might be v4 only.    Simply preferring v6 over v4 could easily mean that a path with less available bandwidth, or one that is more expensive to use, is chosen over a v4-only interface that offers better service overall.    I don't think that's sufficient.  (What _might_ make more sense is that when a HE implementation needs to choose between an IPv4 and an IPv6 address on the same interface, it prefers the IPv6 address.  Even then it's easy to imagine plausible cases where this will fail.)

The -04 draft of HE seems to be written on the assumption that a either host only has one IPv4 address and one IPv6 address, or that all of a host's connections are of approximately equivalent capability.  That's not a reasonable assumption in practice.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Tue, 11 Oct 2011 13:12:23 +0200

In your letter dated Tue, 11 Oct 2011 06:27:04 -0400 you wrote:
>are we now trying to define what's an appropriate network configuration =
>in terms of whether HE works well with it?  seems backwards.

Not at all. To make it fail, we now have an example setup where the IPv6
link randomly drops packets and therefor not suitable and the IPv4 link has a
high initial packetloss because it is a VC or something like that.

Then you would have to disable HE and make RFC-3484 prefer IPv4.

In my opinion adding an IPv6 link that has high loss is just asking for
trouble. The great thing about HE is that it can be shipped to users and when
they have a broken IPv6 connection it just gets ignored. By the time you have
to go in an disable HE because both IPv4 and IPv6 are broken, why not just
disable IPv6 itself?

---

From: Keith Moore <[email-masked]>
Date: Tue, 11 Oct 2011 07:23:27 -0400

> high initial packetloss because it is a VC or something like that.

It doesn't seem necessary to have that contrived a setup before HE behaves sub-optimally.  All you need is for the IPv4 link to perform better overall (for some meaning of better, including "nearly as fast and cheaper") than IPv6, but for the IPv6 to have nearly as good RTTs on brief probes.   We've known for a long time that brief probes aren't good indicators of path quality.

Keith

---

From: Philip Homburg <[email-masked]>
Date: Tue, 11 Oct 2011 16:01:17 +0200

In your letter dated Tue, 11 Oct 2011 06:38:09 -0400 you wrote:
>The main thing =
>that comes to mind is that some applications are more =
>bandwidth-sensitive whereas others are more delay-sensitive, so the =
>choice made by HE might be good for some apps and bad for others.  

Yes, that is true. If the IPv6 connection works well, but has significant lower
bandwidth than IPv4 then HE will be wrong.

This is not something that is easy to solve in an application. The application
would have to measure the bandwidth over both IPv4 and IPv6 and then take a 
decision. I guess that would be doable in torrent but torrent should not need
HE anyhow.

>(No, it's not reasonable to assume that the application falls back to =
>RFC 3484.  RFC 3484 is also not applicable to all apps.  But neither =
>does it really get in the way of apps, because no app is forced to try =
>addresses in the order returned by getaddrinfo)

I don't think it is so much the issue whether an application is forced to 
use HE or not, but what generic algorithms are available to applications.

>The -04 draft of HE seems to be written on the assumption that a either =
>host only has one IPv4 address and one IPv6 address, or that all of a =
>host's connections are of approximately equivalent capability.  That's =
>not a reasonable assumption in practice.

I don't think HE can solve how to deal with multiple interfaces. Even for just
IPv4 that is mostly an unsolved problem.

One thing is that if getaddrinfo knows what to do, then HE may also be okay,
because HE can be made to prefer whatever getaddrinfo prefers.