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

[Harald Alvestrand <[e-mail]>]

On 3/2/21 12:00 PM, Michael Tuexen wrote:
>> On 2. Mar 2021, at 08:53, Harald Alvestrand <[e-mail]> wrote:
>>
>>
>> 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.)
> But in that case the specification says the IP level PMTU is at least 1280. The
> overhead related to the protocol between IPv6 and SCTP is not specified in the RFC.


It's implied by the stack in RFC 8835 section 3.5 (rtcweb-transport); we 
just never worked out the right number from that.



>
> Best regards
> Michael
>> 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.
>>
>>
>>
>>
>>