[e2e] Small packets - Definition needed..

[Detlef Bosau]

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 
well known.

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 
much larger.

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 
"small".

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 
definition.

Detlef