>From my viewpoint (3GPP walled garden) 576octects is quite large. For VoIP we speak about codec rates from less than 5kbps to 23kbps (AMR and AMR-WB), giving payloadsizes that ranges from ~10bytes to ~60bytes. Other speech codecs may be as high as ~60kbps and the packet sizes then varies with the frame size. Agree that it is probably quite tricky to tell the difference between small and big... Ingemar > -----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 > > > > > > > > >
