Is a TCP sender authorized to send data in excess of last client ack + window size ? - TCP-IP

This is a discussion on Is a TCP sender authorized to send data in excess of last client ack + window size ? - TCP-IP ; Hello, To put it simple, I'm facing an issue where a TCP sender sends data outside the client window. Practically: * the connection was setup with window size 65535 (there is no window update in the session and there is ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Is a TCP sender authorized to send data in excess of last client ack + window size ?

  1. Is a TCP sender authorized to send data in excess of last client ack + window size ?

    Hello,

    To put it simple, I'm facing an issue where a TCP sender sends data outside
    the client window.

    Practically:
    * the connection was setup with window size 65535 (there is no window update
    in the session and there is window scaling option in SYN packet)
    * the client last ACK is a segment with ack=171953
    * the server is sending data up to seq=261497

    In my understanding, data in the range of 171953 to 237488 (= 171953 +
    65535) are in the current window, and when last ack received is 171953 the
    server should stop sending when it reaches seq=237488.

    My question is if it's illegal for the sender to send data with sequence
    number higher than 237488 when the last client acknowledgement was 171953
    and the window size is 65535 ?

    Thank you.


  2. Re: Is a TCP sender authorized to send data in excess of last clientack + window size ?

    On Aug 4, 10:30 am, "Ben_" wrote:

    > * the connection was setup with window size 65535 (there is no window update
    > in the session and there is window scaling option in SYN packet)
    > * the client last ACK is a segment with ack=171953
    > * the server is sending data up to seq=261497


    It's not completely clear that you're interpreting the window size
    correctly, though you certainly may be.
    Is 65535 the value in the window size field, or is it the size of the
    window? You said that window scaling is enabled, but haven't stated
    the scaling factor, nor whether both ends set scaling options.

    If both sides support scaling, and you're reporting the UNscaled
    window size, then the sender probably hasn't exceeded the window.

    OTOH, it's possible that the sender is breaking the rules. Some TCPs
    may optimistically exceed the stated window size with the hope that
    the window will have moved by the time out-of-bounds segments arrive.

    Some TCPs are just broken, and send data outside the bounds of the
    window.

    > In my understanding, data in the range of 171953 to 237488 (= 171953 +
    > 65535) are in the current window, and when last ack received is 171953 the
    > server should stop sending when it reaches seq=237488.


    You said window scaling is enabled. In that case, 65535 may not mean
    65535 :-)

    > My question is if it's illegal for the sender to send data with sequence
    > number higher than 237488 when the last client acknowledgement was 171953
    > and the window size is 65535 ?


    Data with sequence numbers higher than last ack + window size is
    expected to be ignored.

    /chris

  3. Re: Is a TCP sender authorized to send data in excess of last client ack + window size ?

    >> * the connection was setup with window size 65535 (there is no window
    >> update
    >> in the session and there is window scaling option in SYN packet)
    >> * the client last ACK is a segment with ack=171953
    >> * the server is sending data up to seq=261497

    >
    > It's not completely clear that you're interpreting the window size
    > correctly, though you certainly may be.


    The chance is I can be somewhat mistaken, because I'm self-educated on
    TCP/IP by investigating bugs produced by those who were supposed to be more
    educated than me... :-)

    > Is 65535 the value in the window size field, or is it the size of the
    > window? You said that window scaling is enabled, but haven't stated
    > the scaling factor, nor whether both ends set scaling options.


    Sorry. A 'not' was missing and compromised your reasoning.

    To be correct, it had to read "there is *NO* window scaling option in SYN
    packet" (looking at the options of the SYN packet with Wireshark).

    With 65535, I mean to refer to the size of the window agreed in the 3 way
    handshake, not the Win=xxx field in the other segments of the stream.

    > If both sides support scaling, and you're reporting the UNscaled
    > window size, then the sender probably hasn't exceeded the window.
    >
    > OTOH, it's possible that the sender is breaking the rules. Some TCPs
    > may optimistically exceed the stated window size with the hope that
    > the window will have moved by the time out-of-bounds segments arrive.
    >
    > Some TCPs are just broken, and send data outside the bounds of the
    > window.


    I also tend to believe that the problem is sort of over-optimization /
    over-optimistic behavior, but I have no facts and found no documentation to
    support this argument.

    In my case, the TCP sender is Windows 2003 (R2, I believe).

    >> In my understanding, data in the range of 171953 to 237488 (= 171953 +
    >> 65535) are in the current window, and when last ack received is 171953
    >> the
    >> server should stop sending when it reaches seq=237488.

    >
    > You said window scaling is enabled. In that case, 65535 may not mean
    > 65535 :-)


    Yes, (I think) I understand that with window scaling the current window
    would be multiplied by the factor defined by the window scaling option,
    which I mistakenly said is active, but is actually not.

    >> My question is if it's illegal for the sender to send data with sequence
    >> number higher than 237488 when the last client acknowledgement was 171953
    >> and the window size is 65535 ?

    >
    > Data with sequence numbers higher than last ack + window size is
    > expected to be ignored.


    That's also my understanding, but I couldn't find a formal definition of
    this behavior. Ideally, an excerpt of an RFC or well-accepted tutorial. Do
    you know where I could find this ?


  4. Re: Is a TCP sender authorized to send data in excess of last client ack + window size ?

    Ben_ wrote:
    > Ideally, an excerpt of an RFC or well-accepted tutorial. Do you know
    > where I could find this ?


    http://www.ietf.org/

    IIRC the initial RFC for TCP is 793.

    rick jones
    --
    web2.0 n, the dot.com reunion tour...
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  5. Re: Is a TCP sender authorized to send data in excess of last client ack + window size ?

    >> Ideally, an excerpt of an RFC or well-accepted tutorial. Do you know
    >> where I could find this ?

    >
    > http://www.ietf.org/
    >
    > IIRC the initial RFC for TCP is 793.
    >


    Well, yes, I had already been through the RFC, but with no luck. Hence me
    asking for pointing to the relevant excerpt.

    In the meanwhile, I took the time to read a bit more carefully and the
    following hits my eye:
    "
    1.5. Operation
    (...)
    Flow Control:
    (...) The window indicates an
    allowed number of octets that the sender may transmit before
    receiving further permission.
    (...)
    3.2. Terminology
    (...)
    Send Sequence Space
    1 2 3 4
    ----------|----------|----------|----------
    SND.UNA SND.NXT SND.UNA
    +SND.WND
    1 - old sequence numbers which have been acknowledged
    2 - sequence numbers of unacknowledged data
    3 - sequence numbers allowed for new data transmission
    4 - future sequence numbers which are not yet allowed
    Send Sequence Space
    Figure 4.
    The send window is the portion of the sequence space labeled 3 in
    figure 4.
    (...)
    GLOSSARY
    (...)
    send window
    This represents the sequence numbers which the remote
    (receiving) TCP is willing to receive. It is the value of the
    window field specified in segments from the remote (data
    receiving) TCP. The range of new sequence numbers which may
    be emitted by a TCP lies between SND.NXT and
    SND.UNA + SND.WND - 1. (Retransmissions of sequence numbers
    between SND.UNA and SND.NXT are expected, of course.)
    "

    Now, considering my case: last client ack is 171953 and the window field in
    the ack segment is 65535.

    So, as per 1.5, the sender has not received "further permission" to data
    with sequence higher than 237488 (= 171953 + 65535).

    And, as per 3.2, such data are not in "space labeled 3" but in space "4 -
    future sequence numbers which are not yet allowed".

    Also, browsing through RFC 1180 shows the following;
    "
    7. Transmission Control Protocol
    (...) The window size determines the amount of data that can be transmitted
    before an acknowledgement is required. (...)
    "

    So, this section really means to say that an "acknowledge is required"
    before sending more data. So, the TCP sender should stop at sequence 237488,
    because the last ack was 171953 and the window is 65535.

    Does this rationale look correct to you ?


  6. Re: Is a TCP sender authorized to send data in excess of last client ack + window size ?

    > Does this rationale look correct to you ?

    OK, I found it !!

    It's exactly this issue I'm facing with a Juniper firewall:
    http://kb.juniper.net/KB9080.

    Clearly, in their eyes, the TCP sender *must* observe the sliding window
    principle and refrain from sending too much data.

    However, I tend to disagree with the way they decide to drop segments.

    Saying that "reason for the drop of the retransmitted packet is that its
    sequence number is smaller than the seqnr of the last sent packet minus the
    window size" means they don't look at the client acknoweldgment.

    With their rule they're dropping segments *in* the window instead of
    segments *outside* the window.

    Is this standard practice accross firewall vendors ??


    -----------
    "
    Synopsis

    If the host does not comply with the TCP sliding windows principle, do not
    use the TCP sequence check feature in the firewall.

    Problem

    Some types of traffic may have difficulty working properly when tcp sequence
    number check is enabled (unset flow no-tcp-seq-check), yet will work
    correctly when the feature is disabled (set flow no-tcp-seq-check).

    This problem mainly occurs in file transfers in combination with packet
    loss. During the file transfer the session stops and is timed out.

    Solution

    The issue is due to the host not complying with the TCP sliding window
    principle and sending out more traffic than fits in the TCP sliding window.

    This can cause problems when there is packet loss. When the sliding window
    is over filled because the sender did not limit itself to the window size
    indicated by the receiver, retransmissions will be dropped by the firewall.
    This causes the TCP session to time-out. The reason for the drop of the
    retransmitted packet is that its sequence number is smaller than the seqnr
    of the last sent packet minus the window size.

    If a host acts in this (non-standard) way, we advise not to use the TCP
    sequence number check feature.
    "
    ------------


  7. Re: Is a TCP sender authorized to send data in excess of last client ack + window size ?

    In article <4898c1e2$0$2863$ba620e4c@news.skynet.be>,
    "Ben_" wrote:

    > > Does this rationale look correct to you ?

    >
    > OK, I found it !!
    >
    > It's exactly this issue I'm facing with a Juniper firewall:
    > http://kb.juniper.net/KB9080.
    >
    > Clearly, in their eyes, the TCP sender *must* observe the sliding window
    > principle and refrain from sending too much data.
    >
    > However, I tend to disagree with the way they decide to drop segments.
    >
    > Saying that "reason for the drop of the retransmitted packet is that its
    > sequence number is smaller than the seqnr of the last sent packet minus the
    > window size" means they don't look at the client acknoweldgment.
    >
    > With their rule they're dropping segments *in* the window instead of
    > segments *outside* the window.


    No, they're dropping packets before the BEGINNING of the window.
    They're assuming that the sender obeys the window size limit. If they
    see a packet with sequence number N, and the window size is W, that must
    mean that sequence number N-W was acknowledged. That means that every
    packet with lower sequence numbers has been received successfully, and
    doesn't need to be retransmitted. If such a packet is received, it's
    dropped because it's an unnecessary retransmission.

    >
    > Is this standard practice accross firewall vendors ??
    >
    >
    > -----------
    > "
    > Synopsis
    >
    > If the host does not comply with the TCP sliding windows principle, do not
    > use the TCP sequence check feature in the firewall.
    >
    > Problem
    >
    > Some types of traffic may have difficulty working properly when tcp sequence
    > number check is enabled (unset flow no-tcp-seq-check), yet will work
    > correctly when the feature is disabled (set flow no-tcp-seq-check).
    >
    > This problem mainly occurs in file transfers in combination with packet
    > loss. During the file transfer the session stops and is timed out.
    >
    > Solution
    >
    > The issue is due to the host not complying with the TCP sliding window
    > principle and sending out more traffic than fits in the TCP sliding window.
    >
    > This can cause problems when there is packet loss. When the sliding window
    > is over filled because the sender did not limit itself to the window size
    > indicated by the receiver, retransmissions will be dropped by the firewall.
    > This causes the TCP session to time-out. The reason for the drop of the
    > retransmitted packet is that its sequence number is smaller than the seqnr
    > of the last sent packet minus the window size.
    >
    > If a host acts in this (non-standard) way, we advise not to use the TCP
    > sequence number check feature.
    > "
    > ------------


    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  8. Re: Is a TCP sender authorized to send data in excess of last client ack + window size ?

    >> It's exactly this issue I'm facing with a Juniper firewall:
    >> http://kb.juniper.net/KB9080.
    >>
    >> Clearly, in their eyes, the TCP sender *must* observe the sliding window
    >> principle and refrain from sending too much data.
    >>
    >> However, I tend to disagree with the way they decide to drop segments.
    >>
    >> Saying that "reason for the drop of the retransmitted packet is that its
    >> sequence number is smaller than the seqnr of the last sent packet minus
    >> the
    >> window size" means they don't look at the client acknoweldgment.
    >>
    >> With their rule they're dropping segments *in* the window instead of
    >> segments *outside* the window.

    >
    > No, they're dropping packets before the BEGINNING of the window.


    OK, it's good to be precise. Their explanation is indeed not that they are
    dropping all packets *outside* the window, but only those before the
    beginning of the window. They're not talking about the upper boundary of the
    sliding window.

    > They're assuming that the sender obeys the window size limit. If they
    > see a packet with sequence number N, and the window size is W, that must
    > mean that sequence number N-W was acknowledged.


    Don't you think they are taking here a very unsafe assumption ?

    Especially in regards of TCP's Robustness Principle ("(...) be liberal in
    what you accept from others").

    > That means that every
    > packet with lower sequence numbers has been received successfully, and
    > doesn't need to be retransmitted. If such a packet is received, it's
    > dropped because it's an unnecessary retransmission.


    It appears we're now with two conceptions of the boundaries of the sliding
    window: the RFC says "highest client ack + window size" vs. firewall says
    "highest server seq - window size".

    They consider the retransmission need dropped because outside "their"
    sliding window. But these packets are inside the RFC sliding window.

    So, I find they are dropping the wrong segments.

    If they have to drop something, it's when the TCP sender doesn't obey the
    window size limit. So, when it sends data above the upper bound on the
    sliding window (as defined by the RFC), not when it retransmits.

    Is my reasoning right or is it broken somewhere ?

    And do you also find the firewall implements a weird / unsafe logic ?


+ Reply to Thread