However, its a can of worms because exactly how one responds depends on
the number of packets lost and whether your running Tahoe or Reno.
Tahoe will retransmit packets that have been successfully delivered if
there are multiple packet losses within the window. Reno will not, but
retransmits lost packets slower (at most one per RTT). This last effect
means that for modern (e.g. Reno) TCP's without SACK dropping multiple
packets in a flow is bad because you need one round trip per lost packet
in order to retransmit. Worse, Fast Recovery works really poorly when
multiple packets are dropped from a window so this is actually a far
stronger congestion control signal than simply dropping a single packet.
- Stefan
> -----Original Message-----
> From: Neal Cardwell [SMTP:cardwell@cs.washington.edu]
> Sent: Thursday, May 21, 1998 5:01 PM
> To: syn@cs
> Subject: RE: early packet train discard?
>
>
> > It depends on how big your window is, where cwnd is in relation to
> the
> > advertised window and how many packets get lost. If the window is
> small
> > then TCP is go-back-N.
>
> I thought if i sent packets 11, 12, 13, and packet 11 gets dropped,
> then
> (with no SACK) i'll time out and cut cwnd to 1, retransmit packet 11,
> then
> get an ACK for 13 (since the receiver buffered 12 and 13), and then
> i'll
> send 14 and 15, etc.
>
> If true, then if some router had, for better or worse, dropped 12 and
> 13
> as well, then i'd need another RTT before i can send 14 and 15.
>
> neal
>
>