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

Harald Alvestrand <harald@alvestrand.no> Mon, 08 March 2021 09:19 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9972D3A2875 for <rtcweb@ietfa.amsl.com>; Mon, 8 Mar 2021 01:19:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P617Ob8FKmHo for <rtcweb@ietfa.amsl.com>; Mon, 8 Mar 2021 01:19:56 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C21E3A2874 for <rtcweb@ietf.org>; Mon, 8 Mar 2021 01:19:56 -0800 (PST)
Received: from [192.168.3.157] (unknown [78.156.11.215]) by mork.alvestrand.no (Postfix) with ESMTPSA id B6C817C684A; Mon, 8 Mar 2021 10:19:54 +0100 (CET)
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, rtcweb@ietf.org
References: <94b3d388-37cd-c29b-9c71-59f8ae14aefa@alvestrand.no> <5300B7A1-6D3E-4BD4-8D41-6A03C2D6E5CC@mozilla.com> <388582AE-1FC6-4CD7-94DB-82FB68CCF679@lurchi.franken.de> <90b567c1-40d3-6005-44c3-efd5d52c2064@alvestrand.no> <6E8C387A-5A36-41CD-8DC0-906CD1B44290@lurchi.franken.de>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <97b8777a-a014-7561-9be7-4566c5bc024d@alvestrand.no>
Date: Mon, 8 Mar 2021 10:19:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <6E8C387A-5A36-41CD-8DC0-906CD1B44290@lurchi.franken.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/Gw7aCghDi7G5qejAie9RvXxY5xY>
Subject: Re: [rtcweb] SCTP issue: Datachannel MTU seems to be problematic.
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 09:19:59 -0000

On 3/2/21 12:00 PM, Michael Tuexen wrote:
>> On 2. Mar 2021, at 08:53, Harald Alvestrand <harald@alvestrand.no> wrote:
>>
>>
>> On 3/2/21 12:09 AM, Michael Tuexen wrote:
>>>> On 1. Mar 2021, at 23:53, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
>>>>
>>>> Hi Harald,
>>>>
>>>>> On 1Mar, 2021, at 11:17, Harald Alvestrand <harald@alvestrand.no> 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.
>>
>>
>>
>>
>>