Three Way handshake Q: - TCP-IP

This is a discussion on Three Way handshake Q: - TCP-IP ; Hi, I have read couple of books about this - but none of them state this explicitly, can someone here clarify: Once in ESTABLISHED state, if SYN+ACK is received, then what is the behavior of the node. 1. A -> ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Three Way handshake Q:

  1. Three Way handshake Q:

    Hi,
    I have read couple of books about this - but none of them state this
    explicitly, can someone here clarify:

    Once in ESTABLISHED state, if SYN+ACK is received, then what is the
    behavior of the node.

    1. A -> send SYN --> B
    2. A <- SYN + ACK <- B
    3. A -> ACK ---> B
    4. A <--- SYN+ACK <- B

    I was hoping that at step 4, when A gets the SYN+ACK, it will ack it and
    start over again. Only four packets are exchanged in this situation, i
    am not saying that after a lot of packets are exchanged, 'SYN+ACK' comes
    in...

    can someone clarify ?
    thanks,
    ravi

  2. Re: Three Way handshake Q:

    On Oct 1, 10:57*pm, Ravi wrote:
    > Hi,
    > * * I have read couple of books about this - but none of them state this
    > explicitly, can someone here clarify:
    >
    > Once in ESTABLISHED state, if SYN+ACK is received, then what is the
    > behavior of the node.
    >
    > 1. A -> send SYN --> B
    > 2. A <- SYN + ACK <- B
    > 3. A -> *ACK ---> * *B
    > 4. A <--- SYN+ACK <- B
    >
    > I was hoping that at step 4, when A gets the SYN+ACK, it will ack it and
    > start over again.


    No. It will correctly reject the packet as a duplicate.

    > Only four packets are exchanged in this situation, i
    > am not saying that after a lot of packets are exchanged, 'SYN+ACK' comes
    > in...
    >
    > can someone clarify ?


    Duplicate packets are, and should be, rejected. They don't prove that
    packet 3 was lost, since the duplicate packet could have been sent
    right before packet 3 was received.

    DS

  3. Re: Three Way handshake Q:

    David Schwartz wrote:
    > On Oct 1, 10:57 pm, Ravi wrote:
    >> Hi,
    >> I have read couple of books about this - but none of them state this
    >> explicitly, can someone here clarify:
    >>
    >> Once in ESTABLISHED state, if SYN+ACK is received, then what is the
    >> behavior of the node.
    >>
    >> 1. A -> send SYN --> B
    >> 2. A <- SYN + ACK <- B
    >> 3. A -> ACK ---> B
    >> 4. A <--- SYN+ACK <- B
    >>
    >> I was hoping that at step 4, when A gets the SYN+ACK, it will ack it and
    >> start over again.

    >
    > No. It will correctly reject the packet as a duplicate.
    >
    >> Only four packets are exchanged in this situation, i
    >> am not saying that after a lot of packets are exchanged, 'SYN+ACK' comes
    >> in...
    >>
    >> can someone clarify ?

    >
    > Duplicate packets are, and should be, rejected. They don't prove that
    > packet 3 was lost, since the duplicate packet could have been sent
    > right before packet 3 was received.



    in the wireshark tap, i am seeing that packet 4 is repeated again and
    again. What if the packet 3 is lost ? the setup is aborted ?

    thanks,
    ravi

    >
    > DS


  4. Re: Three Way handshake Q:

    On Oct 2, 9:50*am, Ravi wrote:

    > >> 1. A -> send SYN --> B
    > >> 2. A <- SYN + ACK <- B
    > >> 3. A -> *ACK ---> * *B
    > >> 4. A <--- SYN+ACK <- B


    > > Duplicate packets are, and should be, rejected. They don't prove that
    > > packet 3 was lost, since the duplicate packet could have been sent
    > > right before packet 3 was received.


    > in the wireshark tap, i am seeing that packet 4 is repeated again and
    > again. What if the packet 3 is lost ? the setup is aborted ?


    The setup already completed. Why would it be aborted?

    The TCP handshake is three-way. All three things have happened. The
    setup is complete.

    DS

  5. Re: Three Way handshake Q:

    David Schwartz wrote:
    > On Oct 2, 9:50?am, Ravi wrote:


    > > >> 1. A -> send SYN --> B
    > > >> 2. A <- SYN + ACK <- B
    > > >> 3. A -> ?ACK ---> ? ?B
    > > >> 4. A <--- SYN+ACK <- B


    > > > Duplicate packets are, and should be, rejected. They don't prove
    > > > that packet 3 was lost, since the duplicate packet could have
    > > > been sent right before packet 3 was received.


    > > in the wireshark tap, i am seeing that packet 4 is repeated again
    > > and again. What if the packet 3 is lost ? the setup is aborted ?


    > The setup already completed. Why would it be aborted?


    > The TCP handshake is three-way. All three things have happened. The
    > setup is complete.


    The three way handshake isn't completely complete until the ACK of the
    SYN|ACK is received by the connection initiator. Given that the SYN
    occupies one byte of sequence space, I would expect that upon reciept
    of a duplicate SYN|ACK with a valid (ie identical to that of the first
    SYN|ACK) sequence number and checksum would trigger another ACK with
    the current expected next sequence number. That would seem to be the
    only way to recover from loss of the ACK of the SYN|ACK.

    rick jones
    --
    No need to believe in either side, or any side. There is no cause.
    There's only yourself. The belief is in your own precision. - Jobert
    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...

  6. Re: Three Way handshake Q:

    On Oct 2, 11:33*am, Rick Jones wrote:

    > The three way handshake isn't completely complete until the ACK of the
    > SYN|ACK is received by the connection initiator.


    I guess it depends upon what you mean by "completely complete". Since
    the side that sends the SYN|ACK has no way to know whether or not the
    other end received it when it does, it must be "completely complete"
    at least as far as that side is concerned.

    >*Given that the SYN
    > occupies one byte of sequence space, I would expect that upon reciept
    > of a duplicate SYN|ACK with a valid (ie identical to that of the first
    > SYN|ACK) sequence number and checksum would trigger another ACK with
    > the current expected next sequence number.


    Nope. Duplicate packets should be discarded. The duplicate packet
    doesn't prove the other packet didn't get through.

    >*That would seem to be the
    > only way to recover from loss of the ACK of the SYN|ACK.


    No, that's what retransmission is for. Only the loss of the original
    packet should trigger a retransmission, and without selective
    acknowledge, only the expiration of the timer proves that.

    When either side of a TCP connection sends something that occupies
    sequence space (including a SYN), it starts a timer. If the sequence
    space is not acknowledged by the expiration of that timer, there is a
    retransmission. But receiving duplicates of earlier acknowledgments
    doesn't prove the later packets didn't get through. They could have
    been before the packet was received and just took a slower network
    path.

    DS

  7. Re: Three Way handshake Q:

    So, rewriting the OPs chart, I believe he was describing:

    A B
    1 SYN -->
    2 <-- SYN|ACK
    3 ACK -->
    4 <-- SYN|ACK

    and he wrote:

    > in the wireshark tap, i am seeing that packet 4 is repeated again
    > and again. What if the packet 3 is lost ? the setup is aborted ?


    Packet four repeated again and again sounded like B was retransmitting
    the SYN|ACK segment. There was no mention of the retransmitted
    SYN|ACK's being ACKed by A. However, A has to emit an ACK for next
    expected sequence number upon reciept of the retransmitted SYN|ACK
    because A has no way of knowing if his ACK (eg packet 3) was lost or
    not. The only valid reason I can see for A not responding to #4 (or
    subsequent retransmissions of B's SYN|ACKs) would be if they were
    corrupt (bad checksum) or if perhaps the ostensibly retransmitted ISN
    were wrong.

    rick jones
    --
    Wisdom Teeth are impacted, people are affected by the effects of events.
    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...

  8. Re: Three Way handshake Q:

    Rick Jones wrote:
    > So, rewriting the OPs chart, I believe he was describing:
    >
    > A B
    > 1 SYN -->
    > 2 <-- SYN|ACK
    > 3 ACK -->
    > 4 <-- SYN|ACK
    >
    > and he wrote:
    >
    >> in the wireshark tap, i am seeing that packet 4 is repeated again
    >> and again. What if the packet 3 is lost ? the setup is aborted ?

    >
    > Packet four repeated again and again sounded like B was retransmitting
    > the SYN|ACK segment. There was no mention of the retransmitted
    > SYN|ACK's being ACKed by A. However, A has to emit an ACK for next
    > expected sequence number upon reciept of the retransmitted SYN|ACK
    > because A has no way of knowing if his ACK (eg packet 3) was lost or
    > not. The only valid reason I can see for A not responding to #4 (or
    > subsequent retransmissions of B's SYN|ACKs) would be if they were
    > corrupt (bad checksum) or if perhaps the ostensibly retransmitted ISN
    > were wrong.
    >


    Curious. This describes the problem I posted about recently:

    Jim Garrison wrote:
    > Here's a summary of a capture of a failed connection.
    > I captured both ends and both traces look identical except
    > for the source/destination address swap. This is for an
    > SSL connection on port 443.
    >
    > Client Server
    >
    > 1 ------SYN------>
    > 2 <---SYN,ACK-----
    > 3 ------ACK------> (so far so good)
    > 4 <---SYN,ACK----- (huh?)
    > 5 ------ACK------> dup of frame 3 according to wireshark
    > 6 <---SYN,ACK-----
    > 7 ------ACK------> dup of frame 3
    > .
    > .
    > .
    > ad nauseum, at ever increasing delays between packets


    What OS is the OP of the "Three Way handshake Q:" thread running?

  9. Re: Three Way handshake Q:

    On Oct 3, 2:37*pm, Rick Jones wrote:

    > Packet four repeated again and again sounded like B was retransmitting
    > the SYN|ACK segment. *There was no mention of the retransmitted
    > SYN|ACK's being ACKed by A. *However, A has to emit an ACK for next
    > expected sequence number upon reciept of the retransmitted SYN|ACK
    > because A has no way of knowing if his ACK (eg packet 3) was lost or
    > not.


    There is no reason A should ACK a duplicate packet.

    A certainly does have a way if knowing if his SYN/ACK was lost or not.
    He assumes it's lost if his ack timer runs out. In the absence of
    selective ACK, nothing the other side can send him proves his packet
    is lost. Only the expiration of a timer does that.

    >*The only valid reason I can see for A not responding to #4 (or
    > subsequent retransmissions of B's SYN|ACKs) would be if they were
    > corrupt (bad checksum) or if perhaps the ostensibly retransmitted ISN
    > were wrong.


    They're duplicates. They contain no new information. It would be an
    error to respond to them.

    DS

  10. Re: Three Way handshake Q:

    Jim,
    I am seeing a slight variation of what you are seeing - the 'ACK' are
    not retransmitted... (packets 5,7 are missing).

    >> Client Server
    >>
    >> 1 ------SYN------>
    >> 2 <---SYN,ACK-----
    >> 3 ------ACK------> (so far so good)
    >> 4 <---SYN,ACK----- (huh?)
    >> 5 ------ACK------> dup of frame 3 according to wireshark
    >> 6 <---SYN,ACK-----
    >> 7 ------ACK------> dup of frame 3
    >> .
    >> .
    >> .
    >> ad nauseum, at ever increasing delays between packets

    >
    > What OS is the OP of the "Three Way handshake Q:" thread running?


    linux - will check the kernel version and post it later...

  11. Re: Three Way handshake Q:

    David Schwartz wrote:
    >
    > They're duplicates. They contain no new information. It would be an
    > error to respond to them.


    are you suggesting the following sequence:

    A B
    ---- SYN --->
    <--SYN+ACK---
    ---- ACK ---->
    ....
    <--SYN+ACK---
    <--SYN+ACK---
    ....

    --- ACK ---->


  12. Re: Three Way handshake Q:

    On Oct 3, 2:37*pm, Rick Jones wrote:

    > The only valid reason I can see for A not responding to #4 (or
    > subsequent retransmissions of B's SYN|ACKs) would be if they were
    > corrupt (bad checksum) or if perhaps the ostensibly retransmitted ISN
    > were wrong.


    'A' wouldn't respond to #4 because it's a duplicate packet. It conveys
    no new information.

    'A' didn't know if its previous packet got through and it still
    doesn't. For all it knows, that packet could have been delayed on the
    network and the other side has already received its previous packet.

    The only way to conclude that a packet is lost, without selective ACK,
    is for our ACK timer to expire.

    DS

  13. Re: Three Way handshake Q:

    In article
    <92f116d6-24da-4a63-8fdb-ab1ea8eecc62@m3g2000hsc.googlegroups.com>,
    David Schwartz wrote:

    > On Oct 3, 2:37*pm, Rick Jones wrote:
    >
    > > Packet four repeated again and again sounded like B was retransmitting
    > > the SYN|ACK segment. *There was no mention of the retransmitted
    > > SYN|ACK's being ACKed by A. *However, A has to emit an ACK for next
    > > expected sequence number upon reciept of the retransmitted SYN|ACK
    > > because A has no way of knowing if his ACK (eg packet 3) was lost or
    > > not.

    >
    > There is no reason A should ACK a duplicate packet.
    >
    > A certainly does have a way if knowing if his SYN/ACK was lost or not.
    > He assumes it's lost if his ack timer runs out. In the absence of
    > selective ACK, nothing the other side can send him proves his packet
    > is lost. Only the expiration of a timer does that.


    When he retransmits it, he needs to find out if the retransmission was
    received. Which means the receiver has to ACK it. If you never
    acknowledge duplicates, a lost ACK can cause a connection failure.

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

  14. Re: Three Way handshake Q:

    On Oct 4, 2:47*pm, Ravi wrote:

    > are you suggesting the following sequence:
    >
    > A * * * * * * B
    > * ---- SYN --->
    > * <--SYN+ACK---
    > * ---- ACK ---->
    > ...
    > * <--SYN+ACK---
    > * <--SYN+ACK---
    > ...
    >
    > * --- ACK ---->


    Exactly. But here's the strange thing: B's timeout should be about the
    same as A's timeout. So I can't understand why B would be sending so
    many retransmissions before A sent a single one.

    Perhaps someone messed with the TCP timers (most likely on B) without
    understanding the consequences? That might cause B to think packets
    are lost that actually are not lost, resulting in spurious
    retransmissions.

    In any event, the retransmissions are spurious, though harmless. A has
    to determine that its packet dropped and B can't help it.

    What's the time frame for these packets? How quickly is B
    retransmitting? How long does A sit there without sending a packet?

    DS

  15. Re: Three Way handshake Q:

    On Oct 5, 4:40*am, Barry Margolin wrote:

    > When he retransmits it, he needs to find out if the retransmission was
    > received. *Which means the receiver has to ACK it. *If you never
    > acknowledge duplicates, a lost ACK can cause a connection failure.


    Wow, you are correct.

    DS

+ Reply to Thread