Skip to main content
gamedev.net
🔒 Locked

Data, Segments, Packets and Frames

Started by Bagheera 9 replies 4k views
Original Post
Bagheera
Bagheera
Some guys at work and I have been going at this for quite some time, and I'd like to get some outside opinions. The question goes something like this - Regarding the OSI model, or the TCP model it doesn't matter, we're wondering about how the data flows down the different layers. As we see it - it's one of two options: Option a) Data -> Segment -> Divides into packets -> each packet into a Frame This means that if the Data pushed down from the programming API is 500 bytes, it's all a 1 to 1 to 1 to 1 deal. Meaning data goes into one segment, which in turn goes into one packet, and into one frame. However, if the data is bigger than the MTU (of let's say Ethernet - 1518 bytes) then the Data goes straight into a Segment - which divides into packets, and each packet goes straight into a frame. So for example - We got a 1 MB data batch. This goes into one Segment (notice that a TCP segment or UDP segment don't have a maximum data size at the header level, unlike a packet and a frame). This segment divides into packets, where each packet size is determined by the 2nd layer MTU. Each packet goes into a frame. That's option a'. The advantage is that we save segment headers, because we have only one segment header for the entire MB. Option b) Data -> Segment -> Packet -> Frame The data divides at the segment level. Meaning that the same MB divides into several segments, where each segment size is determined by the 2nd layer MTU. Each segment goes into a packet and into a frame. Advantage: Simpler Disadvantage: We waste segment headers. Now the MB has not one fourth layer header, but rather 1,000,000 Bytes / 1518 Bytes = 658~ Headers. For TCP that's an extra 20 bytes * 658 headers = 13K bytes. Quite an impressive number... Bottom line: The Cisco CCNA documentation proved to be of no service, and every book I've read contradicts the other. What do you guys think? Quotes from reliable texts would certainly help...
Antheus
Antheus
Quote:
Advantage: Simpler
Disadvantage: We waste segment headers. Now the MB has not one fourth layer header, but rather 1,000,000 Bytes / 1518 Bytes = 658~ Headers. For TCP that's an extra 20 bytes * 658 headers = 13K bytes. Quite an impressive number...


That's 1.315%. Or, not really that much. What you really need to consider is the overhead imposed by re-transmission - how often, how many acks, .... TCP does a fair job at that.

But other than that, your post is missing a question - the only question is "What do you guys think?".

What are you trying to find out?

Whether existing technology is inefficient? Whether there are conceptual problems? Are you proposing a new aproach?

I don't know, It just seems like something is missing.
Bagheera
Bagheera
I need to know what's right - How it is really done.

I am an instructor at the Army and I need to know what the hell to teach ;-)
hplus0603
hplus0603
If you are an instructor, I would suggest picking up a good reference! For example, "TCP/IP Illustrated" is a pretty good book.

In general, though, you can get fragmentation on many different levels. The application wants to send 100 kB over UDP, but UDP only supports 64 kB, so the application has to fragment. Then IP has to fragment into the IP MTU, which might be Ethernet frame size. Then the bridge from the Ethernet to the greater internet might be ATM, which uses 48-byte cell sizes. On the other end, re-assembly happens in more than one layer to match.

The truth is that fragmentation and re-assembly depends on the underlying hardware, and there is no one "Truth(tm)".
enum Bool { True, False, FileNotFound };
Bagheera
Bagheera
Everywhere I've read suggests that if any fragmentation will occur on the source computer, it will happen at the fourth layer, never below. Meaning that you'll never fragment IP packets at the source host, but rather originally create TCP or UDP segments at the correct size.
hplus0603
hplus0603
The IP source host, and any router on the path, can fragment the IP packet.
MTU discovery is recommended for performance reasons, but is neither required, nor always possible.
And when it comes to UDP, that is mapped to a single IP datagram, so it HAS to use IP fragmentation for packets larger than the first-hop MTU (for example, Ethernet).
enum Bool { True, False, FileNotFound };
Bagheera
Bagheera
The question is weather the souce computer does what I call "packetation", meaning it originally creates the packets with the correct < MTU size, or it actually fragments the packets, IE all the fragment field in the packets will be filled. Offset, identification, etc.

More questions regarding MTU Math Discovery:

Why would my computer perform or not perform it?
Is it OS dependant?
Application dependant?
How long does it take? Meaning - I set a packet with DF, and the first router which has to fragment will send an ICMP message back containing "Packet fragmentation is required but the 'don't fragment' (DF) flag is on". I then have to transmit another packet with DF with less data, and another router might tackle me again? How does it work technically?
Do only source computers do it? Can routers do it too?

The tcp/ip guide and wikipedia were less than informative regarding the depths of MTU path discovery...
hplus0603
hplus0603
A well performing TCP stack will do path MTU discovery and size packets appropriately. Because TCP has a sliding window mechanism, TCP doesn't have to create IP fragments. However, UDP packets will need fragmenting if over the MTU, and whether fragmentation happens in the host or in a router is implementation dependent (and, I'm sure, varies by OS).
enum Bool { True, False, FileNotFound };
Bagheera
Bagheera
What does TCP sliding window and our subject have to do with one another?

TCP sliding window and segment size have nothing to do with one another. The sliding window only says: How many bytes can I transmit without waiting for an ACK.
hplus0603
hplus0603
Actually, the sliding window is a necessary part of TCP MTU adaptability. The sliding window implies that the sender can send an arbitrary amount of data up to the window size.
Because the sender is free to choose packet size, well implemented TCP stacks will do path MTU discovery and limit the size of each packet to the MTU.
Typically, this is done by all modern "reasonable size" TCP implementations. Some embedded implementations may not bother, though, or assume a fixed MTU of the first hop.
By contrast, for UDP, you don't have the option of a sliding window. Thus, the sender has to fragment at least to the MTU of the first hop. That's how the sliding window matters.
enum Bool { True, False, FileNotFound };
Scuppy
Scuppy
Check out
http://www.faqs.org/rfcs/rfc2923.html
and the related rfc's listed at the bottom.

There is a Microsoft bulletin that describes the packet sizes it tries and how to change it (a registry setting from memory). From memory, it would take half a dozen attempts to get to a small MTU. You can turn this off and I think it applies to all winsock applications.

I dont think routers are allowed to do pmtu discovery but I could be wrong.

EDIT:
I'm wrong, routers can support it, its just they have to be carefull of a 'pmtu attack'.
I cant find the MS bulletin sorry.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.