0

I was reading a textbook which says about TCP protocol "Selective Repeat":

We have assumed that packets cannot be reordered within the channel between the sender and receiver. This is generally a reasonable assumption when the sender and receiver are connected by a single physical wire. However, when the “channel” connecting the two is a network, packet reordering can occur. The approach taken in practice is to ensure that a sequence number is not reused until the sender is “sure” that any previously sent packets with sequence number x are no longer in the network. This is done by assuming that a packet cannot “live” in the network for longer than some fixed maximum amount of time.

I am confused and below are my two questions.

Q1-What does " the channel can be thought of as essentially buffering packets and spontaneously emitting these packets at any point in the future." mean? Why do we need to buffer an old packet? Isn't it better that the receiver just ignore it?

Q2-Let's say the window size is 2 and the available sequence number is 0,1,2,3. The sender firstly sends packet 0, packet 1, while packet 0 is struck somehow and takes much time to arrive, so timeout occurs the sender has to send packet 0 again, but this time packet 0(new) arrives on time. Then the sender sends packet 2, packet 3, all received by the receiver. And then the sender is about to send packet 0(new), and packet 1(new), but the old packet 0 arrives at receiver now, so receive could not know that this packet is the old packet or the new packet. So how does " assuming that a packet cannot “live” in the network for longer than some fixed maximum amount of time" can fix this issue? Does it mean that the packet header contains the time that it was sent?

Improve this question
  • If the window size is two, then the sender will not send segments (not packets) two and three until both segments zero and one have been acknowledged. A sender cannot send segments outside the current window. – Ron Maupin♦ Aug 15 '20 at 23:48
  • @RonMaupin yes packet 0(re-sended one due to timeout) and packet 1 are acked by sender, but the old packet 0 is struck somewhere in the network,that's the purpose of packet reordering,isn't it – amjad Aug 16 '20 at 0:37
  • "yes packet 0(re-sended one due to timeout) and packet 1 are acked by sender" Thaqt is incorrect. The sender does not send an ACK, it is the receiver that sends the ACK, but it will not send an ACK unless it has actually received a segment. Any segment lost or delayed on the network will not be acknowledge back to the sender, and the sender cannot send any data in the next windows until it receives acknowledgment for all the data in the first window. – Ron Maupin♦ Aug 16 '20 at 4:55
  • @RonMaupin I think you mistand my point. Let me put it in a simple way, the sender send 0,1 (0 is struck before reaching to receiver), so the receive only acks 1,then timeout, the sender re-send 0, this time it arrive the receiver's end on time, so 0(the second one) and 1 are both acked by receivers. Now sender starts to send 2 and 3, but origin 0(lost in the first time) somehow unfreezed in the network and arrives receiver, this is the packet reordering in the context I guess – amjad Aug 16 '20 at 6:03
  • 1
    "the sender send 0,1 (0 is lost), so the receive only acks 1" No, the receiver will not acknowledge segment 1. The acknowledgment number would be 2, the next expected segment, but it acknowledges every segment prior to 2, and it will not do that because it has not received segment 0. – Ron Maupin♦ Aug 16 '20 at 6:07
2

What does " the channel can be thought of as essentially buffering packets and spontaneously emitting these packets at any point in the future." mean? why we need to buffer a old packet? isn't better that the receiver just ignore it?

That's the nature of queueing and buffering which is an essential part of packet switching - received packets are queued/buffered on ingress and deleted from the queue once they've been forwarded. Buffering is necessary as otherwise the egress link would always need to be free whenever a packet is received - that's not possible for packet-switched networks, only for circuit-switched ones.

Let say the window size is 2 and availabe sequence number is 0,1,2,3.

The window doesn't count packets/datagrams but bytes. Also, the sequence number only repeats when its 32-bit field overflows - that happens only after 4 GiB of data. However, that limit means that there can't ever be more than 4 Gib of data "in flight" to avoid ambiguity. Since the largest possible window is (close to) 1 GiB, that is not a problem.

Note that with simple, cumulative ACKs, the receiver can't selectively ACK later segments when a previous segment is still missing. An ACK means that all previous data has been received.

For example, with a segment size of 1,000 and a window size of 10,000, sender sends datagrams D00-D09 (sequence 0-9,999). D00 and D02-D09 are received, but D01 is lost. The receiver still ACKs 1,000 (the next expected data sequence) which triggers the sender to move D0 out of the window, advance it to 1,000-10,999, and send D10.

Meanwhile the receiver has decided that there's a problem, so it ACKs 1,000 again to signal just that. The sender receives the double ACK and resends D01 (reluctant mode) or all data starting from D01 (aggressive mode). The receiver has already got D10 (10,000-10,999), so it ACKs 11,000 which in turn moves the sender's window to 11,000-20,999 (and aborts the still outstanding retransmissions, for aggressive mode).

(I have somewhat simplified the process, in reality there's more parallel overlap, and a delay between send and receive, of course.)

EDIT: As Jeff has correctly pointed out (thx!), support for selective acknowledgments (SACK) is nearly a given today. Using that option, the receiver could also SACK 2,000-9,999 (from D02-D09) right away, so the sender wouldn't start retransmitting them. It could also start transmitting 11,000-20,999 earlier.

Improve this answer
  • 2
    In reality, virtually all modern systems support RFC2018 TCP Selective Acknowledgements. I think the above explanation may mislead readers, current or future, to have a significant misunderstanding of how TCP usually operates in the practical world. – Jeff Wheeler Aug 16 '20 at 12:24
  • 2
    @JeffWheeler Thanks for pointing that out - seems I have simplified to much. I've edit the question as to not be misleading. – Zac67 Aug 16 '20 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.