I have a question about the below excerpt from Cerf, V.; Kahn, R. (1974). "A Protocol for Packet Network Intercommunication". IEEE Transactions on Communications. 22 (5): 637–648.

... Furthermore, we constrain the length of a segment to an integral number of 8-bit bytes. This uniformity is most helpful in simplifying the software needed with HOST machines of different natural word lengths. Provision at the process level can be made for padding a message that is not an integral number of bytes and for identifying which of the arriving bytes of text contain information of interest to the receiving process.

Que: In the first part of the excerpt, the constraint is put on the length of a segment but in the next part the provision is suggested at the process level for padding a message. Aren't these two conflicting arguments? One is suggesting constraint at the TCP and later at the Process.

  • An integral number of bytes means that it must be full bytes. You cannot send byte fractions. The IETF generally refers to octets (eight bits), rather than bytes, in the RFCs, so that means you must send data in multiples of eight bits. The data-link, network, and transport layers all use only full octets. Applications and application-layer protocols , which are off-topic here, may use whatever they want, but the network stack only deals with full octets, so any application must pad partial octets in order to use the network stack.
    – Ron Maupin
    May 21 at 14:40

1 Answer 1


The idea is that the length of a TCP payload can only be given in full bytes. If the message length can not be given in full bytes (like with a message of 6 bit length) then padding of the message to the full bytes must be done in the application (i.e. padding 6 bit with 2 bits to get 8 bit = 1 byte).

  • but in the same paper, a message at the process level is considered as a continuous data stream from which the TCP will create segments. Does that mean, the last segment of a message would be on hold at TCP till the time process sends the padding?
    – mejariamol
    May 21 at 12:13
  • @mejariamol: There is no "on hold". The process will send full bytes only. Anything with more granularity than full bytes is handled internally by the process and is transparent to the TCP stack. May 21 at 12:48

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.