3

In learning materials is often a picture of one TCP segment which is inside one IP datagram which is in one link-layer frame.

Is this always the case?

Is there guarantee that TCP segment is atomic and is contained within one IP datagram?

Does the same apply for datagram and frame?

What I mean is this:

1.

TCP |Segment 1| Segment 2 | Segment 3 |
IP  |Datagram 1   |  Datagram 2 | Datagram 3 |

So basically IP treating the input from the transport layer as simply bytes (like transport layer treats application layer data)

2. Or the possible case, when IP and TCP boundaries match but more TCP segments are within one IP datagram whichtarget the same host but the contained TCP segments are part of different TCP connections.

TCP |Segment 1 | Segment 2 | Segment 3| Segment 4| Segment 5 | Segment 6|
IP  |Datagram 1            |Datagram 2|Datagram 3                       |

2 Answers 2

1

The short answer is no.

The layers of the IP stack are supposed to be agnostic of the other layers. The IP layer could be running over Ethernet, or 802.11 or any of the other data link layer protocols. Those layers are free to fragment the data in any way they need to in order to make the protocol work. In theory they could look at the higher level protocol's header and adjust their fragmentation to match, but there are no requirements to do so.

2
  • 1
    TCP does have a "maximum segment size" that the OS tries to set to fit exactly within one IP packet, though, doesn't it? Dec 7, 2014 at 1:44
  • 1
    @grawity, yes it does, but that is a optimization made by the network stack implementer. The TCP protocol does not require it.
    – heavyd
    Dec 7, 2014 at 1:51
1

I'm assuming you're asking whether a data stream that looks like this can occur:

 TCP:       |     SEGMENT 1          |   SEGMENT 2    |   ...
 IP:        |  FRAGMENT 1   |   FRAGMENT 2   |   FRAGMENT 3    | ...

... that is, IP fragment 1 contains the first portion of TCP segment 1; IP fragment 2 contains the last portion of TCP segment 1 and the first portion of TCP segment 2; etc.

Can you receive it? Yes. What prevents it? If you're building a receiving implementation, you must be prepared for anything the world might throw at you.

Is it valid? Yes, as well. IP packets may be fragmented in transit, whereas TCP segmentation should occur only at the endpoints. I think it is very unlikely that a single transmitting OS would ever transmit data that is both segmented and fragmented, but if a TCP implementation segments data at all and transmits over an IP network, then the IP data may be fragmented in transit, and the above behavior observed.

More information in RFC 791, https://www.ietf.org/rfc/rfc791.txt, see section on Fragmentation.

Regarding packet and frame, similar considerations exist, though I don't have material to cite. An IP implementation should not care how it receives IP packets so long as it can re-establish packet boundaries, which it can and should do without boundary information from the link layer.

In many cases, there are benefits to ensuring that data payloads fit within a single transmission block. If you know the MTU (maximum transmissible unit) between you and your destination, then you can maximize the ratio of data throughput to protocol overhead by fitting your data to the MTU. But that's the best case scenario, not the general case.

4
  • 1
    IIRC, "IP packets may be fragmented in transit" is only valid for IPv4. The rest still applies to IPv6. Dec 7, 2014 at 1:54
  • By fragment you mean ip datagram? If yes, how dowa IP layer know the ordering of the received datagrams so it can build TCP segment from it? As for data-link layer: Can there be case when frames come out of order as in case of IP packets?
    – ps-aux
    Dec 7, 2014 at 18:07
  • Yeah, datagram, sorry. IP datagrams can be broken into fragments, so I mixed up the terms, whoops. RFC 791 also describes the fragment reassembly procedure, basically it's done on the basis of the 'fragment offset' field in the IP header (which provides some primitive sequencing within a fragmented datagram.)
    – lyngvi
    Feb 1, 2015 at 18:11
  • Re: data-link layer: I believe those could arrive out of order as well. While you might have a point-to-point link, a frame from that link might get NAK'ed due to e.g. checksum failure, while the subsequent frame is ACK'ed. You now have data from the second frame but not the first. What actually happens in this situation depends on the protocols involved and is likely up to the receiving implementation in most cases... I don't know what normally happens in that case.
    – lyngvi
    Feb 1, 2015 at 18:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .