# Three Way handshake Q:

• 10-02-2008, 05:57 AM
unix
Three Way handshake Q:
Hi,
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
• 10-02-2008, 06:34 AM
unix
Re: Three Way handshake Q:
On Oct 1, 10:57*pm, Ravi <tora...@yahoo.com> wrote:[color=blue]
> Hi,
> 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.[/color]

No. It will correctly reject the packet as a duplicate.
[color=blue]
> 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 ?[/color]

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
• 10-02-2008, 04:50 PM
unix
Re: Three Way handshake Q:
David Schwartz wrote:[color=blue]
> On Oct 1, 10:57 pm, Ravi <tora...@yahoo.com> wrote:[color=green]
>> Hi,
>> 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.[/color]
>
> No. It will correctly reject the packet as a duplicate.
>[color=green]
>> 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 ?[/color]
>
> 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.[/color]

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
[color=blue]
>
> DS[/color]
• 10-02-2008, 05:03 PM
unix
Re: Three Way handshake Q:
On Oct 2, 9:50*am, Ravi <tora...@yahoo.com> wrote:
[color=blue][color=green][color=darkred]
> >> 1. A -> send SYN --> B
> >> 2. A <- SYN + ACK <- B
> >> 3. A -> *ACK ---> * *B
> >> 4. A <--- SYN+ACK <- B[/color][/color][/color]
[color=blue][color=green]
> > 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.[/color][/color]
[color=blue]
> 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 ?[/color]

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
• 10-02-2008, 06:33 PM
unix
Re: Three Way handshake Q:
David Schwartz <davids@webmaster.com> wrote:[color=blue]
> On Oct 2, 9:50?am, Ravi <tora...@yahoo.com> wrote:[/color]
[color=blue][color=green][color=darkred]
> > >> 1. A -> send SYN --> B
> > >> 2. A <- SYN + ACK <- B
> > >> 3. A -> ?ACK ---> ? ?B
> > >> 4. A <--- SYN+ACK <- B[/color][/color][/color]
[color=blue][color=green][color=darkred]
> > > 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.[/color][/color][/color]
[color=blue][color=green]
> > 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 ?[/color][/color]
[color=blue]
> The setup already completed. Why would it be aborted?[/color]
[color=blue]
> The TCP handshake is three-way. All three things have happened. The
> setup is complete.[/color]

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...
• 10-03-2008, 05:05 AM
unix
Re: Three Way handshake Q:
On Oct 2, 11:33*am, Rick Jones <rick.jon...@hp.com> wrote:
[color=blue]
> The three way handshake isn't completely complete until the ACK of the
> SYN|ACK is received by the connection initiator.[/color]

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.
[color=blue]
>*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.[/color]

Nope. Duplicate packets should be discarded. The duplicate packet
doesn't prove the other packet didn't get through.
[color=blue]
>*That would seem to be the
> only way to recover from loss of the ACK of the SYN|ACK.[/color]

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
• 10-03-2008, 09:37 PM
unix
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:
[color=blue]
> 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 ?[/color]

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...
• 10-04-2008, 05:36 PM
unix
Re: Three Way handshake Q:
Rick Jones wrote:[color=blue]
> 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:
>[color=green]
>> 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 ?[/color]
>
> 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.
>[/color]

Curious. This describes the problem I posted about recently:

Jim Garrison wrote:[color=blue]
> 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[/color]

What OS is the OP of the "Three Way handshake Q:" thread running?
• 10-04-2008, 08:08 PM
unix
Re: Three Way handshake Q:
On Oct 3, 2:37*pm, Rick Jones <rick.jon...@hp.com> wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
>*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.[/color]

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

DS
• 10-04-2008, 09:45 PM
unix
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).
[color=blue][color=green]
>> 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[/color]
>
> What OS is the OP of the "Three Way handshake Q:" thread running?[/color]

linux - will check the kernel version and post it later...
• 10-04-2008, 09:47 PM
unix
Re: Three Way handshake Q:
David Schwartz wrote:[color=blue]
>
> They're duplicates. They contain no new information. It would be an
> error to respond to them.[/color]

are you suggesting the following sequence:

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

• 10-04-2008, 09:53 PM
unix
Re: Three Way handshake Q:
On Oct 3, 2:37*pm, Rick Jones <rick.jon...@hp.com> wrote:
[color=blue]
> 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.[/color]

'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

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

DS
• 10-05-2008, 11:40 AM
unix
Re: Three Way handshake Q:
In article
David Schwartz <davids@webmaster.com> wrote:
[color=blue]
> On Oct 3, 2:37*pm, Rick Jones <rick.jon...@hp.com> wrote:
>[color=green]
> > 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.[/color]
>
> 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.[/color]

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, [email]barmar@alum.mit.edu[/email]
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
• 10-05-2008, 08:37 PM
unix
Re: Three Way handshake Q:
On Oct 4, 2:47*pm, Ravi <tora...@yahoo.com> wrote:
[color=blue]
> are you suggesting the following sequence:
>
> A * * * * * * B
> * ---- SYN --->
> * <--SYN+ACK---
> * ---- ACK ---->
> ...
> * <--SYN+ACK---
> * <--SYN+ACK---
> ...
> <timeout on A>
> * --- ACK ---->[/color]

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
• 10-06-2008, 02:49 AM
unix
Re: Three Way handshake Q:
On Oct 5, 4:40*am, Barry Margolin <bar...@alum.mit.edu> wrote:
[color=blue]
> 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.[/color]

Wow, you are correct.

DS