Re: Some clarifications

From: Kacheong Poon (Kacheong.Poon@Eng.Sun.COM)
Date: Tue, Dec 15 1998

Date: Tue, 15 Dec 1998 17:48:20 -0800 (PST)
From: Kacheong Poon <Kacheong.Poon@Eng.Sun.COM>
To: Jim Gettys <>
Cc: Henrik Frystyk Nielsen <>,
Message-ID: <Roam.SIMCSD.>
Subject: Re: Some clarifications

> It is the second packet drop with is a killer, not the first (due to fast 
> restart).  If something could be done to avoid such a long timeout to 
> recover after a second packet drop, this would be goodness.

By second packet drop, did you mean a retransmitted packet got dropped?
If a retransmitted packet got dropped, it will cause a TCP timeout.  But
if what you meant was 2 packets got dropped in a single window, either
NewReno or SACK can recover from it without causing a timeout.  I think
now many implementations have both.

> Without real experience with deployed applications, it isn't clear what
> the consequences of this fate sharing are in practice.

One area it will help is because of the long train of packets, fast
retransmit/recovery or SACK can be invoked to recover from packet loss.  
This is not true if there are only a few packets in transit, which will not
trigger enough duplicate ACKs to invoke those recovery mechanisms.

From TCP's point of view, this is a single stream.  So all our understandings
of TCP's congestion and loss recovery behaviors still apply.  OTOH, if
we use TCP state sharing, it is not clear how multiple streams to the
same host will react to those network events.

The only implementation I know of which has this TCP state sharing is
from the Berkeley folks.  Their simulation results look good.  But since
the shared state structure is accessed by all TCP connections to the
same host whenever a packet is sent or received, it will not scale in real

So I think having a mux over TCP is a better solution to your problem in the
meantime.  I guess this is what you guys think too...

							K. Poon.