[OSC_dev] OSC/UDP packet sizes for interoperability

[Ross Bencina]

Hi Everyone,

Is there consensus regarding the maximum expected size of an OSC/UDP packet?

My concern is with providing a library that correctly inter-operates
with other implementations.

I had assumed that it was inappropriate to exceed the standard MTU
constraints (1500 bytes, although some sources I've recently found
suggest 512 bytes). Oscpack currently over-allocates its internal
receive buffer to 4096 bytes. However I have received requests to
increase buffering in oscpack to provide compatibility with code that
uses larger packet sizes. (see [1] for the current discussion).

I checked the "Best Practices" paper [2], but aside from mentioning
potential fragmentation, it is silent on the issue of an appropriate
maximum packet size.

Any suggestions?

Thank you,

Ross.


[1] https://github.com/openframeworks/openFrameworks/issues/3106

[2] http://opensoundcontrol.org/files/osc-best-practices-final.pdf

[Matt Wright]

I always went by UDP itself, where the 16-bit packet size count sets the limit. (Yes, on many networks you will get better UDP performance with packets that each fit within one MTU.)

http://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure

Length
A field that specifies the length in bytes of the UDP header and UDP data. The minimum length is 8 bytes since that's the length of the header. The field size sets a theoretical limit of 65,535 bytes (8 byte header + 65,527 bytes of data) for a UDP datagram. The practical limit for the data length which is imposed by the underlying IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header − 20 byte IP header).[3]
In IPv6 Jumbograms it is possible to have UDP packets of size greater than 65,535 bytes.[6] RFC 2675 specifies that the length field is set to zero if the length of the UDP header plus UDP data is greater than 65,535.

-Matt

Hi Everyone,
Is there consensus regarding the maximum expected size of an OSC/UDP packet?
My concern is with providing a library that correctly inter-operates
with other implementations.
I had assumed that it was inappropriate to exceed the standard MTU
constraints (1500 bytes, although some sources I've recently found
suggest 512 bytes). Oscpack currently over-allocates its internal
receive buffer to 4096 bytes. However I have received requests to
increase buffering in oscpack to provide compatibility with code that
uses larger packet sizes. (see [1] for the current discussion).
I checked the "Best Practices" paper [2], but aside from mentioning
potential fragmentation, it is silent on the issue of an appropriate
maximum packet size.
Any suggestions?
Thank you,
Ross.
[1] https://github.com/openframeworks/openFrameworks/issues/3106
[2] http://opensoundcontrol.org/files/osc-best-practices-final.pdf
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Ross Bencina]

Thanks Matt, I guess that settles it then.

For some reason I thought fragmented UDP packets necessarily lead to the
packets being dropped/discarded. I wonder where I got that idea.

Cheers,

Ross.

Post by Matt Wright
I always went by UDP itself, where the 16-bit packet size count sets the
limit. (Yes, on many networks you will get better UDP performance with
packets that each fit within one MTU.)
http://en.wikipedia.org/wiki/User_Datagram_Protocol#Packet_structure

*Length*
A field that specifies the length in bytes of the UDP header and UDP
data. The minimum length is 8 bytes since that's the length of the
header. The field size sets a theoretical limit of 65,535 bytes (8
byte header + 65,527 bytes of data) for a UDP datagram. The practical
limit for the data length which is imposed by the
underlying IPv4 protocol is 65,507 bytes (65,535 − 8 byte UDP header −
20 byte IP header).[3]
In IPv6 Jumbograms it is possible to have UDP packets of size greater
than 65,535 bytes.[6] RFC 2675 specifies that the length field is set
to zero if the length of the UDP header plus UDP data is greater than
65,535.

-Matt

Hi Everyone,
Is there consensus regarding the maximum expected size of an OSC/UDP packet?
My concern is with providing a library that correctly inter-operates
with other implementations.
I had assumed that it was inappropriate to exceed the standard MTU
constraints (1500 bytes, although some sources I've recently found
suggest 512 bytes). Oscpack currently over-allocates its internal
receive buffer to 4096 bytes. However I have received requests to
increase buffering in oscpack to provide compatibility with code that
uses larger packet sizes. (see [1] for the current discussion).
I checked the "Best Practices" paper [2], but aside from mentioning
potential fragmentation, it is silent on the issue of an appropriate
maximum packet size.
Any suggestions?
Thank you,
Ross.
[1] https://github.com/openframeworks/openFrameworks/issues/3106
[2] http://opensoundcontrol.org/files/osc-best-practices-final.pdf
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[IOhannes m zmoelnig]

Post by Matt Wright
I always went by UDP itself, where the 16-bit packet size count
sets the limit.

+1

(Yes, on many networks you will get better UDP performance with
packets that each fit within one MTU.)


and keep inmind that while 1500 is usually the maximum packet size,
there are execptions:
- - gbit ethernet often suggests to use jumbo-frames for better
performance, that have a much higher MTU (9000 seems to be used often
enough)
- - the loopback (software) device is not encumbered by those MTU
limitations, and thus you will often find an MTU of 65536¹ bytes.


fgmasr
IOhannes


¹ hmm, this is what ifconfig shows on my system...