Sent from my iThing
On 23 Dec 2014, at 00:22, Dave Taht dave.t...@gmail.com wrote:
On Thu, Dec 18, 2014 at 2:06 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 19/12/2014 04:07, Michael Richardson wrote:
I am way behind on my mail (this thread) and will be away for the
- create one of more additional software loopback interfaces that are
always up and used as source and destination for binding for all
(legacy) apps.
- a software interface would have one single /64 prefix from each
delegated Homenet prefix, reducing the number of potential sources and
Hi,
On Mon, Dec 22, 2014 at 01:23:37PM +1300, Brian E Carpenter wrote:
Probe results should probably
be cached for a while and interpreted per-prefix not per-address.
I agree in principle, just wonder how big the prefix boundary for
per-prefix should be... (and I can make cases for a /32
On 22.12.2014, at 11.54, Gert Doering g...@space.net wrote:
On Mon, Dec 22, 2014 at 01:23:37PM +1300, Brian E Carpenter wrote:
Probe results should probably
be cached for a while and interpreted per-prefix not per-address.
I agree in principle, just wonder how big the prefix boundary for
Hi,
On Mon, Dec 22, 2014 at 12:48:50PM +, Markus Stenberg wrote:
be cached for a while and interpreted per-prefix not per-address.
I agree in principle, just wonder how big the prefix boundary for
per-prefix should be... (and I can make cases for a /32 should be
good enough??? or
On 22.12.2014, at 13.04, Gert Doering g...@space.net wrote:
I was actually looking the other way, destination space - if you know
that for, say, 2001:608::1 the path over ISP A is better (for whatever
local metric), everything else inside 2001:608::/32 will have the same
result for the same
Probe results should probably [be] interpreted per-prefix not per-address.
Hmm. Interesting idea.
I can imagine some scenarios where it could break -- Ethernet bridged with
Wifi (OpenWRT style), mesh networks, or simply a congested, bufferbloated
interface. I'm not sure how common such
On Mon, Dec 22, 2014 at 5:50 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
Probe results should probably [be] interpreted per-prefix not per-address.
Hmm. Interesting idea.
+1. Pick one of dhcp, slaac, or privacy within a prefix with the best
lifetime, maybe?
I can imagine
I can imagine some scenarios where it could break -- Ethernet bridged with
Wifi (OpenWRT style),
If you have two hosts connected to an OpenWRT router, one over Wifi and
one over Ethernet, they could have very different performance
characteristics while being on the same prefix.
expound?
Hi,
On Mon, Dec 22, 2014 at 03:18:47PM +0100, Juliusz Chroboczek wrote:
If you have two hosts connected at different places to the same mesh
network, they could have very different performance characteristics while
having addresses from the same /64.
Indeed, that's the other end of the
On 23/12/2014 03:22, Gert Doering wrote:
Hi,
On Mon, Dec 22, 2014 at 03:18:47PM +0100, Juliusz Chroboczek wrote:
If you have two hosts connected at different places to the same mesh
network, they could have very different performance characteristics while
having addresses from the same /64.
Brian E Carpenter brian.e.carpen...@gmail.com wrote:
On the other hand, if we end up having hundreds of addresses on every
host, the strategy will need to be rethought. Dave is currently playing
with a network where each host has 10 addresses of different kinds, and
he's
On Thu, Dec 18, 2014 at 2:06 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 19/12/2014 04:07, Michael Richardson wrote:
I am way behind on my mail (this thread) and will be away for the holidays.
Merry Christmas, everyone, and to all a happy new year!
Dave,
my take is that
Hi,
On Fri, Dec 19, 2014 at 11:54:54PM +0100, Matthieu Boutier wrote:
I do end-to-end measurements in my mosh implementation, so we should
not have the problem. The host selects a source address, in fact a
pair (src, dst), depending on the performances of the whole path
determined by this
On Fri, Dec 19, 2014 at 11:54 PM, Matthieu Boutier
bout...@pps.univ-paris-diderot.fr wrote:
You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.
Its not really useful to select a faster gateway if the path towards
the gateway goes over a
You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.
I do end-to-end measurements in my mosh implementation, so we should
not have the problem.
Does this really scale well?
How well do we need it to scale? Three addresses per host? A
On Sun, Dec 21, 2014 at 11:44 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.
I do end-to-end measurements in my mosh implementation, so we should
not have the problem.
On 22/12/2014 08:44, Juliusz Chroboczek wrote:
You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.
I do end-to-end measurements in my mosh implementation, so we should
not have the problem.
Does this really scale well?
How well do
Sounds interesting. In the ideal world, that would be a pluggable
policy algorithm. Lowest RTT may not always be the best choice.
It is, in our particular context. That's the nice thing about working at
the application layer -- you are the application, so you have a pretty
good idea of what
On Fri, Dec 19, 2014 at 6:31 PM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
Sounds interesting. In the ideal world, that would be a pluggable
policy algorithm. Lowest RTT may not always be the best choice.
It is, in our particular context. That's the nice thing about working at
You might also need to combine the features of the gateway with the
metric(s) of the path to the gateway.
Its not really useful to select a faster gateway if the path towards
the gateway goes over a slow wifi link.
I do end-to-end measurements in my mosh implementation, so we should
not
Dave,
my take is that applications, and the entire gai.conf/getaddrinfo() library
is broken. Applications can neither be updated nor be trusted to know enough
about the system to be able to make a proper decision.
Somewhere, someone was working on a new connect(2) call that took FQDNs
rather
On 19/12/2014 04:07, Michael Richardson wrote:
Dave,
my take is that applications, and the entire gai.conf/getaddrinfo() library
is broken. Applications can neither be updated nor be trusted to know enough
about the system to be able to make a proper decision.
Somewhere, someone was
Shouldn't we reduce the amount of cross-posting at some point?
mptcp, I'm told, is likely to show up in Apple and Google products and
infrastructure, and my idea (and many others) is that you don't always have
to pick the perfect address for the SYN, just one that works, but rather one
can
On 18/12/2014 03:16, Dave Taht wrote:
...
The ideal scenario is where the host app picks the best address for
each connection type, and I am a little vague on what actually
happens. What my backbrain (but not RFC 3484 - is there a later rfc
for what gai.conf should do?)
Not sure if anyone
On 19/12/2014 11:22, Juliusz Chroboczek wrote:
Shouldn't we reduce the amount of cross-posting at some point?
mptcp, I'm told, is likely to show up in Apple and Google products and
infrastructure, and my idea (and many others) is that you don't always have
to pick the perfect address for the
On Thu, Dec 18, 2014 at 7:19 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 19/12/2014 11:22, Juliusz Chroboczek wrote:
Shouldn't we reduce the amount of cross-posting at some point?
mptcp, I'm told, is likely to show up in Apple and Google products and
infrastructure, and
On 12/18/14 4:39 PM, Jim Gettys wrote:
On Thu, Dec 18, 2014 at 7:19 PM, Brian E Carpenter
brian.e.carpen...@gmail.com mailto:brian.e.carpen...@gmail.com wrote:
On 19/12/2014 11:22, Juliusz Chroboczek wrote:
Shouldn't we reduce the amount of cross-posting at some point?
On 19/12/2014 13:47, joel jaeggli wrote:
On 12/18/14 4:39 PM, Jim Gettys wrote:
On Thu, Dec 18, 2014 at 7:19 PM, Brian E Carpenter
brian.e.carpen...@gmail.com mailto:brian.e.carpen...@gmail.com wrote:
On 19/12/2014 11:22, Juliusz Chroboczek wrote:
Shouldn't we reduce the amount of
On 19/12/2014 14:49, Juliusz Chroboczek wrote:
Boutier's version of mosh builds connections across all source/destination
pairs, and picks the one with lowest RTT.
Sounds interesting. In the ideal world, that would be a pluggable
policy algorithm. Lowest RTT may not always be the best
On Thu, Dec 18, 2014 at 7:38 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
On 19/12/2014 14:49, Juliusz Chroboczek wrote:
Boutier's version of mosh builds connections across all source/destination
pairs, and picks the one with lowest RTT.
Sounds interesting. In the ideal world,
I have been wrestling with prefix coloring, where choosing a best
prefix would be of use in (for example) reducing the problems induced
by happy eyeballs when more than one ipv6 prefix is present and
several other scenarios.
There are many parts to this - one is in addressing, the other in DNS,
32 matches
Mail list logo
