Re: issue 14 - path testing and congestion

Yes, I agree.

        jak

----- Original Message ----- 
From: "Jari Arkko" <[email protected]>
To: "MOBIKE Mailing List" <[email protected]>
Sent: Sunday, October 31, 2004 8:01 AM
Subject: [Mobike] issue 14 - path testing and congestion


> 
> 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
>