TCPIP sequence number question - VMS

This is a discussion on TCPIP sequence number question - VMS ; Ok, this isn't specifically VMS related but here it goes... Say I am sending TCP data packets with sequence numbers #10 #11 #12 #13 #14 and #15. Someone meddles with my traffic and changes, while in transit, the sequence number ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: TCPIP sequence number question

  1. TCPIP sequence number question

    Ok, this isn't specifically VMS related but here it goes...

    Say I am sending TCP data packets with sequence numbers #10 #11 #12 #13
    #14 and #15.

    Someone meddles with my traffic and changes, while in transit, the
    sequence number of the second packet from #11 to #789

    How will the receiver behave upon receiving the packet with sequence
    number #789 ? Will it wait a certain amount of time to see if the
    packet #11 will arrive out of sequence before declaring #11 to be lost
    and sending NAK to the sender ?

    How long will it wait before declaring #11 to be lost at sea ?

    base on what I read, the recipient will send an ack confirming it has
    received all data intact until/including #10. (instead of sending an
    actual "I haven't received #11").

    Once the sender has realised the recipient hasn't received #11, will the
    sender then resend #11 and all subsequent packets ?

    With windowing, will the sender end up stopping transmission at one
    point, waiting for an ack ? Or will the "sorry I didn,t get #11"
    realisation reach the sender before the sender has finished sending all
    packets permitted in the sliding window ?

    aka: will the data line become idle for some time, or will it remain
    constantly in full use with packets flowing with retransmissions here
    and there ?

  2. Re: TCPIP sequence number question

    JF Mezei skrev:
    > Ok, this isn't specifically VMS related but here it goes...


    And this is a little late in answering, but anyway...

    > Say I am sending TCP data packets with sequence numbers #10 #11 #12 #13
    > #14 and #15.
    >
    > Someone meddles with my traffic and changes, while in transit, the
    > sequence number of the second packet from #11 to #789
    >
    > How will the receiver behave upon receiving the packet with sequence
    > number #789 ? Will it wait a certain amount of time to see if the
    > packet #11 will arrive out of sequence before declaring #11 to be lost
    > and sending NAK to the sender ?


    The received should, assuming that #789 is outside the window, just toss the
    data and pretend it didn't see it. If the data is inside the window, it might be
    stored for later usage.

    > How long will it wait before declaring #11 to be lost at sea ?


    That depends. TCP/IP implementations can do this differently, but it is
    recommended that the average round trip time is measured, and that timeouts are
    set to about 2*rtt.

    But this is all done by the sender. There is no NAK capability in TCP/IP.

    > base on what I read, the recipient will send an ack confirming it has
    > received all data intact until/including #10. (instead of sending an
    > actual "I haven't received #11").


    Correct.

    > Once the sender has realised the recipient hasn't received #11, will the
    > sender then resend #11 and all subsequent packets ?


    That depends on the implementation. It could do either.
    Since TCP uses a sliding window, a lot of data can be outstanding at the time of
    a retransmission. If all data after the data not acknowledged is resent or not
    is not defined. However, it might be wise to back off, and not immediately start
    retransmitting all data again.

    > With windowing, will the sender end up stopping transmission at one
    > point, waiting for an ack ? Or will the "sorry I didn,t get #11"
    > realisation reach the sender before the sender has finished sending all
    > packets permitted in the sliding window ?


    There is no NAK packet. TCP uses a sliding window to define which data can be
    sent and be outstanding before any ACK arrives. In addition, you also have a
    transmission window, which is used to do flow control. And this is normally all
    regulated by the amount of retransmissions you get.
    And TCP don't acknowledge all data. ACK to a certain sequence number implies
    that all data up until that sequence number is acked.

    The TCP flow control, congestion, retransmission, round trip calculation and
    back off algorithms are rather complex, and not easy to answer like this.

    > aka: will the data line become idle for some time, or will it remain
    > constantly in full use with packets flowing with retransmissions here
    > and there ?


    No, TCP tries to be smart and not fill the net with retransmissions. But there
    is definitely some leeway for implementors to do things as they see fit as well,
    so it's not always possible to give a straight answer.

    Johnny

    --
    Johnny Billquist || "I'm on a bus
    || on a psychedelic trip
    email: bqt@softjar.se || Reading murder books
    pdp is alive! || tryin' to stay hip" - B. Idol

  3. Re: TCPIP sequence number question

    Johnny Billquist wrote:
    >
    > That depends. TCP/IP implementations can do this differently, but it is
    > recommended that the average round trip time is measured, and that timeouts are
    > set to about 2*rtt.
    >
    > But this is all done by the sender. There is no NAK capability in TCP/IP.


    I've since used wireshark to trace packets. Found that at least OSX'
    stack, when it seens a missing packet in a sequence, immediatly start to
    ACK the previous packet again, until the missing packet is resent. (aka:
    multiple ACKs for the packet before the missing one).

    For the data I have seen, this happens well before the window fills up.

    I ended up reading and understanding 791 and 793 quite a bit. (but
    haven't seen the sliding window adjustements suggested by the RFcs in my
    traces).



    > There is no NAK packet.


    Based on what I have read/seen, sending multiple ACKs for packet #1 is
    tantamount to a NAK of packet 2.


  4. Re: TCPIP sequence number question

    JF Mezei skrev:
    > Johnny Billquist wrote:
    >> That depends. TCP/IP implementations can do this differently, but it is
    >> recommended that the average round trip time is measured, and that timeouts are
    >> set to about 2*rtt.
    >>
    >> But this is all done by the sender. There is no NAK capability in TCP/IP.

    >
    > I've since used wireshark to trace packets. Found that at least OSX'
    > stack, when it seens a missing packet in a sequence, immediatly start to
    > ACK the previous packet again, until the missing packet is resent. (aka:
    > multiple ACKs for the packet before the missing one).


    Well, the receiver is just trying it's best to get the attention of the
    transmitter, using whatever means are available.

    > For the data I have seen, this happens well before the window fills up.
    >
    > I ended up reading and understanding 791 and 793 quite a bit. (but
    > haven't seen the sliding window adjustements suggested by the RFcs in my
    > traces).


    Good that you started digging through the RFCs. :-)
    However, note that there have been additional details added at later dates,
    which you should probably also read.

    >> There is no NAK packet.

    >
    > Based on what I have read/seen, sending multiple ACKs for packet #1 is
    > tantamount to a NAK of packet 2.


    Not exactly. But it's the best you can do in TCP. The sender can very well wait
    for a full timeout of #2 before resending it, when you send an ACK for #1. If
    you had a positive NAK, the sender should probably do a resend immediately. This
    is something you can't do with TCP.

    But you seem to be rolling here, so I think you'll be able to figure out the
    rest as well. :-)

    Johnny


    --
    Johnny Billquist || "I'm on a bus
    || on a psychedelic trip
    email: bqt@softjar.se || Reading murder books
    pdp is alive! || tryin' to stay hip" - B. Idol

  5. Re: TCPIP sequence number question

    Johnny Billquist wrote:

    > Not exactly. But it's the best you can do in TCP. The sender can very well wait
    > for a full timeout of #2 before resending it, when you send an ACK for #1. If
    > you had a positive NAK, the sender should probably do a resend immediately. This
    > is something you can't do with TCP.


    There are some "fast Retransmission" events in the wireshark logs for
    some types of lost packets.

    Damm it, I just found some "reset" packets. There is no way for me to
    know if they were forged by Bell Canada (like Comcast) or if they were
    forged by the remote ISPs.

    > No. Time Source Destination Protocol Info
    > 3037 46.025138 98.215.114.81 10.0.0.20 TCP 63018 > 6810 [SYN] Seq=0 Len=0 MSS=1452 TSV=20871097 TSER=0 WS=5
    > 3038 46.025310 10.0.0.20 98.215.114.81 TCP 6810 > 63018 [SYN, ACK] Seq=0 Ack=1 Win=131070 Len=0 MSS=1460 WS=1 TSV=1807270126 TSER=20871097
    > 3043 46.146150 98.215.114.81 10.0.0.20 TCP 63018 > 6810 [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=20871127 TSER=1807270126
    > 3044 46.146264 10.0.0.20 98.215.114.81 TCP [TCP Window Update] 6810 > 63018 [ACK] Seq=1 Ack=1 Win=131040 Len=0 TSV=1807270127 TSER=20871127
    > 3056 46.274495 98.215.114.81 10.0.0.20 BitTorrent Handshake
    > 3057 46.274572 10.0.0.20 98.215.114.81 TCP 6810 > 63018 [ACK] Seq=0 Ack=0 Win=65486 Len=0 TSV=1807270127 TSER=20871159
    > 3077 46.524564 10.0.0.20 98.215.114.81 BitTorrent Handshake Continuation data
    > 3088 46.641754 98.215.114.81 10.0.0.20 TCP 63018 > 6810 [ACK] Seq=0 Ack=130 Win=216 Len=0 TSV=20871252 TSER=1807270127
    > 3089 46.641940 10.0.0.20 98.215.114.81 BitTorrent Bitfield, Len:0x1a6
    > 3240 49.141050 10.0.0.20 98.215.114.81 BitTorrent [TCP Retransmission] Bitfield, Len:0x1a6
    > 3252 49.254053 98.215.114.81 10.0.0.20 TCP 63018 > 6810 [RST] Seq=0 Len=0 TSV=20872284 TSER=0
    > 3253 49.254901 98.215.114.81 10.0.0.20 TCP 63018 > 6810 [RST] Seq=12503 Len=0 TSV=20872284 TSER=0
    > 3255 49.277092 98.215.114.81 10.0.0.20 TCP 63018 > 6810 [RST] Seq=0 Len=0



    Wireshark is pretty amazing. (in the above, sequence numbers are
    relative to negotiations during call setup).

    Now, I have found 1 stream that didn't have a reset in it. So I guess
    Bell might not be the one introducing RESETS here and there to kill off
    connections and slow throughput.

  6. Re: TCPIP sequence number question

    In article , Johnny Billquist writes:
    > JF Mezei skrev:
    >
    >> For the data I have seen, this happens well before the window fills up.
    >>
    >> I ended up reading and understanding 791 and 793 quite a bit. (but
    >> haven't seen the sliding window adjustements suggested by the RFcs in my
    >> traces).

    >
    > Good that you started digging through the RFCs. :-)
    > However, note that there have been additional details added at later dates,
    > which you should probably also read.
    >


    In particular JF, you need to read the Host Requirements RFCs (RFC1122 and
    RFC1123). You may also find RFC1127 of interest.

    Simon.

    --
    Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
    Microsoft: Bringing you 1980's technology to a 21st century world

+ Reply to Thread