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

Harald Alvestrand <harald@alvestrand.no> Tue, 02 March 2021 07:53 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 6F4223A281C for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 23:53:07 -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 A1llsVW2uho5 for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 23:53:05 -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 9B8193A281B for <rtcweb@ietf.org>; Mon, 1 Mar 2021 23:53:05 -0800 (PST)
Received: from [192.168.3.157] (unknown [78.156.11.215]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1DB8E7C685C; Tue, 2 Mar 2021 08:53:04 +0100 (CET)
To: Michael Tuexen <michael.tuexen@lurchi.franken.de>, Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: 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>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <90b567c1-40d3-6005-44c3-efd5d52c2064@alvestrand.no>
Date: Tue, 2 Mar 2021 08:53:03 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <388582AE-1FC6-4CD7-94DB-82FB68CCF679@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/QoQ4YZ2pM5DJ_Cq8FXjRJhuLpE4>
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: Tue, 02 Mar 2021 07:53:07 -0000

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.)

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.