-----Original Message-----
From: Arjuna Sathiaseelan [mailto:arjuna@xxxxxxxxxxxxxx]
Sent: den 27 mars 2007 00:37
To: end2end-interest@xxxxxxxxxx
Cc: gorry@xxxxxxxxxxxxxx; dccp@xxxxxxxx
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-fast
er-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
