Re: [IPv6] communicating multiple link (status) to hosts

[Brian E Carpenter <[e-mail]>]

On 21-Mar-24 18:44, Michael Richardson wrote:
> 
> Brian E Carpenter <[e-mail]> wrote:
>      >> {trying to start a new thread}
>      >>
>      >> Lorenzo Colitti <lorenzo=[e-mail]> wrote: > And
>      >> that's bad. The network does not have the capability to leverage >
>      >> multiple paths by using multipath protocols. Only the hosts do.
>      >>
>      >> > Hiding multihoming from the hosts using NPTv6 will prevent hosts
>      >> from > leveraging these protocols to improve bandwidth and resilience.
>      >>
>      >> > While MPTCP is difficult to deploy due to middleboxes, MP-QUIC does
>      >> not > have this problem, and interest in MP-QUIC is building. Even
>      >> without > MP-QUIC, even today QUIC already supports client-initiated
>      >> session > migration. That can be leveraged to maintain existing
>      >> connections alive > when one of the uplinks fails - the client can
>      >> just migrate the > connection to a new source address which will use a
>      >> new uplink. If we > hide the uplinks from the client using NPTv6, we
>      >> cannot do that.
>      >>
>      >> For networks which are more complex than a home network with a single
>      >> LAN segment (no SNACk ) and two routers... how do hosts find out which
>      >> egress routers are up/down/congested/etc.
> 
>      > I think the only universal answer to this is probing. Actually we
>      > learned that from SHIM6.
> 
> So a probe to target, or one to the egress router?

Yes, both. The two probes tell us different things.

> Knowing if the target is down (or a specific address, one of many), vs the
> entire egress is down, or if the ISP in that direction is broken, would be
> useful, right?
> It helps prune the N*M possibilities, right?

Exactly.

    Brian

> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>   -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
> 
> 
>