Why is Packet Size Limited?

[ArsalRiaz123]

I was reading: this answer to "Maximum packet size for a TCP connection", where it says:

The absolute limitation on TCP packet size is 64K (65535 bytes), but in practicality this is far larger than the size of any packet you will see, because the lower layers (e.g. ethernet) have lower packet sizes.

A few questions remain unclear for me:

1. Why don't we just send one single packet? Why do we need to split content into multiple packets (ignoring the size limit)?

2. If a lower layer (like the internet layer) has a lower packet size what does this have to do with TCP packet size limitations? A higher layer (than the internet layer) can add as much data as it wants to.

[Flavio Miranda]

Most of those technologies were invented 20, 30 and sometimes 40 years ago when hardware were totally diffent.  To undestand this, it is necessary travel back all this year and get in touch with the limitation they had at that time.

The problem is that those protocols have been deployed for so long time and in so many devices that change anything now would cause too much pain.

 Software defined network try to improve some limitation but when it comes to underlay network, ethernet and TCP/IP still rule the world.

[Joseph W. Doherty]

"Why don't we just send one single packet? Why do we need to split content into multiple packets (ignoring the size limit)?"

Well, consider if you send a whole GB file as a single "packet", what happens if there's a bit error corrupting the packet?  How many times do you want to re-attempt retransmission, because of single bit error corrupting the whole?

"If a lower layer (like the internet layer) has a lower packet size what does this have to do with TCP packet size limitations?"

Everything and nothing.  TCP guarantees delivery, L2 frames and L3 IP packets do not.  Since it's TCP that guarantees delivery and sequencing, having L2 frames, L3 packets, and L4 segments, they agreeing to work together, about transmission sizes, insures less issues when there is some network delivery issue.  Consider, again, sending a GB segment, but it needs to be split into smaller L2 frames and/or L3 packets, and a frame and/or packet arrives "late", "corrupted" or is "lost".  At the TCP level, you would need to hold  all the data, as it arrives in frames/packets, until you can provide the whole segment to the next layer up.  Further, if you need to retransmit, a corrupted TCP segment, you need to transmit the whole GB again.  (BTW, having worked with ATM, losing a "cell" causes a whole packet to be retransmitted.  Assuming you're using "Standard" Ethernet frames, and that ATM "data" is limited to 48 bytes per cell, losing even just one cell out of single max sized [Ethernet] packet, "needlessly" consumes much of your bandwidth, to replace the whole packet; also assuming you don't lose another/different packet cell on the next attempt.)

"A higher layer (than the internet layer) can add as much data as it wants to."

Sure it can, and that happens now.  What bounds are there on sending (total) volume at L2, L3 or L4?  None, correct?  There are, though, limitations on how big containers might be.

Consider the analogy of moving from one house to another.  Are you limited in how much household goods you can send, in total?  Usually the answer is no.  But are you limited in the size of the containers (i.e. boxed, crates, trucks) you might use?  Usually the answer is yes.

[sp2720401]

On top of what Joseph W. Doherty has mentioned you limit packet size to also allow multiplexing of multiple sessions on a single link. If you start to serialize a 1GB packet over a 1gbps link it would take at least 8 seconds to put bits on the wire. All of the other packets and sessions waiting to traverse that link will either be discarded or you would need massive buffers (memory) just to store the packets waiting. Voice (ie G.711 G.729) is little packets 50x 20ms samples worth of data to make one second of audio...

I don't think you would like to get 20ms of voice every 8 seconds when your voice is sharing the link with 1GB packets.

[Joseph W. Doherty]

Excellent point!  The problem also worstens as bandwidth of link is less.

There is, though, an approach to allow you to send a "GB packet", without blocking (all) others concurrent data streams, which is, you channelize the bandwidth.  (Basically how analog voice worked, i.e. each stream gets its own bandwidth channel.)  Problem with that approach, you cannot (often easily) leverage unused bandwidth, and often are constrained by the number of concurrent channels.  (In the old voice approach, your call would be totally blocked if there were no available channels - "call admission" in modern terms.)