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

Michael Tuexen <michael.tuexen@lurchi.franken.de> Mon, 01 March 2021 23:09 UTC

Return-Path: <michael.tuexen@lurchi.franken.de>
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 7CD363A249C for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 15:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01] 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 troyqW2-oD5I for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 15:09:31 -0800 (PST)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B203A249B for <rtcweb@ietf.org>; Mon, 1 Mar 2021 15:09:31 -0800 (PST)
Received: from mbp.fritz.box (ip4d16007f.dynamic.kabel-deutschland.de [77.22.0.127]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 995B274AA01B2; Tue, 2 Mar 2021 00:09:22 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <5300B7A1-6D3E-4BD4-8D41-6A03C2D6E5CC@mozilla.com>
Date: Tue, 2 Mar 2021 00:09:22 +0100
Cc: Harald Alvestrand <harald@alvestrand.no>, rtcweb@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <388582AE-1FC6-4CD7-94DB-82FB68CCF679@lurchi.franken.de>
References: <94b3d388-37cd-c29b-9c71-59f8ae14aefa@alvestrand.no> <5300B7A1-6D3E-4BD4-8D41-6A03C2D6E5CC@mozilla.com>
To: Nils Ohlmeier <nohlmeier@mozilla.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/rOehZQfLFSmA8ZcS6FLwo_KeawI>
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, 01 Mar 2021 23:09:34 -0000

> 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?

Best regards
Michael
> 
>> 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.
> 
> Best regards
>  Nils Ohlmeier
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb