[e2e] Small packets - Definition needed..

[Dah Ming Chiu]

A natural reason for discussing "small" vs "large" packets is concerned
with the packet header overhead, as several people suggested.  For
example, when the header size is smaller than certain percentage of
the total packet size, you can ignore the overhead in your engineering
considerations.

Arjuna's problems, as stated in his latest email, are different.

In the case of "Draft 1", you can avoid the problem by simply
rephrasing the sentence to:
"TFRC-SP is intended for flows that send packets no larger than
1500 bytes with inter-packet intervals no smaller than 10 ms".
The "small" here is something quite arbitrary due to the specific
design of TFRC-SP that when satisfied makes TFRC-SP work
better than TFRC.

In the case of  "Draft 2", you can avoid the problem by simply
replacing the word "small packets" by "packets no smaller than
1095 bytes".  In other words, you don't need to define "small".

If you are trying to justify "1095 bytes", it will not be easy, and
you will not get people to agree. You could have picked 1500
or 800, I doubt there is a big difference. It is just an engineering
constant.  Why do we need such an engineering constant?
It is like the problem of how loud are we allowed to talk in a
public place with other people around. In most civilized places,
it is rude to talk too loud.  Since network protocols codify the
level of "rudeness" into programs, you get to pick these numbers.
Of course you will not get concensus on what level of rudeness
is appropriate.  Whether this (IETF policying it) works or not, and
how you may want to accommodate different people under
different circumstances, is a different debate, which has been
played out on this list many times in the past.

Dah Ming Chiu
CUHK

----- Original Message ----- 
From: "Arjuna Sathiaseelan" <arjuna at erg.abdn.ac.uk>
To: <end2end-interest at postel.org>
Cc: <gorry at erg.abdn.ac.uk>; <dccp at ietf.org>
Sent: Tuesday, March 27, 2007 6:37 AM
Subject: Re: [e2e] Small packets - Definition needed..


> Dear All, (CCing to the DCCP mailing list)
>
> Thanks a lot for your replies.
>
>>From the replies, I could see that its hard to generalize the definition 
>>of
> small and large packets. My only worry is that that a proper consensus has
> to be reached on deciding the definition of small packets as currently 
> there
> seems to be an ambiguity (from my point of view) in some of the drafts 
> when
> it comes to defining small packets. For example consider the TFRC-SP and
> Faster Restart for TFRC drafts.
>
>
> Draft 1) TFRC-SP says the following in the Introduction
> ("draft-ietf-dccp-tfrc-voip-07.txt", currently in the RFC Editor's
> queue):
>
>     "TFRC-SP is intended for flows that need to send frequent small
>     packets, with less than 1500 bytes per packet, limited by a minimum
>     interval between packets of 10 ms."
>
>    "Applications that are not willing to be limited by a minimum
>     interval of 10 ms. between packets, or that want to send packets
>     larger than 1500 bytes, should not use TFRC-SP.  However, for
>     applications with a minimum interval of at least 10 ms. between
>     packets and with data packets of at most 1500 bytes, the performance
>     of TFRC-SP should be at least as good as that from TFRC."
>
> Draft 2) Faster Restart for TFRC
> (http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-02.
> txt) after idle periods: the allowed sending rate is never reduced below
> four packets per RTT, or eight packets per RTT for small packets, as the
> result of an idle or slow period.
>
> FR uses a variable called X_active_min_rate:
>    X_active_min_rate
>      The minimum restart rate allowed by Faster Restart in the presence
>      of idle and/or data-limited periods.  Note that Faster Restart
>      flows can drop below this rate as the result of actual loss
>      feedback.  X_active_min_rate is defined as follows:
>
>      X_active_min_rate := min(8*s, max(4*s, 8760 bytes)).
>
> So here the small packet is defined as anything less than 1095 bytes.
>
> As Joe Touch put forward, the relative size of header to payload could be
> the key to the answer.
>
> Regards
> Arjuna
>
> -----Original Message-----
> Craig Partridge wrote:
>> I don't know of a general definition.
>>
>> As I recall, for router tests in the early 1990s, the idea of a small
>> packet was 64 bytes and big was an Ethernet MTU.
>
> 64 bytes was the smallest effective link size, since Ethernet padded
> everything smaller out to 64 bytes. As a result, it often doesn't make 
> sense
> to think of packets being smaller on ethernet links.
>
>> Personally, I'd react that somewhere around 64 bytes is where packets
>> get small -- as the addition of a header becomes a notable overhead.
>> I'm not sure where I'd say "large" starts these days.
>
> When the header becomes notable depends on the header:
>
> UDP/IPv4/PPP = 30
> TCP/IPv6/IPsec/IPv6/ether+VLAN/GFP = 162
>
> There's quite a bit of range there, but the relative size of headers to
> payload is a good place to start.
>
> Joe
>
> -------------------------------
> From: David P. Reed [mailto:dpreed at reed.com]
> Sent: 23 March 2007 14:20
> To: Arjuna Sathiaseelan
> Cc: end2end-interest at postel.org
> Subject: Re: [e2e] Small packets - Definition needed..
>
> 576 is a lovely number of octets.   I first encountered its loveliness
> when I realized that it is 9 times 64.   Which means that all the
> popular word sizes of computers divide it evenly.   Thus, you can
> transmit packets that are composed of 72-bit, 36-bit, 64-bit, 32-bit,
> 24-bit, 18-bit, 16-bit, 12-bit, 8-bit, and 4-bit data arrays.
>
> And RSA-576 is the second largest number factored in the RSA Factoring
> Challenge (640, another number to be conjured with, was chosen by IBM
> and Microsoft as the limiting size of the IBM PC architecture's memory,
> and RSA-640 is the largest factored number in that challenge).
>
> And it has many other numerological properties.   It is the sum of 2^6
> and 2^9 octets.   69 is a wonderful reference (at least in English
> speaking countries).
>
> If you add the number 90 to it, it generates the biblical number we must
> not refer to here.   If you subtract 80 from it, you get one of the
> "perfect" numbers.   So it stands in the middle between perfectability
> and evil.
>
> -------------------------------
>
> Surely it depends on the application and environment? In the context of
> TFRC-SP, the aim was to support VoIP traffic, so small would be a low-rate
> voice codec (tens of octets of payload data per packet), but I don't think
> that generalises.
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
> Arjuna Sathiaseelan wrote:
>>
>> Dear All,
>>  I have been trying to find out the definition of small and large
>> packets. There are protocols such as TFRC-SP which are used for small
>> packets. I am wondering how do we define small packets? What is the
>> size limit?
>>
>> My thoughts on this is : any packet size less than 576 bytes, could be
>> considered as small packets. And more than 576 bytes, could be termed
>> large packets.
>>
>> Any thoughts.
>>
>> Regards
>> Arjuna
>>
>>
>>
>> -------------------------------
>>
>> Dr.Arjuna Sathiaseelan
>>
>> Electronics Research Group
>>
>> University of Aberdeen
>>
>> Aberdeen AB24 3UE
>>
>> Email: arjuna at erg.abdn.ac.uk <mailto:arjuna at erg.abdn.ac.uk>
>>
>> Web: www.erg.abdn.ac.uk/users/arjuna
>> <http://www.erg.abdn.ac.uk/users/arjuna>
>>
>> Phone : +44-1224-272780
>> Fax :     +44-1224-272497
>>
>>
>>
>