UDP, portable maximum packet size.
Venu Nayar
>I was wondering, what is a generally supported maximum packet size on UDP?
What UDP does is to take the data that comes from the application
layer (which may be of any length) and encapsulate it in the header. Hence a
UDP packet can be of any length. IP then gets the UDP packet and fragments it
based on the MRU value. The MRU value is the maximum packet size which can be
transported on the underlying medium.
Hence the size of a packet which goes out is depends on your network
protocol - ethernet, token rng or whatever.
--
Venu Nayar | Internet: ve...@cirrus.com
Cirrus Logic Inc. | UUCP: oliveb!cirrus!venu
Work: (415)-226-2100 X3737 |
Home: (408)-942-0181 |
Stephen R. van den Berg
512 bytes? (surely)
536 bytes?
maybe 1024 bytes?
or even higher?
I am trying to define some UPD-communications protocol, and have to know
what a practical maximum packet size is (which still can be transmitted all
over the world).
--
Sincerely, be...@messua.informatik.rwth-aachen.de
Stephen R. van den Berg (AKA BuGless). be...@physik.tu-muenchen.de
"-- Listen carefully, I shall say this only once --"
Stephen R. van den Berg
>Stephen R. van den Berg writes:
>>I was wondering, what is a generally supported maximum packet size on UDP?
> What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium.
> Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.
Let me rephrase the question then, given these split up packets, does
portability (and reliability) somehow suffer beyond a certain critical UDP
packet size? (i.e. does it matter in how many physical packets one UDP
packet is splitted?)
Someone suggested that 8KB UDP packets can be transmitted across most of
the Internet without problems; seems like a bit optimistic to me, or is it?
--
Sincerely, be...@messua.informatik.rwth-aachen.de
Stephen R. van den Berg (AKA BuGless). be...@physik.tu-muenchen.de
Real programmers don't just die, they produce core dumps.
Tay Beng Hang
In <1991Oct18.1...@urmel.informatik.rwth-aachen.de> be...@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>>I was wondering, what is a generally supported maximum packet size on UDP?
>What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
Theoretically, the maximum size of an UDP packet is 64K, this is
derived from the length field in UDP packet which is 16 bit only.
If the application has data longer than 64K, it is the responsibility
of the application to fragment the data into several UDP packet and
transmit them one by one. UDP protocol does NOT fragment the data
at all. Note that the actual size of data that can be transmitted
in one UDP packet depends very much on the implementation
(buffer size between application process and the protocol). For
example, in most BSD socket implementations of UDP, 8k is the
most portable size that an application can send in one UDP pakcet.
I guess this is the reason why 8K was taken as the NFS packet size.
>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium.
>Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.
This is true.
____________________________________________________________________________
| Beng-Hang Tay | Telnet: 520 8732 |
| Singapore Networks Operation | Phone: (65) 279 8732 |
| Hewlett-Packard Singapore Pte. Ltd. | Fax: (65) 272 2780 |
| 1150 Depot Road | Internet: ta...@hpsgm2.sgp.hp.com |
| Singapore 0410 | ta...@hpsgnlc.sgp.hp.com |
| Republic of Singapore | HPDesk: HP3200/67 |
----------------------------------------------------------------------------
W. Richard Stevens
>>layer (which may be of any length) and encapsulate it in the header. Hence a
>>UDP packet can be of any length.
I don't think this answer is correct, but as usual, it depends a lot
on the implementation. I think you'll find most UDP implementations
do indeed have an upper limit on the size of data that a user process
can send as a UDP datagram. Remember that what goes out of UDP has to
go through IP, and there may also be an IP limit. I think the only
absolute guarantee is that IP must handle a 576-byte IP datagram. I
also think that this 576-byte guarantee is why you sometimes see some
applications never exceeding around 512-bytes of user data in a UDP
datagram (e.g., the DNS and TFTP).
Most current BSD-derived systems initialize the limit when the socket
is created--look at udp_sendspace and udp_recvspace in netinet/udp_usrreq.c
in any of the BSD sources. Most systems initialize these to just over
8k bytes. As I recall, 4.3BSD Tahoe set these to 2k bytes, but I think
they're back at 8k with Reno. You can also change these after the socket
is created with setsockopt() and either SO_SNDBUF or SO_RCVBUF. I know
that there are systems out there with smaller limits.
Rich Stevens (rste...@noao.edu)
Rich Braun
>>I was wondering, what is a generally supported maximum packet size on UDP?
ve...@cirrus.com (Venu Nayar) writes:
> What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value.
But, if you want the answer for an Ethernet-based LAN, between two
systems on the same physical medium, and you don't want fragmentation
to happen, remember that the maximum-sized Ethernet packet is 1536 bytes.
A UDP header is 8 bytes, an IP header is 20 bytes, an Ethernet header
is 18 bytes, and the trailing checksum is 2 bytes. My calculation
therefore yields 1488 bytes for data in a non-fragmented UDP packet.
Am I off by a few bytes?
-rich
Art Berggreen
>In <1991Oct18.1...@urmel.informatik.rwth-aachen.de> be...@physik.tu-muenchen.de (Stephen R. van den Berg) writes:
>
>>I was wondering, what is a generally supported maximum packet size on UDP?
>
> What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium.
> Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.
While it is true in theory that a UDP datagram can be up to 65K, most
implementations have default or hard limits on the size of UDP datagrams
that the networking code will accept. I believe the question was aimed
at finding a safe value that will be accepted by most machines.
Art
Darren Croke
>
>>I was wondering, what is a generally supported maximum packet size on UDP?
>
> What UDP does is to take the data that comes from the application
>layer (which may be of any length) and encapsulate it in the header. Hence a
>UDP packet can be of any length. IP then gets the UDP packet and fragments it
>based on the MRU value. The MRU value is the maximum packet size which can be
>transported on the underlying medium.
> Hence the size of a packet which goes out is depends on your network
>protocol - ethernet, token rng or whatever.
The 4.3 bsd implementation maintains a global called udp_recvspace.
This variable is initialized with the following line of code -
u_long udp_recvspace = 4 * (1024+sizeof(struct sockaddr_in)); /* 4 1K dgrams */
During the creation of a udp socket, this variable is passed to a
routine called soreserve() which sets the hiwater mark for the receive
socket buffer which effectively limits received udp datagram size.
Obviously, anyone using this code can increase the value but I'm sure
you'll find implementations out there that have gone with the default.
--
Darren Croke Micronics Computers
d...@micronics.com X Terminal Division
(415) 651-2300
Art Berggreen
A few.
The Information field of an Ethernet packet is only 1500 bytes, so your
numbers are a bit high (really 1472 bytes of UDP data). And the Ethernet
FCS is actually 4 bytes.
>-rich
Art
Chuck Kollars - Sun BOS Software
>systems on the same physical medium, and you don't want fragmentation
>to happen, remember that the maximum-sized Ethernet packet is 1536 bytes.
>A UDP header is 8 bytes, an IP header is 20 bytes, an Ethernet header
>is 18 bytes, and the trailing checksum is 2 bytes. My calculation
>therefore yields 1488 bytes for data in a non-fragmented UDP packet.
Close...
The total time from the start of one Ethernet frame to the start of the
next is a minimum of ~1538 byte times. This includes 12 byte times of
interframe spacing and 8 byte times of preamble along with the actual
frame size of 1518 bytes.
Of that 1518 bytes, 4 are FCS, leaving 1514. Another 6 are destination
Ethernet address, 6 are source Ethernet address, and 2 are type,
leaving 1500 bytes for user data in each frame. (This assumes you're
using the DIX Ethernet Version II frame format. If instead you're
using IEEE 802.3 frame format, the 2 byte "type" field becomes the
"length" field and an additional 5 bytes are consumed by the "SNAP"
header.)
Of that 1500 bytes, at least 20 go to an IP header, and 8 go to the UDP
header, leaving a maximum 1472 bytes of application data in each
frame. (If the IP header includes "options", it will be larger and the
space for application data will be smaller. Also some of the
"application" data may be an RPC header.)
---
chuck kollars <ckol...@East.Sun.COM> (located in Boston)
Systems and Network Administration Group (SNAG)