RE: Some thoughts about "path failover"

Oh, well, It looks like I am in the minority. It's fine with me if
we want to go with sending RR packets sequentially. However,
I would think the goal would be "path failover" within reasonable time
otherwise what's to stop some vendor implementing the other way unless
there is no added advantage to the other approach.

Another thing I would like to bring up is that I would think this "path
failover"
with RR should only be done when necessary e.g. if an INFO-EXCH of address
update is received, I would think there is no need for RR in this case. 

Regards!
/Jing

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Tuesday, April 27, 2004 1:44 PM
To: Xiang, Jing [BL60:437:EXCH]
Cc: Spencer Dawkins; [email protected]
Subject: Re: [Mobike] Some thoughts about "path failover" 


Jing,

I used, or well, attempted to use, the ARPAnet in the mid-80's before
the deployment of end-system congestion control in TCP.

I don't want to go back.

Since then, responsibility for congestion control has lived primarily
in end systems.  What you are proposing ("just send however much you
feel like") is a step in the wrong direction.  

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.

						- Bill