[e2e] Small packets - Definition needed..

[Arjuna Sathiaseelan]

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