Documents uploaded

Callaghan, Robert Robert.Callaghan at ICN.SIEMENS.COM
Thu Oct 26 14:14:28 EDT 2000


As Brian says, there are several different answers.

In reality, the max length IP packet supported is constrained by the MTU
(max transmission unit) supported by the host at each end (usually a
function of receive buffers) and of the subnets in the path.

Since IP is an internetworking protocol, it runs over a number of
networking technologies and protocols, each with its own frame or packet
size limitation.  For example, running IP over an X.25 network (e.g., ISDN
D-channel X.25) might limit the MTU size to 128 octets.  Ethernet allows
1500 bytes.

RFC1191 contains a table of MTU sizes for various subnet technologies and
the RFC numbers in which they are defined.  I copy the table below (one
advantage of having ASCII specs :-).

    Plateau    MTU    Comments                      Reference
    ------     ---    --------                      ---------
               65535  Official maximum MTU          RFC 791
               65535  Hyperchannel                  RFC 1044
    65535
    32000             Just in case
               17914  16Mb IBM Token Ring           ref. [6]
    17914
               8166   IEEE 802.4                    RFC 1042
    8166
               4464   IEEE 802.5 (4Mb max)          RFC 1042
               4352   FDDI (Revised)                RFC 1188
    4352 (1%)
               2048   Wideband Network              RFC 907
               2002   IEEE 802.5 (4Mb recommended)  RFC 1042
    2002 (2%)
               1536   Exp. Ethernet Nets            RFC 895
               1500   Ethernet Networks             RFC 894
               1500   Point-to-Point (default)      RFC 1134
               1492   IEEE 802.3                    RFC 1042
    1492 (3%)
               1006   SLIP                          RFC 1055
               1006   ARPANET                       BBN 1822
    1006
               576    X.25 Networks                 RFC 877
               544    DEC IP Portal                 ref. [10]
               512    NETBIOS                       RFC 1088
               508    IEEE 802/Source-Rt Bridge     RFC 1042
               508    ARCNET                        RFC 1051
    508 (13%)
               296    Point-to-Point (low delay)    RFC 1144
    296
    68                Official minimum MTU          RFC 791

                 Table 7-1:  Common MTUs in the Internet


In a general case implementation, I would support at least 1500 bytes MTU
sizes.  As for your specific application (video), it might not require 1500
byte packets.  Supporting some type of Path MTU Discovery (RFC1191 or
RFC1981) might be useful to avoid fragmentation since some paths don't
support 1500 byte MTUs.  For example, many tunneling technologies (GRE,
L2TP, IPSEC) reduce the effective packet size.

Chip

At 10:09 PM 10/25/00 -0400, Rosen, Brian wrote:
>There is the "real" answer, and the practical answer.
>
>The real answer is that depending on what kind of network you are on,
>you could see, in theory, packets of up to 64K bytes.  4K bytes can actually
>be
>seen in some Gig-E systems.  Whether you will find a video codec using such
>large packets sizes or not is uncertain; I've never seen one.
>
>It used to be that we thought 1510-odd bytes was the biggest practical
>packet you
>see on a LAN, but that's no longer the case.  There is a lot of code around
>that
>fails above that 1500 ish number.
>
>Brian
>
> > -----Original Message-----
> > From: Chris Farmer [mailto:cfarmer at smithmicro.com]
> > Sent: Wednesday, October 25, 2000 9:05 PM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Sanity check on Packet Sizes....
> >
> >
> > Okay,
> >
> > I was researching an arcane fact on the theoretical and
> > practical sizes for
> > RTP packet sizes for
> > video conferencing.
> >
> > What I have come up with is:
> > There is specific RFC's about implimenting H.263, H.261,
> > G.723, but I'm
> > looking for just an overall
> > practical size to check input buffer sizes.
> >
> > RFC 1889 RTP packet structure referes to 768, RFC 791
> > RFC 768 UDP refers to obsolete RFC 760.
> > RFC 791 states in the Glossory,
> >     ARPANET messages max size is about 1012 octets (8096)bits.
> >    ARPANET packet max size is about 126 octets (1008) bits.
> >
> > As a client side EP, should I be concerned about the ARPANET
> > message size or
> > the ARPANET packet size?
> >
> > RFC 760 states:
> >         65,536 octets theoretically, put not practical
> >             Page 22, every destination should be able to
> > receive a datagram
> > of 576 octets in one piece or as fragments to be reassembled
> >
> > so my guess here is 4608 bits max?  Or is this too low level
> > and there is
> > another RFC that I should reference?
> >
> > Any help in this direction?
> >
> > Thanks,
> >
> >
> > Christopher B. Farmer
> > Software Engineer
> > Smith Micro Software, Inc.
> > (503) 641-1221 ext 28
> > ======================================================================
> > Daily C\C++ Tidbits at www.EngageUs.com\c
> > "Challenges in life are inevitable.  Failure is optional" -
> > Roger Crawford
> > ======================================================================
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
> >
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>For help on this mail list, send "HELP ITU-SG16" in a message to
>listserv at mailbag.intel.com


-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
"The best way to pick a lock is with a key."
http://www.netaid.org
-------------------------------------------------------------------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list