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@xxxxxxxx]
Sent: 23 March 2007 14:20
To: Arjuna Sathiaseelan
Cc: end2end-interest@xxxxxxxxxx
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@xxxxxxxxxxxxxx <mailto:arjuna@xxxxxxxxxxxxxx>
>
> Web: www.erg.abdn.ac.uk/users/arjuna
> <http://www.erg.abdn.ac.uk/users/arjuna>
>
> Phone : +44-1224-272780
> Fax : +44-1224-272497
>
>
>
