TCP problem after sending 3 duplicated Acks

  • Thread starter Thread starter Guest
  • Start date Start date
Toggle sidebar Toggle sidebar
G

Guest

Guest
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Hello,

There is a TCP problem when the server (Windows NT 4)
sends 3 duplicated acks to the client, asking for
determinated lost packet but instead of the client sends
this packet, it ignores this request and sends the next
packet on the queue. What happen is that the server will
ack this new packet and send again a new ack with the
imediate seq number before the duplicated ack sent and so
on. The example below show this situation:


Connection stablished...


Client: Seq=408; ack=158; len=4 (packet a)
Client: Seq=412; ack=158; len=4 (packet b)

Server : Seq=158; ack=412; len=0 (ack packet a)
*** Server : Seq=158; ack=416; len=0 (ack packet b,
for some reason this packet is lost).

As the client received the first ack it sends the
next packet

Client: Seq=416; ack=158; len=4 (packet c)

*** Server : Seq=158; ack=416; len=0 (duplicated ack)

Client: Seq=420; ack=158; len=4 (packet d)

*** Server : Seq=158; ack=416; len=0 (duplicated ack)

Now the server sent 3 duplicated acks but the
client ignores this situation and sends the next packet

Client: Seq=424; ack=158; len=4 (packet e)

Now the problem comes: The server ack the packet
received and send an ack with the seg=412. (Segment
correctly acked before the seg 416)

*** Server : Seq=158; ack=424; len=0
---> Server : Seq=158; ack=412; len=0

Client: Seq=428; ack=158; len=4 (packet f)

And then connection continues with this
problem....

*** Server : Seq=158; ack=428; len=0
---> Server : Seq=158; ack=412; len=0


Is there someone SP that fix this problem? Is there
something else that we can do to fix this problem?

Thanks
 
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

What OS client is running?

"Rafael Gava" <rafael_gava100@hotmail.com> wrote in message
news:1918701c44c98$0ec5a3b0$a401280a@phx.gbl...
> Hello,
>
> There is a TCP problem when the server (Windows NT 4)
> sends 3 duplicated acks to the client, asking for
> determinated lost packet but instead of the client sends
> this packet, it ignores this request and sends the next
> packet on the queue. What happen is that the server will
> ack this new packet and send again a new ack with the
> imediate seq number before the duplicated ack sent and so
> on. The example below show this situation:
>
>
> Connection stablished...
>
>
> Client: Seq=408; ack=158; len=4 (packet a)
> Client: Seq=412; ack=158; len=4 (packet b)
>
> Server : Seq=158; ack=412; len=0 (ack packet a)
> *** Server : Seq=158; ack=416; len=0 (ack packet b,
> for some reason this packet is lost).
>
> As the client received the first ack it sends the
> next packet
>
> Client: Seq=416; ack=158; len=4 (packet c)
>
> *** Server : Seq=158; ack=416; len=0 (duplicated ack)
>
> Client: Seq=420; ack=158; len=4 (packet d)
>
> *** Server : Seq=158; ack=416; len=0 (duplicated ack)
>
> Now the server sent 3 duplicated acks but the
> client ignores this situation and sends the next packet
>
> Client: Seq=424; ack=158; len=4 (packet e)
>
> Now the problem comes: The server ack the packet
> received and send an ack with the seg=412. (Segment
> correctly acked before the seg 416)
>
> *** Server : Seq=158; ack=424; len=0
> ---> Server : Seq=158; ack=412; len=0
>
> Client: Seq=428; ack=158; len=4 (packet f)
>
> And then connection continues with this
> problem....
>
> *** Server : Seq=158; ack=428; len=0
> ---> Server : Seq=158; ack=412; len=0
>
>
> Is there someone SP that fix this problem? Is there
> something else that we can do to fix this problem?
>
> Thanks
>
>
>
 
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Well, actually it's a IP Phone H.323 Alpha Telecom and
the server is a Windows NT 4 with service pack 4.
I agree that the client didn't do the fast retransmit
after receiving the 3rd duplicate ack but what is strange
is the fact that, after sending 3 acks, NT sends the
immediately previous already acked packet and it starts
to accept news sequence packets, acknoledge them and
after that send this wrong ack packet. Why?

Is there some fix to that?

Thanks

Rafael


>-----Original Message-----
>What OS client is running?
>
>"Rafael Gava" <rafael_gava100@hotmail.com> wrote in
message
>news:1918701c44c98$0ec5a3b0$a401280a@phx.gbl...
>> Hello,
>>
>> There is a TCP problem when the server (Windows NT 4)
>> sends 3 duplicated acks to the client, asking for
>> determinated lost packet but instead of the client
sends
>> this packet, it ignores this request and sends the next
>> packet on the queue. What happen is that the server
will
>> ack this new packet and send again a new ack with the
>> imediate seq number before the duplicated ack sent and
so
>> on. The example below show this situation:
>>
>>
>> Connection stablished...
>>
>>
>> Client: Seq=408; ack=158; len=4 (packet a)
>> Client: Seq=412; ack=158; len=4 (packet b)
>>
>> Server : Seq=158; ack=412; len=0 (ack packet a)
>> *** Server : Seq=158; ack=416; len=0 (ack packet b,
>> for some reason this packet is lost).
>>
>> As the client received the first ack it sends the
>> next packet
>>
>> Client: Seq=416; ack=158; len=4 (packet c)
>>
>> *** Server : Seq=158; ack=416; len=0 (duplicated ack)
>>
>> Client: Seq=420; ack=158; len=4 (packet d)
>>
>> *** Server : Seq=158; ack=416; len=0 (duplicated ack)
>>
>> Now the server sent 3 duplicated acks but the
>> client ignores this situation and sends the next packet
>>
>> Client: Seq=424; ack=158; len=4 (packet e)
>>
>> Now the problem comes: The server ack the packet
>> received and send an ack with the seg=412. (Segment
>> correctly acked before the seg 416)
>>
>> *** Server : Seq=158; ack=424; len=0
>> ---> Server : Seq=158; ack=412; len=0
>>
>> Client: Seq=428; ack=158; len=4 (packet f)
>>
>> And then connection continues with this
>> problem....
>>
>> *** Server : Seq=158; ack=428; len=0
>> ---> Server : Seq=158; ack=412; len=0
>>
>>
>> Is there someone SP that fix this problem? Is there
>> something else that we can do to fix this problem?
>>
>> Thanks
>>
>>
>>
>
>
>.
>
 
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Rafael Gava <rafael_gava100@hotmail.com> wrote:
> There is a TCP problem when the server (Windows NT 4) sends 3
> duplicated acks to the client, asking for determinated lost packet
> but instead of the client sends this packet, it ignores this request
> and sends the next packet on the queue.

Might be considered a nit, but the three duplicate ACKs aren't
_really_ the receiver "asking" for a lost segment to be retransmitted.
The sender _infers_ from the reciept of three duplicate ACKs that a
segment has been lost and retransmits it.

Also, for the ACK to be considered a duplicate, it must not do
anything else like open the window or be piggy-backed on data (IIRC).
As such, typically you will have four ACKs with the same ACKno, not
just three.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
 
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Hello Rick,

You are right, when 3 duplicated acks are sent,
theorically, it's to informe the sender that a packet has
been lost and when the sender receives this 3rd ack, It
should proceed with fast retransmit. But in my case the
TCP sender (client) doesn't support fast retransmit and
at this point the receiver (server) sends a wrong ack
with the immediately previous packet received. I don't
know why this behavior. I think that is a bug on Windows
NT TCP stack. What do you think?

>-----Original Message-----
>Rafael Gava <rafael_gava100@hotmail.com> wrote:
>> There is a TCP problem when the server (Windows NT 4)
sends 3
>> duplicated acks to the client, asking for determinated
lost packet
>> but instead of the client sends this packet, it
ignores this request
>> and sends the next packet on the queue.
>
>Might be considered a nit, but the three duplicate ACKs
aren't
>_really_ the receiver "asking" for a lost segment to be
retransmitted.
>The sender _infers_ from the reciept of three duplicate
ACKs that a
>segment has been lost and retransmits it.
>
>Also, for the ACK to be considered a duplicate, it must
not do
>anything else like open the window or be piggy-backed on
data (IIRC).
>As such, typically you will have four ACKs with the same
ACKno, not
>just three.
>
>rick jones
>--
>a wide gulf separates "what if" from "if only"
>these opinions are mine, all mine; HP might not want
them anyway... :)
>feel free to post, OR email to raj in cup.hp.com but
NOT BOTH...
>.
>
 
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Rafael Gava <gava100@ig.com.br> wrote:
> You are right, when 3 duplicated acks are sent, theorically, it's
> to informe the sender that a packet has been lost

sort-of - it simply tells the sender what the next, expected, in-order
sequence number was, nothing more. it is the sender then that is
inferring packet loss.

> and when the sender receives this 3rd ack, It should proceed with
> fast retransmit. But in my case the TCP sender (client) doesn't
> support fast retransmit and at this point the receiver (server)
> sends a wrong ack with the immediately previous packet received. I
> don't know why this behavior. I think that is a bug on Windows NT
> TCP stack. What do you think?

I must confess that I ceased paying specific attention to the NT stack
a long long time ago, and your packet trace expired on my news server
recently.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...
 
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

>-----Original Message-----
>Rafael Gava <gava100@ig.com.br> wrote:
>> You are right, when 3 duplicated acks are sent,
theorically, it's
>> to informe the sender that a packet has been lost
>
>sort-of - it simply tells the sender what the next,
expected, in-order
>sequence number was, nothing more. it is the sender
then that is
>inferring packet loss.

OK...


>
>> and when the sender receives this 3rd ack, It should
proceed with
>> fast retransmit. But in my case the TCP sender
(client) doesn't
>> support fast retransmit and at this point the receiver
(server)
>> sends a wrong ack with the immediately previous packet
received. I
>> don't know why this behavior. I think that is a bug on
Windows NT
>> TCP stack. What do you think?
>
>I must confess that I ceased paying specific attention
to the NT stack
>a long long time ago, and your packet trace expired on
my news server
>recently.

I'm sorry but I didn't understand what you mean.
Anyway, do you know some place where I can post this
message?
If you would mind I can send you the trace.


Rafael
 
Archived from groups: microsoft.public.windowsnt.protocol.tcpip (More info?)

Rafael, can you send me the packet trace?
"Rafael Gava" <rgoliveira@fitec.org.br> wrote in message
news:1c8f801c452d0$8bced640$a101280a@phx.gbl...
>
> >-----Original Message-----
> >Rafael Gava <gava100@ig.com.br> wrote:
> >> You are right, when 3 duplicated acks are sent,
> theorically, it's
> >> to informe the sender that a packet has been lost
> >
> >sort-of - it simply tells the sender what the next,
> expected, in-order
> >sequence number was, nothing more. it is the sender
> then that is
> >inferring packet loss.
>
> OK...
>
>
> >
> >> and when the sender receives this 3rd ack, It should
> proceed with
> >> fast retransmit. But in my case the TCP sender
> (client) doesn't
> >> support fast retransmit and at this point the receiver
> (server)
> >> sends a wrong ack with the immediately previous packet
> received. I
> >> don't know why this behavior. I think that is a bug on
> Windows NT
> >> TCP stack. What do you think?
> >
> >I must confess that I ceased paying specific attention
> to the NT stack
> >a long long time ago, and your packet trace expired on
> my news server
> >recently.
>
> I'm sorry but I didn't understand what you mean.
> Anyway, do you know some place where I can post this
> message?
> If you would mind I can send you the trace.
>
>
> Rafael
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom