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

Harald Alvestrand <harald@alvestrand.no> Tue, 02 March 2021 07:42 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 CFBB03A27E4 for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 23:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 mFXeMS-D3jHs for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 23:42:03 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF2193A27E3 for <rtcweb@ietf.org>; Mon, 1 Mar 2021 23:42:03 -0800 (PST)
Received: from [192.168.3.157] (unknown [78.156.11.215]) by mork.alvestrand.no (Postfix) with ESMTPSA id BA1A37C684C; Tue, 2 Mar 2021 08:42:01 +0100 (CET)
To: Nils Ohlmeier <nohlmeier@mozilla.com>
Cc: rtcweb@ietf.org
References: <94b3d388-37cd-c29b-9c71-59f8ae14aefa@alvestrand.no> <5300B7A1-6D3E-4BD4-8D41-6A03C2D6E5CC@mozilla.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <4b7577f7-b738-245e-a489-18e8c0627043@alvestrand.no>
Date: Tue, 2 Mar 2021 08:42:01 +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: <5300B7A1-6D3E-4BD4-8D41-6A03C2D6E5CC@mozilla.com>
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/3qGiXTz6SgGUlpJITvQgq_fKEzw>
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:42:07 -0000

On 3/1/21 11:53 PM, Nils Ohlmeier 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.
>
>> We didn't discover the issue until we encountered a situation with large packets being sent on IPv6-only networks.
> So this IPv6 only network operated at 1280 bytes MTU?
> But you would have encountered the same issue on an IPv4 network with an MTU of ~1200 bytes as well, right?
>
> In other words if would do the safe thing here and use the way smaller IPv4 minimum MTU, we would end up with super small values.
> So I think the sane, but painful solution to this problem is to actually adjust the data channel MTU based on actual facts about the link (IP version, cipher in use, TURN channel vs data indication) rather then use a hard coded value.

IPv4 supports in-network fragmentation of overlarge datagrams (as long 
as you don't use the DF flag). So it would cause a performance penalty, 
but would not break communication.

And the practical IPv4 MTU on the Internet is 1480, not 572 (Ethernet 
MTU - typical tunneling overhead).

There's an outstanding bug in usrsctp 
(https://github.com/sctplab/usrsctp/issues/205) about SCTP path MTU 
discovery; the short version seems to be "it doesn't work".


>
> Best regards
>    Nils Ohlmeier
>