Re: [rtcweb] SCTP issue: Datachannel MTU seems to be problematic.

[Harald Alvestrand <[e-mail]>]

On 3/2/21 12:09 AM, Michael Tuexen wrote:
>> On 1. Mar 2021, at 23:53, Nils Ohlmeier <[e-mail]> wrote:
>>
>> Hi Harald,
>>
>>> On 1Mar, 2021, at 11:17, Harald Alvestrand <[e-mail]> wrote:
>>>
>>> This for info:
>>>
>>> We have recently discovered some problems with SCTP on small-MTU networks.
>> Interesting problem you encountered there.
>>
>>> Turns out we underestimated the max size of the encapsulating headers.
>>>
>>> Current calculation:
>>>
>>> // The biggest SCTP packet. Starting from a 'safe' wire MTU value of 1280,
>>> // take off 85 bytes for DTLS/TURN/TCP/IP and ciphertext overhead.
>>> //
>>> // Additionally, it's possible that TURN adds an additional 4 bytes of overhead
>>> // after a channel has been established, so we subtract an additional 4 bytes.
>>> //
>>> // 1280 IPV6 MTU
>>> //  -40 IPV6 header
>>> //   -8 UDP
>>> //  -24 GCM Cipher
>>> //  -13 DTLS record header
>>> //   -4 TURN ChannelData
>>> // = 1191 bytes.
>>>
>>> Which is somewhat smaller than the number we assumed in the RFC of 1200 bytes.
>> What I don’t understand here is that this calculation is only done for IPv6, which has a significantly higher minimum MTU compared to IPv4.
> I was assuming that an IPv6 network is used with an MTU of 1280 to provide IPv4 connectivity via a TURN service.
> So the IPv4 level MTU would be 1191, which is smaller than 1200 as mentioned in the RFC... Or am I wrong?

The actual problem we discovered in production was in a case without 
TURN, but with a client that did IPv6 only. (It may also be client OS 
specific - we're not sure about that.)

So we could probably have gotten away with an MTU of 1195 bytes.

I'm also not sure if the 24 bytes of GCM cipher overhead is the right 
number for all ciphersuites that we permit; we may have to keep an eye 
on that.

But yes, we need Path MTU discovery to work, including a way to recover 
from too-large initial assumptions.