Re: [Tsv-art] Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Wed, 29 January 2020 21:59 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752A1120026; Wed, 29 Jan 2020 13:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de
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 ujvPz7kIESYF; Wed, 29 Jan 2020 13:59:02 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174A3120047; Wed, 29 Jan 2020 13:59:01 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 33D1125A1A; Wed, 29 Jan 2020 22:58:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1580335139; bh=UfH9uGFUJdyMratkCKhXCOAWUrjfBrpklqx65UqN6OM=; h=From:To:CC:Subject:Date:From; b=pkpX2JXYxCw9Y5/Ol7LOfQGX9kxhr0l/GifjMJjxSZnzgMZ8d6/WT7ZknIpUQ+KRh 4M/fd+mK5Srt+zs35nNvPIVcnOD7kWRWOipNbxwBr/nioEtHsJ4x1f1CdOuw8KFuZk Hqox4selWRb68fEObjVf7Zq3ROZYS8opY3QZvwtU=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id va9LBh7w02Pc; Wed, 29 Jan 2020 22:58:57 +0100 (CET)
Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 29 Jan 2020 22:58:57 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.158]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Wed, 29 Jan 2020 22:58:56 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Gunnar Hellström <gunnar.hellstrom@omnitor.se>, Christer Holmberg <christer.holmberg@ericsson.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "draft-ietf-mmusic-t140-usage-data-channel.all@ietf.org" <draft-ietf-mmusic-t140-usage-data-channel.all@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11
Thread-Index: AdXW702AgJKk97+8PEGjxavEbNwM2w==
Content-Class: urn:content-classes:message
Date: Wed, 29 Jan 2020 21:58:56 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D8FB09C@rznt8114.rznt.rzdir.fht-esslingen.de>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D8FB09Crznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/e6FI4vG2fiW4o5QU8TS4UV7q3Yw>
Subject: Re: [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
Precedence: list
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 21:59:15 -0000

Hi all,

see below inline [MS].

Michael


Von: Gunnar Hellström<mailto:gunnar.hellstrom@omnitor.se>
Gesendet: Mittwoch, 29. Januar 2020 17:30
An: Christer Holmberg<mailto:christer.holmberg@ericsson.com>; Scharf, Michael<mailto:Michael.Scharf@hs-esslingen.de>; tsv-art@ietf.org<mailto:tsv-art@ietf.org>
Cc: last-call@ietf.org<mailto:last-call@ietf.org>; mmusic@ietf.org<mailto:mmusic@ietf.org>; draft-ietf-mmusic-t140-usage-data-channel.all@ietf.org<mailto:draft-ietf-mmusic-t140-usage-data-channel.all@ietf.org>
Betreff: Re: Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11


Hi,

I will try to add to the answers,
Den 2020-01-29 kl. 07:05, skrev Christer Holmberg:

Hi Michael,



Thank you for review! Please see inline.



---



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



The assumption has been that the associated procedures in 4103 apply.
Note that section 6 in RFC 4103 continues:
"


Note that this parameter was not defined in RFC 2793<https://tools.ietf.org/html/rfc2793> [16<https://tools.ietf.org/html/rfc4103#ref-16>].

   Therefore implementations of the text/t140 format may be in use that

   do not recognize and act according to this parameter.  Therefore,

   receivers of text/t140 MUST be designed so they can handle temporary

   reception of characters at a higher rate than this parameter

   specifies.  As a result malfunction due to buffer overflow is avoided

   for text conversation with human input.

"



This note may be historic now, but for the T140-usage draft we may have the similar case when an implementation has not succeeded to implement support for the CPS parameter, or for dcsa at all.

[MS] I have also read that paragraph, but to me it sounded as a historic transition problem. Also, as far as I read this text in 4103, the MUST is only about the design of the implementation, not about its actual operation. For instance, receiption at a higher rate could be an optional feature turned off by default may not violate that MUST.

We had specific wording for that case earlier, but I think we deleted most of it.

Do you think we should insert a similar precaution in the t140-usage draft, but referring to other reasons than RFC 2793 interop?

[MS] I don’t understand why the draft specifies a parameter if implementations shall just ignore the value. I guess the actual use of this parameter could be better specified in the document.





But, I can for sure make it explicit, e.g., by adding the sentence from 4103 to the end of the 1st paragraph.



---



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



I assume it could result in a buffer overflow sooner or later, but I think it is a local implementation issue how it is dealt with by the sender application.



Perhaps Gunnar knows more about how implementations handle this?

What the CPS parameter tries to prevent is buffer overflow in slow ancient receiving devices.

Modern implementations will likely have buffer space enough for storing quite a large volume of text for eventual transmission to the limited device. It is instead another risk that appears. If you have a receiving device only able to present 4 characters per second which is the reality if you have interop with the old TTYs through a gateway, then a modern device user happening to paste a large piece of text or use speech to text technology will generate text in buffers that will take a very long time to present at the receiving device. The sense of a real-time conversation will be lost. (1000 characters will take 4 minutes to present!)

The users need to realize that this technology is intended for human conversation. It is wise if implementations have the possibility for pasting in short texts, but it should not be used for document transfer.

[MS] The document could better describe this, IMHO. As the data channel is different and has other capabilities, it is not clear to me that all limitations explained in RFC 4103 apply here as well.

So, yes, it is a local implementation issue.

[MS] From a transport protocol design perspective, the „cps“ parameter may realize some sort of (simple) flow control. And in that case sender and receiver typically have to agree on the semantics. And your example actually describes a typical flow control problem: If a 4 cps receiver receives 1000 characters, it may actually be interested in slowing down the sender. Could it do so, for instance, by sending cps=0? As far as I understand the I-D, this would be allowed. How to deal with that case is not a local implementation issue only. Well, we are here probably discussing corner cases of corner cases. But as far as I can see, the document does not comprehensively describe the use of the cps attribute.





---



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



The 2nd sentence talks about the case when the user input rate is faster than the maximum transmission rate (see question #2).
Yes, so in the second case, the transmission procedure will detect that not all buffered characters are allowed to be transmitted, when the transmission interval (normally 300 ms) has passed. So they will be kept in a buffer at the sending side. Is that unclear so we need to clarify it?

[MS] I had to partly reverse-engineer the handling of the buffer from RFC 4103, albeit it is not exactly clear if all considerations therein also apply to this specification. For instance, I believe that your additional explanation could be added to the document to better clarify the intention. And just to illusttrate that there could be more ambiguity: To me, Section 5.3 could also imply that characters queued in the sender are dropped from the buffer if they cannot be transmitted within 500ms. That is a relatively small threshold for links with RTT of 200ms or more (e.g., satellite or slow GPRS links), e.g. if retransmissions are needed due to packet loss or congestion/flow control kicks in. Unlike RFC 4103, transport is now reliable and this could have some side effects even if the data rates in text conversations are very small. Out of my head, I would assume that a buffer threshold of 500ms will probably work very well in most parts of the Internet. But there are some areas with bad connectivity, high packet loss rates, etc. I am not sure of the proposed parameters really work well in such corner cases. Typically, such Questions would be answered by measurement data from running code.





---



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



I suggest to remove the "or lower" part, since the recommendation is to use 300.

Modern applications, especially speech-to-text are better at lower delays. So, having a 300 ms delay may be on the high side. Transmission intervals down to 100 ms will be experienced as an improvement for some applications. The load in both bandwidth and packets per second  is still low compared to what audio and video (often used in the same sessions) cause.

[MS] Indeed, bandwidth and packet rate will be small compared to other traffic. Nonetheless, this I-D somewhat specifies a service with real-time requirement that runs over a reliable transport channel, which could e.g. traverse highly congested links. Just assuming „the transport will just always work“ is a bit dangerous, IMHO.

It is a RECOMMENDATION,  so, yes, "or lower" could be deleted, but I prefer to leave it.

[MS] Maybe the document could write something like „It is RECOMMENDED to use the default transmission interval of 300 milliseconds [RFC4103] for T.140 data channels. Implementers MAY also use lower values". However, note that RFC 4103 backs the parameter of 300ms by estimating the overhead. If this document allows smaller values, it may have to similarly reason about the impact.





---



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



Regarding the MUST, T.140 does not provide acknowledgement that T140blocks have been received. It uses a reliable data channel, so as long as the data channel is up and running the sender can only assume that the blocks will be successfully transmitted.



Perhaps Gunnar knows more about how receiving implementations would "suspect" loss?

The requirement from the T.140 presentation level is that the channel shall deliver in order and without duplication. Possible loss should be indicated. For RFC 4103, there is a slight risk that packets are lost, and if more are lost than can be recovered by the redundancy, then a suspected loss has appeared and should be indicated in the text presentation. There is a chance that something invisible in the text stream was lost. We cannot know.

For the t140-usage case, the situation is different. We have reliable delivery in order as long as not more than about 7 retries are made and nothing is blocking transmission so that the watchdog breaks the SCTP associations. But that can happen and the draft says that reestablishment shall be tried. At that moment it may be hard to know from the sender side what was successfully transmitted, because we do not have any application level checking delivery. What must be avoided is to retransmit something that might have been received. It is better to let something be lost and insert an indication that something might have been lost.

[MS] I am not really familiar with internals of the SCTP stack. But to me there is ambiguity in the term „already sucessfully transmitted T140blocks“. What does that mean? That the T140block has been copied into the SCTP send buffer? Or that an IP packet containing this data has been transmitted to the peer? I think the former may not immediately imply the latter, what has exactly happened my be difficult to know. Maybe it would be safer to avoid the word „successfully transmitted“. For instance, „Retransmission of already sent T140blocks MUST be avoided“ may work around some of the terminology issues.

That is what the text tries to say.  It might be a good habit to always insert an indicator for suspected loss by the receiver, when the SCTP associations are refreshed. I think the current wording allows that and smarter solutions if possible. It is good to not require the transmitter to insert the loss marker, because that might make it harder to apply security to the transmission chain.

[MS] I was wondering if it is possible that the transmitter erroneously inserts a loss marker even if _no_ data was lost, because the receiver wrongly „suspected“ loss. As far as I understand, the ITU-T T.140 Addendum specifies the loss marker for „discovered data loss“. So, it is not clear to me if using this for _suspected_ loss would be consistent with the ITU-T T.140 Addendum (which I had to read to actually understand this I-D).

[MS] Anyway, I agree that the current specification allows „smarter“ solutions simply by omitting details on (well, granted) corner cases. The question is whether the current spec is precise enough to ensure interoperability between implementations and to fully describe the characteristics to potential users. I don’t understand this use case well enough and therefore I defer that question to the TSV ADs.

Best regards

Michael



Regards,



Christer



Regards

Gunnar



--



+ + + + + + + + + + + + + +



Gunnar Hellström

Omnitor

gunnar.hellstrom@omnitor.se<mailto:gunnar.hellstrom@omnitor.se>

+46 708 204 288