[tsvwg] Two comments about removing the 16 kB limitation in draft-ietf-tsvwg-dtls-over-sctp-bis-02
li.yan18@zte.com.cn Tue, 11 January 2022 02:11 UTC
Return-Path: <li.yan18@zte.com.cn>
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 A81B43A0C18 for <tsvwg@ietfa.amsl.com>; Mon, 10 Jan 2022 18:11:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vj81q4lqEEym for <tsvwg@ietfa.amsl.com>; Mon, 10 Jan 2022 18:11:43 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6823A0C0D for <tsvwg@ietf.org>; Mon, 10 Jan 2022 18:11:42 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4JXvMJ61QGz815Mf; Tue, 11 Jan 2022 10:11:40 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 20B2BA3c008424; Tue, 11 Jan 2022 10:11:11 +0800 (GMT-8) (envelope-from li.yan18@zte.com.cn)
Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid202; Tue, 11 Jan 2022 10:11:10 +0800 (CST)
Date: Tue, 11 Jan 2022 10:11:10 +0800
X-Zmail-TransId: 2afd61dce73e53a7cec3
X-Mailer: Zmail v1.0
Message-ID: <202201111011108579872@zte.com.cn>
Mime-Version: 1.0
From: li.yan18@zte.com.cn
To: claudio.porfiri@ericsson.com, magnus.westerlund@ericsson.com, john.mattsson@ericsson.com, tsvwg@ietf.org
Cc: zhou.xingyue@zte.com.cn, deng.zhiren@zte.com.cn, li.meng5@zte.com.cn, ma.jun3@zte.com.cn, li.yan18@zte.com.cn
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 20B2BA3c008424
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.138.novalocal with ID 61DCE75C.001 by FangMail milter!
X-FangMail-Envelope: 1641867100/4JXvMJ61QGz815Mf/61DCE75C.001/10.30.14.238/[10.30.14.238]/mse-fl1.zte.com.cn/<li.yan18@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 61DCE75C.001/4JXvMJ61QGz815Mf
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/EwRYWKO3ORz6n7qK-gmrIGlvQUc>
Subject: [tsvwg] Two comments about removing the 16 kB limitation in draft-ietf-tsvwg-dtls-over-sctp-bis-02
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 11 Jan 2022 02:11:48 -0000
Dear tsvwg members, Happy new year! About the current version of draft-ietf-tsvwg-dtls-over-sctp-bis-02, ZTE has two comments as below: 1. Supplementary Note on Fragment reassembly It is better to add more description in section 4.1 in the current draft. The description about how to reassemble the fragemented user message in the DTLS layer is not clear enough, and may cause confusion for readers.It is recommended to add further description about it. For example: On the receiving side, after getting the user_message’ from SCTP, DTLS makes use of the length field in the DTLS record header to decrypt the content of the first DTLS record to get m0, then m1...... The length field in DTLS record header is very import for decryption of each DTLS record.According to the length field, the receiving side knows the end of decryption of one DTLS record and the start of the next DTLS record. Detemining which DTLS record is the last one needs to use the overall length of the user_message’ from SCTP to minus the lenght of each DTLS record. After the last DTLS record is decrypted, the user_message is reassembled: user_message = m0 | m1 | m2...... 2. Consideration of backward compatibility The issue of backward compatibility needs to be considered, for example,if the server side supports DTLS without user message size limitation, while the client has message size limitation, packet loss may occur on the client side. Therefore, a mechanism is needed to identify whether the peer has the requirement of user message size limitation. More details welcome further discussion. Yan Li Kind Regards, 李燕 LiYan RAN产品经营团队/无线规划部/无线产品经营部 RAN Product Operation Team/Wireless Product Planning Dept./Wireless Product Operation Division 南京市雨花台区软件大道50号 中兴通讯南京二区 1号楼 No.50 Software Avenue,Yuhuatai District, Nanjing, P.R.China, 210012 M: +86 13913811347 E: li.yan18@zte.com.cn www.zte.com.cn
- [tsvwg] Two comments about removing the 16 kB lim… li.yan18
- Re: [tsvwg] Two comments about removing the 16 kB… Magnus Westerlund
- Re: [tsvwg] Two comments about removing the 16 kB… li.yan18