Subject: (ION) NHRP : Packets in flight 2 - Path Switching Delay

From: Reinaldo Penno Filho <[email-masked]>
Date: Tue, 27 Jan 1998 00:18:37 -0200 (EDT)

HI,

Few weeks ago I wrote to this list concerned about possible
retransmissions and/or timeout due to the fact that at some time there
would be a routed path and cut through path at the same time. As we know
the routed path latency is much bigger then the cut through one. 

I gave the LANE example of a flush protocol to avoid this. Someone (sorry
I didn't kept the message) argued that LANE avoided flushing for protocols
like IP (that can do their own fragmentation/reassembly).

I agree that this make sense; if IP can do it, let him do the work...

I went thorough the LANE spec and didn't find anything that mentioned that
IP should deserve a particular treatment. What I found that I think its
interesting is that some clients can avoid the flushing protocol by
applying a "Path Switching Delay". 

"The Path Switching Delay is the time since sending a frame to the routed
path (aka BUS path) after which the client may assume that the frame has
been either discarded or delivered to the recipient. So this may be used
to bypass the Flush Protocol ". 

"Value Recommended: Minimum = 1 second, Default=6 seconds, Maximum=8
seconds"

I think LANE avoid flushing for IP by applying the PAth Switching Delay
procedure. I agree with my coleague that putting the flush protocol in
NHRP will cause unnecessary overhead, but putting a procedure similar to
the path switching delay maybe its interesting.

Best Regards,

Reinaldo

----------------------------------------------------------------------------
Reinaldo Penno Filho
Brazilian Research Network 
[email-masked]
----------------------------------------------------------------------------

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.