1

I was trying to understand how TCP works (not in detail of course). I was surfing the web for easy-to-understand flow diagrams and a question arose and couldn't find a straight answer.

Let's suppose that we have this nice flow where everything is sync (ignore the ending part with FIN and crossing packets): enter image description here

Looking at this schematic one can understand that B can only send data as a response to something to A but from what I understand TCP is a bidirectional protocol so each entity can send it whenever it wants.

  1. I would like to know what would happen if both A and B send packets at the same time. Basically having crossing data packets, how the sequence numbers and acks would behave. Initially, I thought that the same thing is happening in the mirror for the B -> A connection (having sets of seq numbers for each direction), but that's not making sense really. In the example "hello" is sent in response to "foobar" and that would mess with the seq numbers for B -> A connection.

  2. Also another question in the same direction, I read that TCP is an SWP (Sliding window protocol), I would like to know how ACKs are formed in this case. TCP is responding with the number of bytes basically as a Seq number, I can't really imagine how that can happen inside a window (where you can receive in any order). Is the implementation using two sets of seq numbers and two windows for both receiver and sender?

  3. What would happen in the following scenario:

enter image description here

Any spec references or other helpful resources are more than welcome.

1
  • There are actually four windows. Each side communicates a receive window to the other side in each segment sent, and each side maintains a congestion window for itself, not communicating that to the other side. The receive window is based on the available buffer space of the receiver, and the congestion window slides based on the loss of segments in the path.
    – Ron Maupin
    Apr 1 at 21:25
2

Rather simple: each direction has its own and independent sequence number and sliding window. So, whether the ends are sending data unidirectionally (one end just ACKing with otherwise empty segments) or bidirectionally doesn't matter.

5
  • Thank you for the answer. I understand that there is also a Seq number for A and B, but couldn't understand if problems can appear in that. Can you provide a simple answer for the newly added question (3.) and explain how this issue can be solved. Apr 1 at 9:30
  • You're still mixing up both directions. A receives Seq 1 "Hello" and ACKs 6 (1+5). A sends Seq 1007 "ping", B ACKs 1011 (1007+4). There's no conflict.
    – Zac67
    Apr 1 at 9:39
  • So you are saying there are actually two channels 1 for A -> B and 1 for B -> A. For each channel, A keeps two seq numbers one for sending and one for receiving which initially are the same. And based on communication one can stay at the initial value and the other can grow for example. So basically the first image where B responds with "hello" to A's "foobar" is actually not correct. Apr 1 at 10:29
  • 1
    @UrsescuIonut No, for each channel the sender keeps two sequence numbers (latest sent and latest acknowledgement received) and the receiver keeps a sequence number (latest received).
    – user253751
    Apr 1 at 10:38
  • Ok, I think I understand now (also got a quick look in RFC 793). Still, there is a problem that I don't get. When you receive a segment you will do some tests on the SEG.SEQ and SEG.SEQ+LEN-1 to be inside the window (recv window RCV.NXT, RCV.NXT+RCV.WND). In the context of q3. if the RCV.WND is 2 (< 4, suppose RCV.NXT on A is 1) will the ACK packet from B be dropped? Or maybe ACK packets are treated differently (couldn't find a straight answer to this). Apr 2 at 12:46
0

TCP only acts on the packets it receives, it doesn't know which packets are on the line.

If both sides sends data at the same time, from TCP's perspective, it will send data, then receive data, and after that it receives a packet containing an ACK

Example from the perspective of side A:

A -> B: SEQ=1000 SYN=1000        (SYN is a random value in practice)
A <- B: SEQ=0    ACK=1001 SYN=0  (SYN is a random value in practice)
A -> B: SEQ=1001 ACK=1           (When the packet contains only an ACK, 
                                  don't increase the sequence number for
                                  the next packet)
(A knows it sending sequence number is 1001, and the receiving sequence number is 1)
// Example: Only A sends something
A -> B: SEQ=1001 ACK=1 "hello "
A <- B: SEQ=1    ACK=1007 (We acknowledge that 6 bytes have been received)

// Example: Only A sends multiple things quickly
A -> B: SEQ=1007 ACK=1 "World"
A -> B: SEQ=1013 ACK=1 "!"
A <- B: SEQ=1    ACK=1013
A <- B: SEQ=1    ACK=1014

// Example: Both sides send data at the same time
A -> B: SEQ=1014 ACK=1 "Ping!"
A <- B: SEQ=1    ACK=1014 "Hello"
A -> B: SEQ=1019 ACK=6
A <- B: SEQ=6    ACK=1019

// Example: Both sides send data, but B's data packet takes a
// slow route though the internet
A -> B: SEQ=1019 ACK=6 "1"
# B sends the data, the packet is delayed
# B receives the data from A and sends an (SEQ=7, ACK=1020)
A <- B: SEQ=10   ACK=1020
# A sees that it missed some data, but doesn't respond back. It is
# B's responsibility to detect missing ack's and resend data if needed.
A <- B: SEQ=6    ACK=1019 "Data"
# Out of order packet detected (SEQ/ACK values decremented)
# We already know the other side has acknowledges up to 1020, so we remember that value
A -> B: SEQ=1020 ACK=10

// Complex example: Multiple packet are lost/reordered
// (packets from a real world traffic capture I did in my own network)
// The remote side is supposed to say "Hello World!"
A -> B: SEQ=1020 ACK=10 "/MOTD"
A <- B: SEQ=10   ACK=1025
A <- B: SEQ=16   ACK=1025 "World!"
# Note how the sequence ID is suddenly bigger
A -> B: SEQ=1025 ACK=10
# We have received everything correctly up to 10, so only send 10 back
A <- B: SEQ=10   ACK=1025 "Hello "
A -> B: SEQ=1025 ACK=22
# Note how the ack number shoots up by 12, even though we only received 6 bytes of data
A <- B: SEQ=16   ACK=1025 "World!"
A -> B: SEQ=1025 ACK=22
# We receive the same data again, we already know about this, and we already processed it. It must alrady be send before the other side received our ACK

Also another question in the same direction, I read that TCP is an SWP (Sliding window protocol), I would like to know how ACKs are formed in this case. TCP is responding with the number of bytes basically as a Seq number, I can't really imagine how that can happen inside a window (where you can receive in any order). Is the implementation using two sets of seq numbers and two windows for both receiver and sender?

TCP was originally designed for slower networks. The sequence number is a 32-bit number, and rolls over every 4GB of data transferred. This was fine when we were in the dial-up time, as we only had internet speeds in the KB range, but this system fails with modern internet speeds, where it could roll over in seconds. These days we add "timestamps" to packets, which increment slower, and it is used in combination with the other fields to handle out of order, duplicate packets and rolled over sequence numbers

3
  • I like your answer, but can you also respond to the last question (3.) please? I think that is the actual question in my mind but couldn't explain it from the start. Apr 1 at 9:27
  • I added an example for the out or order data packet (and another example what happens if 1 of the packets gets dropped)
    – Ferrybig
    Apr 1 at 9:58
  • 1
    In q3, A sends 4 bytes of data, which is acked in the 2nd packet . When B sends Hello, it is sending 5 bytes of data, but cannot ack the data send by A because it was sent before B set its data packet. A receives a packet acking its data sent (Ping), but the seq number indicates B sent data that it has not received. What happens next depends on how long the packet is delayed from B. If it is quick enough, then the receiver accepts the packet and acks it. If it is past the RTO, then A will send a ack 1, telling B it has not received the data. B would then retransmit the Hello
    – Kevin
    Apr 1 at 12:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.