RE: issue 14 - path testing and congestion

In my opinion path-testing/path-failover should be a general
module, output of which MOBIKE should use. Trying to solve this
in the framework of MOBIKE may not be the right place of this 
functionality, as this could be needed outside MOBIKE also.

I would rather make use of the information gotten from some other
module outside of MOBIKE. If there is none, we need to initiate
a general effort rather than overloading MOBIKE in an unmodular
way.

Atul

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On
> Behalf Of ext Jari Arkko
> Sent: Sunday, October 31, 2004 11:02 AM
> To: MOBIKE Mailing List
> 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
>