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

Nils Ohlmeier <nohlmeier@mozilla.com> Mon, 01 March 2021 22:53 UTC

Return-Path: <nohlmeier@mozilla.com>
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 B69563A24A8 for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 14:53:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
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 kZJWL_pfJNIf for <rtcweb@ietfa.amsl.com>; Mon, 1 Mar 2021 14:53:47 -0800 (PST)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0733A3A24B5 for <rtcweb@ietf.org>; Mon, 1 Mar 2021 14:53:45 -0800 (PST)
Received: by mail-pg1-x532.google.com with SMTP id a23so2765737pga.8 for <rtcweb@ietf.org>; Mon, 01 Mar 2021 14:53:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LfoOwdBsOIn8Wgq8m/ozpQuw4nk+yWzu3zXyXuUGPmQ=; b=XpR+bo2XD8HMFpElkQH5qF8xTbmtYJZtlfRsyAE2HYBYNnTAwmptexlXjdfPzmanKf esF+J11RZCd6RiOmpVddg61SpLZ9KQVAV5j5D18X5J4+6R6I6sz1lSBTBIfHa4w6KqpZ HhQQpZRFWXPXgIW/prgzLYobKczIXAU3iGwXE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LfoOwdBsOIn8Wgq8m/ozpQuw4nk+yWzu3zXyXuUGPmQ=; b=TFKzoIzm46GZKDmtt2KGIBBZT++2yW/035qzr6Nk//p16sR5Rwswn2ATrfjo9iL/Fx Z5URwmv5jhpWNEeSMcMz2ki4y4emrQoJz/AsB7dY4x9GcaNuAogaqhRzcsqUD7IwW0XN G2x2Qhs8sEijFiQCpqnxons/joU7Vi0YwQfWGohnnL0/c2Wt7rw+pyq8dg7jcas9tuMt valDCxreU1pydiqQUl6XTeELpEPM5/daIiYP8lidj8FyEaWf27ElsogL3Rkrw+KDANER TOfMi3mXGuH14gLX0l4zpOrm/rpYGCcW+ldlWqh6ls4/KHA18CDv8MoSr5ml6tWQLx0j lPeA==
X-Gm-Message-State: AOAM531xQ4jgXjGSsi2ESPbBrOwHv0Voagq4YoYcZD5wVDq3Ku2+jJFl FjMyb8fqTD0tCtP2S8DTtYJenOyM9ttzMQ==
X-Google-Smtp-Source: ABdhPJzwOerj6RN6GugICTifDlJ3+oJp7esM5xMghDPUdntOUuXHCIqtjv1GOKJTYdc5XBuDRFPKqQ==
X-Received: by 2002:a65:5288:: with SMTP id y8mr14759600pgp.105.1614639224690; Mon, 01 Mar 2021 14:53:44 -0800 (PST)
Received: from ?IPv6:2601:647:4600:3f31:107b:5b9b:e09d:d554? ([2601:647:4600:3f31:107b:5b9b:e09d:d554]) by smtp.gmail.com with ESMTPSA id x11sm1132145pjh.0.2021.03.01.14.53.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Mar 2021 14:53:44 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Nils Ohlmeier <nohlmeier@mozilla.com>
In-Reply-To: <94b3d388-37cd-c29b-9c71-59f8ae14aefa@alvestrand.no>
Date: Mon, 1 Mar 2021 14:53:42 -0800
Cc: rtcweb@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5300B7A1-6D3E-4BD4-8D41-6A03C2D6E5CC@mozilla.com>
References: <94b3d388-37cd-c29b-9c71-59f8ae14aefa@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/WnTVKEegreJJMYrFDAq9qDQxwog>
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 22:53:54 -0000

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.

Best regards
  Nils Ohlmeier