; v6...@ietf.org
Subject: Re: [DNSOP] [v6ops] New Version Notification for
draft-v6ops-xie-network-happyeyeballs-00.txt
Hi Barbara,
Thanks for your comments and sharing. I need to note that NHE is not competing
with
Client-side HE or competing with deployment of fully functioning IPv6
Hi,
On Thu, Sep 27, 2018 at 11:09:39AM +0800, Davey Song wrote:
> So the suffering of users is real in dualstack.
This is a misconception.
"A few applications are lazy, so performance for them is poor" is better
describing things.
Gert Doering
-- NetMaster
--
have you enabled IPv6 on
Hi Tommy,
Thanks for your suggestions.
On Wed, 26 Sep 2018 at 23:38, Tommy Pauly wrote:
> +1 to the point that the proposal for NHE is essentially a mechanism for
> the ISP and/or content provider to work around a broken deployment that
> they should be in a position to fix themselves, or
Hi Barbara,
Thanks for your comments and sharing. I need to note that NHE is not
competing with
Client-side HE or competing with deployment of fully functioning IPv6. The
background of
NHE is :
1) the dualstack is real. Client is facing the choice ipv4 or ipv6.
2) the poor or unpredictable IPv6
Speaking for myself, I see HE as a mechanism whose usefulness as described
(selecting between IPv4 and IPv6 addresses) will wane, but which applied in a
different way may have value long term. The latter has to do with access from
or to multi-addressed services and selecting the one that seems
JORDI PALET MARTINEZ wrote:
...
In my experience, there are two ways IPv6 can be broken:
1) ICMPv6 being filtered, so PMTUD doesn't work.
perhaps we can choose a flag day to turn on a new option in our ipv6
stacks-- add an ipv6 option to all our syn and syn-ack packets, and/or
require
ommy Pauly
Fecha: miércoles, 26 de septiembre de 2018, 12:38
Para: Tony Finch , "STARK, BARBARA H" , dnsop
, "v6...@ietf.org" , Davey Song
Asunto: Re: [v6ops] [DNSOP] New Version Notification for
draft-v6ops-xie-network-happyeyeballs-00.txt
+1 to the point that the p
inal-
De: v6ops en nombre de "STARK, BARBARA H"
Fecha: miércoles, 26 de septiembre de 2018, 10:45
Para: 'Tony Finch' , Gert Doering
CC: dnsop , "v6...@ietf.org"
Asunto: Re: [v6ops] [DNSOP] New Version Notification for
draft-v6ops-xie-network-happyeyeballs-00.txt
>
STARK, BARBARA H wrote:
> Why would an ISP choose to deploy partial or broken IPv6 + NHE, rather
> than properly functioning IPv6?
That was my initial reaction too :-) I think the actual idea is to work
around brokenness on third party networks, e.g. the ISP has working v6,
the web site has
Gert Doering wrote:
>
> I'm not sure how often I've heard the well-meaning suggestion "just do
> not deliver DNS records of type if ".
>
> It was a bad idea at all times, and it is still a bad idea. Never withhold
> legitimate records.
I think it's even worse in this case.
The point of happy
In your letter dated Wed, 26 Sep 2018 12:58:30 +1000 you wrote:
>I have said before, but don't know if I still adhere to it, but
>anyways, here's a question: How *long* do people think a biassing
>mechanism like HE is a good idea?
>
>I used to love HE. I now have a sense, I'm more neutral. Maybe,
Hi,
On Wed, Sep 26, 2018 at 03:56:15PM +0800, Chongfeng Xie wrote:
> In the early stage of dual-stack deployment, we can not expect the
> IPv6 has matched performance with IPv4.
This is true. But "early stage of dual-stack deployment" was 15 years ago,
so this is not a valid excuse today.
@chinatelecom.cn
From: George Michaelson
Date: 2018-09-26 10:58
To: dnsop WG
CC:
Subject: Re: [v6ops] [DNSOP] New Version Notification for
draft-v6ops-xie-network-happyeyeballs-00.txt
I have said before, but don't know if I still adhere to it, but
anyways, here's a question: How *long* do
Hi,
On Wed, Sep 26, 2018 at 03:14:42PM +0800, Davey Song wrote:
> NHE can
> help reduce the unnecessary traffic emitted by HE client becuase the
> record
> will be omitted or delayed if IPv6 connectivity is poorer. I don't see any
> interferance now.
I'm not sure how often I've heard the
> If we’re discussing host based versus network based happy eyeballs, would
> it be naive to think that the network based HE would interfere with the
> client’s HE?
>
Currently this draft only considers IPv4/IPv6 racing situation. The general
address
racing is already done for all clients
On Wed., 26 Sep. 2018, 16:10 Ole Troan, wrote:
> Davey,
>
> If we’re discussing host based versus network based happy eyeballs, would
> it be naive to think that the network based HE would interfere with the
> client’s HE?
>
> A router knows very little about end to end properties of a
Hi,
On Wed, Sep 26, 2018 at 03:28:24PM +1000, George Michaelson wrote:
> run a race, but bias the race towards the one you like? oky.. But
> once we're beyond a world where the V6 needs the bias, for anyone
> stuck on the vestigial 4-is-better space, this means they incurred
> *additional*
Hi George,
Actually the idea of NHE is inspired partially by CDN stuff, which involve
lots of measurments
and route users to visit a best path against network dynamics. It proves
to be a good practice
for morden Internet. No doubt. I'm wondering CDN is also breaking DNSSEC to
stub-resolver,
Davey,
If we’re discussing host based versus network based happy eyeballs, would it be
naive to think that the network based HE would interfere with the client’s HE?
A router knows very little about end to end properties of a connection. It
could of course do those measurements by looking
Having a predictable bias seems better than an unpredictable one.
> On Sep 25, 2018, at 22:28, George Michaelson wrote:
>
> I'm not speaking for Owen. I'm speaking for myself. I asked a
> question. Is this really a long-term defensible thing to do? Do we
> want HE forever?
>
> run a race? thats
I'm not speaking for Owen. I'm speaking for myself. I asked a
question. Is this really a long-term defensible thing to do? Do we
want HE forever?
run a race? thats fine. But, as the thread here notes, the
second-by-second conditions which leads one TCP to return SYN-ACK
before another can be
What better idea did you mean?
Being able to select a protocol based on what works best for the
end-user does not seem like a terrible end-state for the end-user,
short- or long-term.
> On Sep 25, 2018, at 21:25, Owen DeLong wrote:
>
> It was never a good idea. It was a necessary evil (kind of
It was never a good idea. It was a necessary evil (kind of like NAT in that
regard) to expeditiously deal with a somewhat tenacious (at the time) problem
which has since been given a significantly better solution, but so long as the
workaround appears to be working, people are loathe to put in
I have said before, but don't know if I still adhere to it, but
anyways, here's a question: How *long* do people think a biassing
mechanism like HE is a good idea?
* is it a good idea *forever*
* or is it a transition path mechanism which has an end-of-life?
* how do we know, when its at
>
> But in the general case the network cannot.
> Think host multi-homing.
>
Yes or no.
Generally speaking the races of IPv6 and IPv4 connections on both network
and client are going to be suffered by netowrk dynamics, including
Multi-homing, route flaps, roaming, or other network falilures.
> This hints at a general misunderstanding on how "The Internet" works.
>
> Talking to the local ISP on "what would you recommend, IPv4 or IPv6?"
> can give an indication, but if the server you're trying to talk to
> is on the other side of the world, the local ISP's preference for
>
> On Sep 24, 2018, at 11:14 AM, 神明達哉 wrote:
>
> At Fri, 21 Sep 2018 14:31:50 +0800,
> Davey Song wrote:
>
> > I just submited a new draft intending to provide better connectivity from
> > network side function . Comments are welcome.
>
> Some quick observations:
>
> - I don't see why the
27 matches
Mail list logo
