Why RTP max packet size is 1200 in WebRTC?

[cyberwoodman]

HI all.

Buy studying WebRTC sources I was wondering why developers chose RTP max packet size as 1200 bytes.

As I correctly understood right now this constant is definded in media/engine/constants.cc|16| const int kVideoMtu = 1200;

Thanks.

[Lorenzo Miniero]

Not a Chrome or libwebrtc developer, but I can give you a general answer. While the MTU is typically large enough (slightly lower than 1500) you can't assume it will be the same everywhere on the media path. If the packet you send is larger than the MTU of a network node, the packet will simply be dropped. Considering the overhead you can have with WebRTC on packets (SRTP, extensions, etc.), you want a smaller RTP packet to start from, to be sure the packet will always get through.

L.

[Istvan Fenesi]

https://stackoverflow.com/questions/47635545/why-webrtc-chose-rtp-max-packet-size-to-1200-bytes/47650260#47650260

[Iñaki Baz Castillo]

You can say "thanks" to all those "sys admins" that block ICMP for
"security reasons".



--
Iñaki Baz Castillo
<i...@aliax.net>

[Niels Moller]

I think that's vaguely related. It would be reasonable for webrtc to
try to do path MTU discovery, which under IPv4 would mean setting the
"don't fragment" bit on sent packets, and respond to incoming ICMP.
(Which would then be broken if ICMP is gratuitously blocked, just like
TCP path MTU discovery breaks down in that case).

But we don't do anything like that, as far as I'm aware. Which means
that the IPv4 network is expected to fragment any packets that are too
large for some link on the path. Which has the drawback that if one of
the fragments is lost, other fragments will consume network resources
but still be useless if they make it to the receiver.

So the smaller max packet size is to avoid packet fragmentation.

[cyberwoodman]

Yep, thanks, it's my post :)

[cyberwoodman]

Thanks. Do you know who discovered such constant?

[Harald Alvestrand]

On Tue, Dec 5, 2017 at 12:03 PM, cyberwoodman <taras.k...@gmail.com> wrote:

Thanks. Do you know who discovered such constant?

Part of Internet folklore for the past 20 years.

Piece of history: The IPv4 minimum payload size was 576 bytes. Any link layer smaller than this had to do fragmentation/reassembly on the link.

(I've heard of people ignoring this and setting the MTU of their modem to 128 bytes. IP still worked.)

When IPv6 came along, the Internet had pretty much stabilized on the Ethernet frame size - 1500 bytes. A calculation of a standard IPv6 header + a layer or two of encapsulation led to the conclusion that it was safe to guarantee a payload size of 1280 bytes in all cases. (This isn't strictly true - the IPv6 header allows unlilmited "continuation" headers - what used to be called header extensions in IPv4. But packets with "continuation headers" are handled badly by most routers, so in practice they're not used for normal user traffic.)

Anyway, 1200 bytes is 1280 bytes minus the RTP headers minus some bytes for RTP header extensions minus a few "let's play it safe" bytes. It'll usually work.

 

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/80d628b7-fdca-4127-8faa-8f471fa20670%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[cyberwoodman]

Thanks. I think your first sentence completely explains my question!

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[cyberwoodman]

Here is a good explanation why packet should be lesser or equal than 1280 bytes for IPv6 networks.
https://www.arbornetworks.com/blog/asert/ipv6-fragmentation/

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Horaci Macias]

is this max RTP packet size value configurable or "tweakable" by any means? I'm trying to eliminate fragmentation on a network with MTU < 1200.

thanks,

H 

[Harald Alvestrand]

I didn't know that anyone were running networks with MTU < 1200 any more ... at the very least, you'll never get IPv6 on those networks, since that requires an ~1400 byte subnetwork-layer MTU. I'm curious - care to share what kind of network it is?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e4d9bdf9-8e25-43bf-94c6-62c8ebd798cc%40googlegroups.com.

[Horaci Macias]

Hi Harald,

The network I'm using uses MPLS links and some protocol tuneling that reduces the size available for application layers.

I'm still troubleshooting this as we speak to see if there is any other alternative, but still I'd like to know if this 1200 value in chrome is configurable by any means, at least to try things out.

My end goal is eliminate IP fragmentation completely on this environment which seems to be causing some glitches.

thanks,

H

[Iñaki Baz Castillo]

On 5 February 2018 at 13:35, Horaci Macias <horaci...@gmail.com> wrote:
> Hi Harald,

>
> I'm still troubleshooting this as we speak to see if there is any other
> alternative, but still I'd like to know if this 1200 value in chrome is
> configurable by any means, at least to try things out.

AFAIK the 1200 is hardcoded.

[Harald Alvestrand]

For video, here:

https://codesearch.chromium.org/chromium/src/third_party/webrtc/media/engine/constants.cc?type=cs&q=1200+file:webrtc&sq=package:chromium&l=16

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfkhUz_JDW5chDOSnZkKXW0zQENvmT3P4BB1bX6g8WYoKw%40mail.gmail.com.

[Horaci Macias]

OK. Thanks!