[Tsv-art] Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11
Michael Scharf via Datatracker <noreply@ietf.org> Wed, 29 January 2020 01:16 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A4D1200EF; Tue, 28 Jan 2020 17:16:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Michael Scharf via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: last-call@ietf.org, mmusic@ietf.org, draft-ietf-mmusic-t140-usage-data-channel.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.116.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Michael Scharf <michael.scharf@hs-esslingen.de>
Message-ID: <158026059575.4541.13882610914386065869@ietfa.amsl.com>
Date: Tue, 28 Jan 2020 17:16:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/M7R2IFf_tqQvdM7t4_Ub6m6ukwA>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2020 01:16:36 -0000
Reviewer: Michael Scharf Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This document specifies how a WebRTC data channel can transport ITU-T T.140 text conversation. Disclaimer: I am really not familiar with this area and this particular use case. For instance, I have never heard of ITU-T T.140 before reviewing this document. The draft is pretty short. In general, the basic protocol mechanisms are well described. However, the document is rather vague when it comes to some details. Thus, I have some comments (well, actually questions). Maybe some of this is obvious to the domain experts - but not to me. 1/ I wonder why Section 4.2.1 does not include any normative statements on how to handle the maximum character transmission rate ('cps' attribute). RFC 4103 states that "In receipt of this parameter, devices MUST adhere to the request by transmitting characters at a rate at or below the specified <integer> value." Isn't a similar statement needed in this document? 2/ Also, it is not really clear from the document what would happen if a peer exceeds this maximum character transmission rate (or the rate allowed by congestion/flow control). What happens if the sender types faster than the 'cps' attribute (say, an automated chat bot)? I guess characters would be dropped at the sender? In that case, no missing text markers would be displayed in the receiver, right? 3/ Section 5.3. "Data Buffering" includes the following statement: "As described in [T140], buffering can be used to reduce overhead, with the maximum buffering time being 500 ms. It can also be used for staying within the maximum character transmission rate (Section 4.2), if such has been provided by the peer." I don't understand the second sentence. At first sight, enforcing the 'cps' attribute does not only require a buffer, but also some sort of rate shaper/policer (e.g., token bucket or the like). Do I miss something? 4/ Also in Section 5.3 is written: "An implementation needs to take the user requirements for smooth flow and low latency in real-time text conversation into consideration when assigning a buffer time. It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103], or lower, for T.140 data channels". What is meant here by "or lower"? Does the document want to recommend values much smaller than 300 ms, say, 1 ms? As explained in RFC 4103, this could increase the overhead and bitrate, right? The absolute rate values are relatively small for large parts of today's Internet, but couldn't this text conversation be particularly useful in scenarios with very small capacity of links (i.e., kbps range)? 5/ Section 5.4 mandates: "Retransmission of already successfully transmitted T140blocks MUST be avoided, and missing text markers [T140ad1] SHOULD be inserted in the received data stream where loss is detected or suspected." I believe a better wording for the MUST would be "... sucessfully received T140blocks ...", albeit the document does not detail how an implementation can indeed fulfill this MUST. Regarding the SHOULD, I assume that "loss suspected" could be deterrmined by a heuristic. Could such a heuristic fail and result in spurious missing text markers? If so, would a SHOULD be reasonable for that? I don't know whether interoperable running code would need a specification with that level of detail. Thus, I flag these questions only as "nits".
- [Tsv-art] Tsvart last call review of draft-ietf-m… Michael Scharf via Datatracker
- Re: [Tsv-art] Tsvart last call review of draft-ie… Christer Holmberg
- Re: [Tsv-art] Tsvart last call review of draft-ie… Gunnar Hellström
- Re: [Tsv-art] Tsvart last call review of draft-ie… Scharf, Michael
- Re: [Tsv-art] Tsvart last call review of draft-ie… Christer Holmberg
- Re: [Tsv-art] Tsvart last call review of draft-ie… Scharf, Michael
- Re: [Tsv-art] Tsvart last call review of draft-ie… Christer Holmberg
- Re: [Tsv-art] Tsvart last call review of draft-ie… Gunnar Hellström
- Re: [Tsv-art] Tsvart last call review of draft-ie… Christer Holmberg
- Re: [Tsv-art] Tsvart last call review of draft-ie… Scharf, Michael
- Re: [Tsv-art] Tsvart last call review of draft-ie… Gunnar Hellström
- Re: [Tsv-art] Tsvart last call review of draft-ie… Christer Holmberg
- Re: [Tsv-art] Tsvart last call review of draft-ie… Gunnar Hellström
- Re: [Tsv-art] Tsvart last call review of draft-ie… Christer Holmberg
- Re: [Tsv-art] Tsvart last call review of draft-ie… Gunnar Hellström
- Re: [Tsv-art] Tsvart last call review of draft-ie… Scharf, Michael
- Re: [Tsv-art] Tsvart last call review of draft-ie… Christer Holmberg