> 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). As mentioned in the
draft, NHE can
work independenly(without interferance) with the adoption of Client-side
HE.
If client's already support HE, it will query A & AAAA at the same time. NHE
can
help reduce the unnecessary traffic emitted by HE client becuase the AAAA
record
will be omitted or delayed if IPv6 connectivity is poorer. I don't see any
interferance now.


> A router knows very little about end to end properties of a connection. It
> could of course do those measurements by looking deeply into packets, but
> it would still be restricted to it’s own topological location.
>
It depends on how far you do the measurement to simulate the end users.
Some APM (application performance measurement) vendor like New Relic
provides sdk implementing on Apps to provide measurement data for analysis
and deliever a good performance monitoring and traffic engineering.
Some provide probes close to clients and edge.

I think maybe there is a crose-layer issues on this draft which should be
simple
 enough and aim IP layer issues. But right now lots of complected
application
layer complexities (like CDN, APM) are involved.


> Compare that with the data available to an MP-TCP host stack.
>

I think MP-TCP or other transmition protocol are based on stable,
high-performance ip layer.


> And note I think HE can’t just be between v4 and v6, but between all the
> candidate connections between source and destination.
>

HE(RFC8035) only focus on IP connection seletion right now accroding to the
problem statement:

   "Many communication protocols operating over the modern Internet use
   hostnames.  These often resolve to multiple IP addresses, each of
   which may have different performance and connectivity
   characteristics.  Since specific addresses or address families (IPv4
   or IPv6) may be blocked, broken, or sub-optimal on a network, clients
   that attempt multiple connections in parallel have a chance of
   establishing a connection more quickly.  This document specifies
   requirements for algorithms that reduce this user-visible delay and
   provides an example algorithm."


If there are other candidate connections, they also need a better IP
connectiviy as a bais I think.
NHE at least can give a indicaiton of poor connection for certain address
family (or address) .
It is potentially a low level routing founctions other than hight level
traffic scheduling tools.

Davey
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to