[e2e] Small packets - Definition needed..
detlef.bosau at web.de
Tue Mar 27 07:05:56 PDT 2007
Dah Ming Chiu wrote:
> A natural reason for discussing "small" vs "large" packets is concerned
> with the packet header overhead, as several people suggested. For
Yes. There is a tradeoff between packet lenght and header size. That´s
However, to me this whole discussion seems to be an engineering
discussion, related to certain technologies. I never gave much thought
absolute packet sizes, IIRC 536 was motivated by some SLIP pecularities,
1500 is somewhat Ethernet related.
So, tomorrow someone will invent a new technology - and packets may be
Of course, traffic shall be not too bursty, so one should consider a
packet´s temporal length on a certain netwok. In Ethernet, a packet may
last 1.2 ms. So, that´s obviously acceptable. So, why shouldn´t wie use
packets which last 1.2 ms on a Terbit network? Then a maximum packet
size would be 150 MByte. Then we have a look at applications. How large
is an e-mail? (O.k., let´s leave out those written by me ;-))
10 kByte? 1 kByte? Or when the newest DVD immage is attached: 2 Gbyte?
And how large should IP packets be then?
Personally, 1500 bytes is somewhat a "magic number" to me, perhpas not
only for me, for historical reasons and Ethernet influence.
However, "small", "large" are relative attributes. I can say a packet
is "small" compared to an average packet length. But I don´t see a sense
in defining "small" to, say, less then 500 bytes. Perhaps, tomorrow 90 %
of packets are larger than 100.000 bytes and then 90.000 bytes would be
So, in my opinion we can give some orientation what is "small" or
"large" in some "best current practice" RFC which reflects the actual
situation, i.e. "spring 2007". But I don´t see a sense in a generic
More information about the end2end-interest