4

I understand seq/ack is used to provide a reliable connection service. But it seems that during TCP data transmission the ACK bit is ALWAYS set, as demonstrated in the following picture.

Suppose A has just acked a packet from B, and now A wants to send something to B. What is the point of A setting the ACK bit and ACK number, which are already known to B?

A related question: wouldn't it be more clear to always separate ACK control segment from data segment?

Pic from internet: enter image description here

  • Thanks for the kind reminder. I just did. But actually this seems to me more like a design choice - header size is (almost always) fixed so why not use spare bits to ACK something. Even it appears as a duplicate ACK, it does not harm. But why is this designed preferred over two separate packet formats (e.g. one for ACK and one for data) is unclear. – wlnirvana Aug 8 '17 at 6:51
3

acks themselves are not acknowledged - so your notion that the peer already knows the information in the seemingly redundant ack is not necessarily true.. and its free to encode it this way, so doing so helps prevent retrasmissions from lost acks at no cost.

2

The ACK bit means that the Acknowledgement number in this packet is valid. In the SYN packet there is no SEQ# from the other side yet so there is nothing to ACK. There is a zero in the ACKnowledgement field, but it is just a placeholder (some decoders show it some don't, but you can see it in the hex). Every packet after the first packet will have the ACK bit set. Every packet has a SEQ and ACK number, so there is always a valid ACK, even if the ACK was the same as the last ACK.

2

As RFC 793 says:

Acknowledgment Number. 32 bits.

If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent.

As others have said, instead of leaving the ACK field empty, it is always populated. It doesn't "cost" anything and it always makes sure that the other end knows what byte is expected next.

1

The ACK bit is continuously used as part of the process of transferring data.

Since the purpose of TCP is to be a reliable protocol, it has to have some way to acknowledge that all pieces of data were correctly received. The ACK associated with the Acknowledgment number is used to do so.

From RFC793

Reliability:

The TCP must recover from data that is damaged, lost, duplicated, or
delivered out of order by the internet communication system.  This
is achieved by assigning a sequence number to each octet
transmitted, and requiring a positive acknowledgment (ACK) from the
receiving TCP.  If the ACK is not received within a timeout
interval, the data is retransmitted.  At the receiver, the sequence
numbers are used to correctly order segments that may be received
out of order and to eliminate duplicates.  Damage is handled by
adding a checksum to each segment transmitted, checking it at the
receiver, and discarding damaged segments.

As long as the TCPs continue to function properly and the internet
system does not become completely partitioned, no transmission
errors will affect the correct delivery of data.  TCP recovers from
internet communication system errors.

Flow Control:

TCP provides a means for the receiver to govern the amount of data
sent by the sender.  This is achieved by returning a "window" with
every ACK indicating a range of acceptable sequence numbers beyond
the last segment successfully received.  The window indicates an
allowed number of octets that the sender may transmit before
receiving further permission.
  • Thanks for you reply. May be I wasn't clear in the question. I understand that the purpose of seq/ack is to provide a reliable delivery service. However I was wondering why the ACK flag is set even for data segments. – wlnirvana Apr 21 '16 at 15:31
  • @wlnirvana, the ACK is just a flag in the TCP header. There is no reason to not ACK when sending segments containing data. doing otherwise is really wasting bandwidth (sending empty segments just to ACK). You should read the RFC; it discusses this. – Ron Maupin Apr 21 '16 at 15:43
  • 1
    Does this mean that the WIN field is only valid when ACK is set? Otherwise I still don't see why in the picture the fourth line is "PSH, ACK" instead of only "PSH". I mean if ACK is effectively in every packet, why don't we just remove this flag and save one more bit of bandwidth? – wlnirvana Apr 21 '16 at 16:02

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.