Hi Andi,
Thanks for your comments and your help.
I'm aware to RFC 793 statement regarding to ACK.
My problem is that these piggyback ACK can cause duplicate ACK and therefor
invoke the
Fast Retransmit mechanism.
Consider the following situation when the sender send TCP segment and the
receiver send
ACK.
Then the sender send another 3 (or more) segments, and meanwhile it receives 3
piggyback ACKs that have been sent by the receiver (i.e. the receive send 3 TCP
frame
before it receives the 3 packets that has been sent by the Sender).
The sender can assume that these ACKs are duplicate ACK and therefor it enters
into
Fast Retransmit although it shouldn't.
Can you help me with this issue.
Thanks for your effort,
RamiC.
Andi Kleen wrote:
> On Thu, Jul 26, 2001 at 01:19:51PM +0200, Rabeeh Khoury wrote:
> > Hi All,
> >
> > I have noticed (using tcpdump and simple TCP client-server application)
> > that TCP frame are always sent with ACK flag even if the sender doesn't
> > receive new frames (i.e. it send the same Acknowledgment Number).
> >
> > RFC 2581 (section 4.1) states that:
> > "A TCP receiver MUST NOT generate more than one ACK for every
> > incoming
> > segment, other than to update the offered window as the receiving
> > application consumes new data"
> >
> > According to the above statement it seems that LINUX TCP / IP violates this
> > rule.
>
> ACK in this context means a new packet that only contains the ACK.
> If there are packets send for other reason it is ok to contain an ACK,
> in fact RFC793 (that's the real TCP standard) even states that every
> packet in Established should carry an ACK flag.
>
> -Andi
|