Re: [tsvwg] DTLS 1.3 over SCTP
Michael Tuexen <michael.tuexen@lurchi.franken.de> Fri, 14 July 2023 10:23 UTC
Return-Path: <michael.tuexen@lurchi.franken.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BD1C15154F for <tsvwg@ietfa.amsl.com>; Fri, 14 Jul 2023 03:23:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d6haS1d3RlY for <tsvwg@ietfa.amsl.com>; Fri, 14 Jul 2023 03:23:44 -0700 (PDT)
Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64AF5C14CEFE for <tsvwg@ietf.org>; Fri, 14 Jul 2023 03:23:44 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:85a6:7e27:ddf8:905b]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 8E6FA770DB881; Fri, 14 Jul 2023 12:23:41 +0200 (CEST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
In-Reply-To: <PA4PR07MB75686885CBFD806697BA548F8734A@PA4PR07MB7568.eurprd07.prod.outlook.com>
Date: Fri, 14 Jul 2023 12:23:41 +0200
Cc: tsvwg IETF list <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1580DEE1-B807-46AA-BFA6-F9D37BBEEEFE@lurchi.franken.de>
References: <0C990143-D450-4288-9390-E06D3469FF1D@lurchi.franken.de> <PA4PR07MB7568B70C363F70CA9CF005648734A@PA4PR07MB7568.eurprd07.prod.outlook.com> <B35A9C2C-9360-4248-B0FA-552ADC1F5D05@lurchi.franken.de> <PA4PR07MB7568AAF7162A90DC79945DAB8734A@PA4PR07MB7568.eurprd07.prod.outlook.com> <FFC46CD7-5416-4526-8C2C-0BFD55E62FD7@lurchi.franken.de> <PA4PR07MB75686885CBFD806697BA548F8734A@PA4PR07MB7568.eurprd07.prod.outlook.com>
To: Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/gcFDMTdd0-fIRl_Tqo7OGSgz0_Q>
Subject: Re: [tsvwg] DTLS 1.3 over SCTP
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jul 2023 10:23:49 -0000
> On 14. Jul 2023, at 12:16, Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> wrote: > > Hi Michael, > Yes, they send atomic messages. No fragmentation is foreseen. OK, great. Any prediction/requirements on the message rates and/or bandwidths? Best regards Michael > > BR, > Claudio > > -----Original Message----- > From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Michael Tuexen > Sent: Friday, 14 July 2023 11:42 > To: Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> > Cc: tsvwg IETF list <tsvwg@ietf.org> > Subject: Re: [tsvwg] DTLS 1.3 over SCTP > >> On 14. Jul 2023, at 11:24, Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> wrote: >> >> Hi Michael, >> As an example, S1-AP protocol that exploits SCTP and is described in TS 36.413 (the protocol) and TS 36.412 (the transport) can send a single message that contains all the features from a User Equipment and the total maximum size of this signal may grow up to 142k. > I see. >> S1-AP is not the most demanding though, there are signals in Xn protocol specified in TS 48.423 that can grow up to more than 500k > 500KB in a single message. What message rates are expected? What is the expected bandwidth of links carrying this > traffic. > > I assume that sending/receiving the messages are atomic operations from an application point of view. Is that correct? > > Best regards > Michael >> >> BR, >> Claudio. >> >> -----Original Message----- >> From: Michael Tuexen <michael.tuexen@lurchi.franken.de> >> Sent: Friday, 14 July 2023 11:14 >> To: Claudio Porfiri <claudio.porfiri@ericsson.com> >> Cc: tsvwg IETF list <tsvwg@ietf.org> >> Subject: Re: [tsvwg] DTLS 1.3 over SCTP >> >>> On 14. Jul 2023, at 08:04, Claudio Porfiri <claudio.porfiri=40ericsson.com@dmarc.ietf.org> wrote: >>> >>> Hi Michael, >>> I am reading this new draft but I have a quick comment at once. >>> The requirements from 3GPP towards SCTP are far beyond the limit of 64k, for instance S1-AP needs up to 142k. >> Hi Claudio, >> >> could you provide some insight what kind of signalling message needs up to 142KB? >> Just wondering what kind of information needs 142 KB. >>> This new draft improves the situation but doesn't solve it. >> The focus is not limited to 3GPP. We are trying to improve the situation >> for RFC 6083 with minimizing the changes. >> >> Best regards >> Michael >>> >>> Best regards, >>> Claudio >>> >>> -----Original Message----- >>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Michael Tuexen >>> Sent: Thursday, 13 July 2023 16:35 >>> To: tsvwg IETF list <tsvwg@ietf.org> >>> Subject: [tsvwg] DTLS 1.3 over SCTP >>> >>> Dear all, >>> >>> Hannes Tschofenig and myself have submitted an ID for using DTLS 1.3 over SCTP: >>> https://www.ietf.org/archive/id/draft-tuexen-tsvwg-rfc6083-bis-02.html >>> >>> This is an alternative to >>> https://www.ietf.org/archive/id/draft-ietf-tsvwg-dtls-over-sctp-bis-06.html >>> >>> Our document is based on RFC 6083. The major differences are: >>> * Use DTLS 1.3 instead of DTLS 1.0 >>> * Use key updates instead of renegotiation. This limits the number of >>> rekeyings to 2^64, but that should not limit in real world scenarios. >>> * Bump the maximum user message size to 64KB by using RFC 8449. >>> >>> Any comments welcome. >>> >>> Best regards >>> Michael
- [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Claudio Porfiri
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Claudio Porfiri
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Claudio Porfiri
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Claudio Porfiri
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Magnus Westerlund
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Magnus Westerlund
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Magnus Westerlund
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Magnus Westerlund
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Magnus Westerlund
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen
- Re: [tsvwg] DTLS 1.3 over SCTP Magnus Westerlund
- Re: [tsvwg] DTLS 1.3 over SCTP Michael Tuexen