[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ns] a small bug in delayed ACK ?
>
> > So, what I am willing to indicate is that an ACK of some "next expected"
> > packets should not be delayed.
> > for example, The sender send W packets from seq. 1.
>
> large initial windows?
No. I just exemplify a case.
> > Assuming the first W-1
> > packets are dropped and the last W-th packet arrived at the receiver,
> > after any kind of retransmission method, the sender retransmit the dropped
> > packet from seq. 1. At this time, the receiver has "next expected" seq. 1
> > but the receiver should not delayed the ACK of it.
>
> Why shouldn't the receiver delay the ACK? Delayed acks have to start
> somewhere; you're basically saying that delayed acks should be
> exclusively second-in-order-and-onwards, rather than
> first-in-order-and-onwards. I'd argue that this first packet is not
> out of order as far as the window and its needs are concerned, and is
> therefore correctly delayed.
It may cause performace decrease. In the view of the sender, it is in
recovery period and expects that the receiver may send an ACK per every
packet.
If timeout occurs, its window increases very slowly.
Otherwise, (NewReno with partial window deplation or rate halving
algorithm), the sender try to adapt the window size to half after recovery
ends to increase its performace. Hence it may reduce more than half if the
receiver does not send immediately for a packet arrival.
I heard that it is a known bug and corrected in current version of TCP in
linux and BSD.
Thanks.
jchee
-------------------------------------------------------------
Changhee Joo [email protected]
School of Electrical Engineering, Seoul National Univ., Korea
-------------------------------------------------------------