Re: issue 14 - path testing and congestion

This issue is now closed, as suggested below.
Pasi, can you mark it closed on the list?

Also, Atul raised the "division of work" question
that we have also been discussing in other contexts.
Perhaps we should open a new issue number for that
too, maybe you Pasi can set that up as well. We will
discuss the division of work issue face-to-face in
the meeting on Tuesday.

--Jari

Jari Arkko wrote:
> 
> I'd like to close this issue based on what Bill Sommerfeld
> said about it:
> 
>   While there may be situations where you can ignore congestion control
>   best practices and get excellent benchmark results under carefully
>   controlled conditions, such environments tend to be unstable under
>   load and are therefore unsuitable for production use.
> 
>   Path failover is likely to be triggered in as the result of packet
>   loss.  Packet loss is often caused by congestion.  Sending a burst of
>   packets when you detect an event which may be the result of congestion
>   has been considered a really bad idea for about two decades now.
> 
>   We MUST NOT produce a spec which, if deployed, would force router
>   vendors to produce countermeasures to protect the rest of the network
>   from us.
> 
> As a result, I'd like to suggest that when peers test candidate addresses
> (or pairs), they SHOULD attempt testing all of them, but MUST do this
> sequentially (based on an implementation-dependent priority order) and
> using an exponential back-off procedure.
> 
> Ok for everyone? I'll assume so unless I hear from you in the next
> couple of days.
> 
> Note that the unpleasant but necessary side-effect is that only a
> small set of multihoming addresses on both sides is practical. On
> larger sets, testing takes too long. Some math about this in
> 
>   http://www.arkko.com/publications/multi6/faildet.html#anchor9
> 
> --Jari
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
>