; 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. The
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 s
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 betwe
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 p
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 t
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 pmt
And this is what I tried to say several times:
We need to take advantage of HE and NHE, or other means, to "report" to the
ISPs about brokenness.
https://tools.ietf.org/html/draft-palet-v6ops-he-reporting-00
Regards,
Jordi
-Mensaje original-
De: v6ops en nombre de Tommy Pauly
Fe
Hi Barbara,
In my experience, there are two ways IPv6 can be broken:
1) ICMPv6 being filtered, so PMTUD doesn't work.
2) IPv6 deployment issues (including having records with no or bad IPv6
connectivity).
HE only helps for 2).
But 2 can be caused in different points between the source and
+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 between one another as Tony describes.
The point of client-side Happy Eyeballs is to work around bro
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 work
> The point of happy eyeballs is to work around crappy or broken networks,
That's my recollection, too. And I'm really struggling to figure out which are
the broken IPv6 networks NHE is trying to work around. The possible networks
are: LAN, ISP/access, core/transit, and destination. I'm not awar
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 e
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, w
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.
Ger
I'm working in China telecom. End users' experience is the uppermost important
for us, either is over IPv4 or IPv6. People have fears on IPv6 transition
because they are not sure of IPv6 performance. Actually we have received user's
complains when IPv6 was deployed. IPv6-only is attractive，bu
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 wel
> 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 (rfc6724
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 connection
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* con
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, right
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 deepl
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 f
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 volat
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 l
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 t
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 end-
>
> 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. Ext
> 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
> IPv4-vs-IPv
> 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 in
29 matches
Mail list logo
