8159 bytes takes 20 ms, 8160 bytes takes 200 ms?

From: Itjalve (itjalve_at_hotmail.com.(donotspam))
Date: 10/13/04 

Date: Wed, 13 Oct 2004 00:47:04 -0700

Win2k communicating with an embedded system via a point-to-point link using
tcp winsock. 8159 bytes (7 fragments) takes about 20 milli seconds, 8160
bytes (8 fragments) takes about 200 milli seconds.

Its looks like that win2k waits about 150 ms before ack the last, 8,
fragment. Is this a win2k problem or is it my application that is slow?

I have checked my code for delays, but I can't find any problems there, i'm
waiting for packets and the cpu load is less than 10%.

//
this is what etheral shows, a packet with ack and push flag set, and win2k
(192.168.125.2) waits 0.15s before sending the ack
//

No. Time Source Destination Protocol Info
  47727 36.458361 192.168.125.1 192.168.125.2 TCP
5515 > 2179 [PSH, ACK] Seq=2400562144 Ack=2286139454 Win=8192 Len=304

Frame 47727 (358 bytes on wire, 358 bytes captured)
    Arrival Time: Oct 13, 2004 08:13:02.001731000
    Time delta from previous packet: 0.000535000 seconds
    Time since reference or first frame: 36.458361000 seconds
    Frame Number: 47727
    Packet Length: 358 bytes
    Capture Length: 358 bytes
Ethernet II, Src: 00:00:23:08:80:33, Dst: 00:04:76:22:89:fe
    Destination: 00:04:76:22:89:fe (00:04:76:22:89:fe)
    Source: 00:00:23:08:80:33 (00:00:23:08:80:33)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.125.1 (192.168.125.1), Dst Addr:
192.168.125.2 (192.168.125.2)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 344
    Identification: 0x2384 (9092)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x9ac7 (correct)
    Source: 192.168.125.1 (192.168.125.1)
    Destination: 192.168.125.2 (192.168.125.2)
Transmission Control Protocol, Src Port: 5515 (5515), Dst Port: 2179 (2179),
Seq: 2400562144, Ack: 2286139454, Len: 304
    Source port: 5515 (5515)
    Destination port: 2179 (2179)
    Sequence number: 2400562144
    Next sequence number: 2400562448
    Acknowledgement number: 2286139454
    Header length: 20 bytes
    Flags: 0x0018 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 8192
    Checksum: 0x91d9 (correct)
Data (304 bytes)

No. Time Source Destination Protocol Info
  47728 36.609320 192.168.125.2 192.168.125.1 TCP
2179 > 5515 [ACK] Seq=2286139454 Ack=2400562448 Win=17216 [CHECKSUM
INCORRECT] Len=0

Frame 47728 (54 bytes on wire, 54 bytes captured)
    Arrival Time: Oct 13, 2004 08:13:02.152690000
    Time delta from previous packet: 0.150959000 seconds
    Time since reference or first frame: 36.609320000 seconds
    Frame Number: 47728
    Packet Length: 54 bytes
    Capture Length: 54 bytes
Ethernet II, Src: 00:04:76:22:89:fe, Dst: 00:00:23:08:80:33
    Destination: 00:00:23:08:80:33 (00:00:23:08:80:33)
    Source: 00:04:76:22:89:fe (00:04:76:22:89:fe)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.125.2 (192.168.125.2), Dst Addr:
192.168.125.1 (192.168.125.1)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 40
    Identification: 0xf909 (63753)
    Flags: 0x04 (Don't Fragment)
        0... = Reserved bit: Not set
        .1.. = Don't fragment: Set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (0x06)
    Header checksum: 0x0000 (incorrect, should be 0x8671)
    Source: 192.168.125.2 (192.168.125.2)
    Destination: 192.168.125.1 (192.168.125.1)
Transmission Control Protocol, Src Port: 2179 (2179), Dst Port: 5515 (5515),
Seq: 2286139454, Ack: 2400562448, Len: 0
    Source port: 2179 (2179)
    Destination port: 5515 (5515)
    Sequence number: 2286139454
    Acknowledgement number: 2400562448
    Header length: 20 bytes
    Flags: 0x0010 (ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 17216
    Checksum: 0x7b6f (incorrect, should be 0x5689)

Relevant Pages

  • Re: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... the ACK packet. ... Flags: 0x04 (Don't Fragment) ... Header checksum: 0x9ac7 ...
    (microsoft.public.win32.programmer.networks)
  • Re: [Full-Disclosure] A new TCP/IP blind data injection technique?
    ... For example the BorderWare Firewall will not accept fragmented packets, ... Then pass or drop the packet. ... > should be fairly easy to turn this into a practical attack. ... The other fragment of Bob's packet carry the ...
    (Full-Disclosure)
  • Re: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... look for Nagle algorithm in TCP ... > this is what etheral shows, a packet with ack and push flag set, and win2k ... > Header length: 20 bytes ... > Fragment offset: 0 ...
    (microsoft.public.win32.programmer.networks)
  • RE: 8159 bytes takes 20 ms, 8160 bytes takes 200 ms?
    ... > this is what etheral shows, a packet with ack and push flag set, and win2k ... > Time since reference or first frame: ... > Header length: 20 bytes ... > Fragment offset: 0 ...
    (microsoft.public.win32.programmer.networks)
  • Re: IP_HDRINCL
    ... Because the operating system cannot fragment a packet without changing ... the header. ... If the OS fragments the packet, it would have to modify the headers. ...
    (comp.unix.programmer)
Loading