max udp datagram size

hi

is there the maximum UDP datagram size?

is there some recomendation to chose one based on the application /
network?

i have to send video over unreliable WiFi connection from a boat to
shore along with some control data in both directions. probably i'll
chose some existing transport / application layer protocol in the
end, but in a course if experiments i just started to wonder about
these UDP datagrams. it seems that if i try to send too large packets
i get "Bad address" error, but i can't find any documentation as too
what's the limit if any.

thanks

--
gr{oe|ee}t{en|ings}
artm

Artem Baguinski wrote:

> hi
>
> is there the maximum UDP datagram size?

getsockopt() with SO_MAX_MSG_SIZE option will get you the size, but it is
normally 65508 bytes.

> is there some recomendation to chose one based on the application /
> network?

Due to packet loss, generally apps do not send UDP packets larger than 16K. And
it is most efficient to send a multiple of the MTU less the UDP header size, or
for Ethernet 1500 - 28 = 1472 bytes.

> i have to send video over unreliable WiFi connection from a boat to
> shore along with some control data in both directions. probably i'll
> chose some existing transport / application layer protocol in the
> end, but in a course if experiments i just started to wonder about
> these UDP datagrams. it seems that if i try to send too large packets
> i get "Bad address" error, but i can't find any documentation as too
> what's the limit if any.
>
> thanks

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

"Phil Frisbie, Jr." <(E-Mail Removed)> writes:

> Artem Baguinski wrote:
>
>> hi is there the maximum UDP datagram size?
>
> getsockopt() with SO_MAX_MSG_SIZE option will get you the size, but it
> is normally 65508 bytes.
>
>> is there some recomendation to chose one based on the application /
>> network?
>
> Due to packet loss, generally apps do not send UDP packets larger than
> 16K. And it is most efficient to send a multiple of the MTU less the
> UDP header size, or for Ethernet 1500 - 28 = 1472 bytes.

thanks. and is it the same for 802.11g as for Ethernet? i have both
boxes connected with ethernet to wireless access points.


--
gr{oe|ee}t{en|ings}
artm

Phil Frisbie, Jr. <(E-Mail Removed)> wrote:
> Due to packet loss, generally apps do not send UDP packets larger
> than 16K. And it is most efficient to send a multiple of the MTU
> less the UDP header size, or for Ethernet 1500 - 28 = 1472 bytes.

I grok the IP fragmentation amplifies the packet loss rate into a much
larger datagram loss rate (*), but why is it more efficient if the
datagram a multiple of the MTU less header size? I wouldn't have
expected that to matter.

rick jones

(*) all fragments of an IP datagram must arrive to reassemble the
datagram. If there is a probability of packet loss "p" the probability
of packet arrival is (1-p). The probability of all the fragments of
the datagram arriving then is (1-p)^numfrag, and that gets small
rather quickly as numfrag increases...

--
oxymoron n, Hummer H2 with California Save Our Coasts and Oceans plates
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

Rick Jones wrote:

> Phil Frisbie, Jr. <(E-Mail Removed)> wrote:
>
>>Due to packet loss, generally apps do not send UDP packets larger
>>than 16K. And it is most efficient to send a multiple of the MTU
>>less the UDP header size, or for Ethernet 1500 - 28 = 1472 bytes.
>
> I grok the IP fragmentation amplifies the packet loss rate into a much
> larger datagram loss rate (*),

Good! Many people have a hard time understanding that.

> but why is it more efficient if the
> datagram a multiple of the MTU less header size? I wouldn't have
> expected that to matter.

It generally only matters on a LAN when sending a continuous series of packets,
due to the 28 byte header overhead and Ethernet frame collision protocol. For
example, if I am sending UDP packets 16192 (11*1472) bytes long, they will each
be sent as 11 1500 byte long IP packets. But if I send UDP packets 16K (16384)
bytes long, they will each be sent as 11 1500 byte long IP packets along with a
12th 220 byte long IP packet.

> rick jones
>
> (*) all fragments of an IP datagram must arrive to reassemble the
> datagram. If there is a probability of packet loss "p" the probability
> of packet arrival is (1-p). The probability of all the fragments of
> the datagram arriving then is (1-p)^numfrag, and that gets small
> rather quickly as numfrag increases...
>

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Phil Frisbie, Jr. <(E-Mail Removed)> wrote:
> Rick Jones wrote:
>> I grok the IP fragmentation amplifies the packet loss rate into a
>> much larger datagram loss rate (*),

> Good! Many people have a hard time understanding that.

I fell asleep a lot in probstats, but not that much

>> but why is it more efficient if the datagram a multiple of the MTU
>> less header size? I wouldn't have expected that to matter.

> It generally only matters on a LAN when sending a continuous series
> of packets, due to the 28 byte header overhead and Ethernet frame
> collision protocol. For example, if I am sending UDP packets 16192
> (11*1472) bytes long, they will each be sent as 11 1500 byte long IP
> packets. But if I send UDP packets 16K (16384) bytes long, they will
> each be sent as 11 1500 byte long IP packets along with a 12th 220
> byte long IP packet.

Ah, so your comment about efficiency was more about on the wire ratio
of headers to data. I thought there was something "magical" about
MTU-multiple datagram size in the Linux IP fragmentation code or
something.

Still, the difference in the ratios - at least in the example you give
- would seem to be really small - perhaps even epsilon.

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...

Rick Jones wrote:

> Phil Frisbie, Jr. <(E-Mail Removed)> wrote:
>
>>>but why is it more efficient if the datagram a multiple of the MTU
>>>less header size? I wouldn't have expected that to matter.
>
>
>>It generally only matters on a LAN when sending a continuous series
>>of packets, due to the 28 byte header overhead and Ethernet frame
>>collision protocol. For example, if I am sending UDP packets 16192
>>(11*1472) bytes long, they will each be sent as 11 1500 byte long IP
>>packets. But if I send UDP packets 16K (16384) bytes long, they will
>>each be sent as 11 1500 byte long IP packets along with a 12th 220
>>byte long IP packet.
>
> Ah, so your comment about efficiency was more about on the wire ratio
> of headers to data. I thought there was something "magical" about
> MTU-multiple datagram size in the Linux IP fragmentation code or
> something.
>
> Still, the difference in the ratios - at least in the example you give
> - would seem to be really small - perhaps even epsilon.

It can make a noticeable difference on half duplex Ethernet with packets
slightly larger than one or two MTUs. In the real world it does not make that
much difference, but still, if you have the control it is a good rule to follow.

> rick jones

--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com