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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 02 February 2020 21:18 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 E4BB912013C; Sun, 2 Feb 2020 13:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.1
X-Spam-Level: ***
X-Spam-Status: No, score=3.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=omnitorab.onmicrosoft.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 tzny-HMwRoWw; Sun, 2 Feb 2020 13:18:47 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00102.outbound.protection.outlook.com [40.107.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF8A12003E; Sun, 2 Feb 2020 13:18:46 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FbKJRnYKhSKi5UQ8+5+VaDIZDU4yD592ziIaTj4UDDWbsiOVsInVwWxDIv3q3yCeU1tw8mFceqUH4qMVWVuZ6AdMyUKb+9HbQHzrT3s8GP+IOqpNV0i/MNKrrR1g6H5QsJCivyKgIqKa5ghLo1ji5L/pU0uJaoe934Fx1+pMUBrVFhh66XpiyeoQ63XT9R6mOycNAwSGcpzK+PGRz8935Z1hq7aUOSIvpHsvY/65kYfg8BEmgx1INYM/HDUv5NfTmk/GuPmd5rqNEVYpiRvU7ng4OOV93SHFiCOeNZWQc7LgU4Qmc3/5hcvZcylyV3ogv+ZEGOJoGvgHRW4LssKw6A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ryxUgrDorg9p9rUCQd+pl+bw9npWtyp7quhi+1f4A9U=; b=DR8W/U6OCU3YVsCYEjTAWUdnMAtuhdzbHDPGrFDr2UA35cV6cOLAwBQcbTicGY5+6O9rRajhPILZM/a1ZpkwdiaJCzQYP96iIW/hOGYCSix93ro6640AIHmtB94JGfOVndV0s6bqrD6gNQExhm8wQh/HyRb0H2o6CiPd4juh5h4xYPm8+tHOO4OuAZYodznaFObglNq+3WLgO9rkE/5z8XIsaCbiIh7C6SnxVNDc/M6bANSEsGvd/1vuNAp6nO7edtJ3kLdp9L9Y+GhNsWkOcLREs5/r5TvMIKRznvojZjrCLH618l7TXM7iZJWmxsVPGIOV+dd4qEFvz9RpTXhVCw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ryxUgrDorg9p9rUCQd+pl+bw9npWtyp7quhi+1f4A9U=; b=XPxeAIKTqoM3nhkItxxvJKScDAu+4l//Kmw7YQpjZ0UmtItTYDpqzPbVcLsD1iWkxzXKviJ9nHPHGaYyq/nP/cCSdb0XV1hqb5POAcElzGBhJU5sCU6DpXlSoDGn12YtPKayrBk1S8rslqT49Hc8zqMFyxmaUaup83KNXu4iePY=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0605.EURP193.PROD.OUTLOOK.COM (10.186.176.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Sun, 2 Feb 2020 21:18:43 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1910:128d:b820:f765]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::1910:128d:b820:f765%4]) with mapi id 15.20.2686.031; Sun, 2 Feb 2020 21:18:43 +0000
Received: from [192.168.2.136] (77.53.230.59) by ZR0P278CA0036.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27 via Frontend Transport; Sun, 2 Feb 2020 21:18:42 +0000
From: =?utf-8?B?R3VubmFyIEhlbGxzdHLDtm0=?= <gunnar.hellstrom@omnitor.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "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+8PEGjxavEbNwM2wAdF9oAAAHPaDAABsgBAAABHo2AACn9soAAAshVsAAESF+AAGVLJwAAADt0gAAFN76AAAUnywA=
Date: Sun, 2 Feb 2020 21:18:43 +0000
Message-ID: <c4b71183-307a-975f-a6ee-a332f919e4fc@omnitor.se>
References: <6EC6417807D9754DA64F3087E2E2E03E2D8FB09C@rznt8114.rznt.rzdir.fht-esslingen.de> <1D07192D-90E3-4857-A44F-CCB2A4065E67@ericsson.com> <6EC6417807D9754DA64F3087E2E2E03E2D8FEAC8@rznt8114.rznt.rzdir.fht-esslingen.de> <4912DB9B-8404-4C86-9957-56AA5DFE539F@ericsson.com> <4b84568b-3525-d8e1-7b09-45dee8ac39f1@omnitor.se> <C7A0DD7E-51E2-4056-9AB7-7F636D33DB12@ericsson.com> <6EC6417807D9754DA64F3087E2E2E03E2D904618@rznt8114.rznt.rzdir.fht-esslingen.de> <50e5a0ad-f433-5df3-7225-592d3fcd2599@omnitor.se> <A959F700-4258-4319-B546-44BBE0877F86@ericsson.com> <6619bbfb-4674-caf3-9eae-3a96a4dba4a1@omnitor.se> <D934CACD-B720-4D6A-ACD9-A4314BE37FDD@ericsson.com>
In-Reply-To: <D934CACD-B720-4D6A-ACD9-A4314BE37FDD@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: ZR0P278CA0036.CHEP278.PROD.OUTLOOK.COM (2603:10a6:910:1c::23) To VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (2603:10a6:800:159::12)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [77.53.230.59]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 54e409bc-75bc-4440-936b-08d7a8257b18
x-ms-traffictypediagnostic: VI1P193MB0605:
x-microsoft-antispam-prvs: <VI1P193MB0605E4E64136690B105893B9FB010@VI1P193MB0605.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0301360BF5
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(396003)(376002)(136003)(346002)(189003)(199004)(52116002)(54906003)(6486002)(4326008)(956004)(66446008)(64756008)(66556008)(66476007)(66946007)(2616005)(86362001)(8936002)(31696002)(2906002)(110136005)(316002)(66574012)(16576012)(36756003)(16526019)(186003)(5660300002)(31686004)(8676002)(81156014)(81166006)(26005)(30864003)(85202003)(85182001)(508600001)(966005)(71200400001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0605; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zjmITshp6KtEQYmOeqd6BrnToZhfodvpnEZWT+ZjyS6BcGEnfzjn2xU0eTmz1xW44wwVKj56MUAAVEfs+vTCERvCf7ql2vqX7wTGsv/gF0r1dctpc44O+C2VYl3bNiLj/xACleZjImFig+M7A3ayUZKSNl7BzqPYc/9yFcFfVvIvmMg2JZMli38JeYOayFnf5PxbV7BjxDprERwMcHPl/3aIeJoMP7iu1PE4FKlokEHMKQmGDaB50+aCjDN7SJlQMH6+pWgzUVJVPXD5e3Y9D4eCdjyx8KVqIcRNp/Yg/C3bZSSvN1bAxIzCyBBl2Jzw9wEuBT8qDJ/WBlp0yowRyy2FGioeyrqb9yd9AB+NemJgLCwb3FG4lUY84hwW8ZcmNUHNHFHhRMQYzLdecwLwcXxzlMFa4xitStYpDz9O+A500uItTrBK5RW+QpCR6xO96XFG5m7gDGQHc8kl6wOP4wzBxL3xTHWKLyMfWTiqsQ3N8wLTk/AEj4eH4N6TUpyRcifiJ88+FF+eN+z/d/aq0g==
x-ms-exchange-antispam-messagedata: 8Ifujeg5N9jPFZa8fyM/rozfQMmPiWwuD2MemQukmwIDiYVY95Sm8p/tRf5/FulL6k466AQEaT+A9fLH4IF5EGXjgbCEdVf0kYhGspTudh4ag99L1rzykfJ6sRLzkcSHjfth+l2wCs3xAulO8AR1fA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <9357F6E9CF75C346B8AF717D4C3DA1C0@EURP193.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 54e409bc-75bc-4440-936b-08d7a8257b18
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2020 21:18:43.1426 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Dk0sCsV8y8hdCd9duUMmHRBILwWOaMPetF3LuhtpupsZy4f34kCaIsvzbAFvQ5DbFZIE9jlUzO3qYj/DZwGRcM3jojtrjUL6DZpl7uM5UhI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0605
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/xVTUFIVaOMTBwbXIff95HfgTLuA>
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: Sun, 02 Feb 2020 21:18:50 -0000

Hi,

I am fine with all Christer's conclusions and proposals below.

Gunnar

Den 2020-02-02 kl. 17:51, skrev Christer Holmberg:
> Hi,
>     
>   ---
>     
>      1/
>            
>      ...
>            
>      >      >>>>>> In any case, I don't think this is a real-life problem - in cases where T.140
>      >      >> is
>      >      >>>>>> used as intended. As Gunner mentioned, T.140 is not designed or intended
>      >      >> for
>      >      >>>>>> transport of large amount of copy-pasted text but for human interactions.
>      >      >>>>> Then probably a big warning sign should be added to the document.
>      >      >>>>>
>      >      >>>> We do reference T.140, and I assume the scope and usage are described
>      >      >> there. RFC 4103 does not have such statement either.
>      >      >>>> But, sure, if people think it is useful we can add a note saying that T.140 is
>      >      >> intended for real-time interaction, not for transfer of text files, documents etc.
>      >      >>> [GH] RFC 4103, has the following wording in its introduction:
>      >      >>>
>      >      >>>       "The text is intended to be entered by human users from a keyboard,
>      >      >>>         handwriting recognition, voice recognition or any other input method.
>      >      >>>         The rate of character entry is usually at a level of a few characters
>      >      >>>         per second or less."
>      >      >>>
>      >      >>> I suggest that the first sentence is added to our introduction.
>      >      >> [CH] I suggest adding both sentences.
>      >      >
>      >      > Regarding the congestion control impact, both sentences provide useful information. With the second sentence it is easier to understand
>      >      > how low the data rate will be (and that it will not cause much issues in many parts of the Internet).
>      >      >
>      >      > [GH] Yes, possible. I hesitated to propose adding both because of the
>      >      > expression "a few", considering that with speech-to-text and a rapid
>      >      > speaker, text production can reach about 20 CPS. But the sentence says
>      >      > "usually", so I can accept that both are added.
>      >
>      > Good.
>      >
>      > So, the current suggestion for addressing the issue: add the RFC 4103 sentence (see above) to the draft.
>
> No change to suggestion above.
>
>   -----
>           
>      2/
>            
>      ...
>            
>      >      >>
>      >      >> [CH]  Just to keep everyone in sync, the current proposal is to add some text
>      >      >> like:
>      >      >>
>      >      >>                    "If the receiver receives text at a higher rate than it can handle,
>      >      >> e.g.,
>      >      >>                      because the sender does not support the cps parameter, the
>      >      >> receiver
>      >      >>                      can indicate to the sender that it is not willing to receive more text
>      >      >> using
>      >      >>                      the direction attributes [ref-to-section-4.2.3]"
>      >      >>
>      >      >> I guess we could also say that the receiver might choose to close the T.140 data
>      >      >> channel.
>      >      >>
>      >      >>                    "If the receiver receives text at a higher rate than it can handle,
>      >      >> e.g.,
>      >      >>                      because the sender does not support the cps parameter, the
>      >      >> receiver
>      >      >>                      can either close the T.140 data channel, or maintain the data
>      >      >> channel but
>      >      >>                      indicate to the sender that it is not willing to receive more text
>      >      >> using
>      >      >>                      the direction attributes [ref-to-section-4.2.3]"
>      >      > That would work for me.
>      >      >
>      >      > The receiver could IMHO also just use SCTP flow control to slow down the sender. If the receiver only reads data from the SCTP
>      >      > receive buffer with rate cps, the sender will not be able to transmit faster than cps once SCTP flow control kicks in and the  SCTP send
>      >      > buffer fills up. A similar effect will happen if the network is very slow and cannot deliver the data rate needed to deliver cps (which is
>      >      > most likely a rare event in today's Internet for these low bit rates, but clearly it can happen in corner cases). In those cases, it could be
>      >      > beneficial not to have huge send buffers inside SCTP as data can get queued there, too.
>      >      >
>      >      > Maybe it would make sense to add a heads-up in the document to take into account potential buffering inside SCTP when sizing buffers.
>      >      >
>      >      > [GH] I don't like the text about closing the channel. Using SCTP flow
>      >      > control sounds better if that is an available action from WebRTC
>      >      > applications. Real-time text transmission needs to be equally robust as
>      >      > audio and video transmission, because it is used as an alternative to
>      >      > these media. Therefore we should not attract implementors to ideas of
>      >      > reducing its robustness. Saying that, I realize that it could instead
>      >      > build up huge queues of text, or cause receiver buffer overflow so that
>      >      > text will be lost. But that is better handled by user decisions about
>      >      > what to do with the call.
>      >
>      >  First, it is NOT within the scope of this document to define how to implement flow control on WebRTC data channels.
>      > I know that it has been discussed in the WebRTC community, and a quick search gave me this:
>      >
>      > https://github.com/pion/webrtc/tree/master/examples/data-channels-flow-control
>      >
>      > Second, as I indicated earlier, I really don't think data channel overloading is going to be a problem with T.140. If people
>      > try to use it for non-intended things (file transfer etc), and it doesn't work, it is not up to this spec to fix it.
>      >
>      > Having said that, we can of course indicate that if a flow control mechanism will be available in the future, the receiver can
>      > use that. Something like:
>      >
>      >           "If the receiver receives text at a higher rate than it can handle, e.g.,
>      >             because the sender does not support the cps parameter, the receiver
>      >             indicate to the sender that it is not willing to receive more text at the moment,
>      >             using the direction attributes [ref-to-section-4.2.3]. If that does not help, the
>      >             receiver can close the T.140 data channel."
>      >
>      >             NOTE: At the time of writing this specification, a flow control mechanism for WebRTC data channels
>      >            had not been standardized. Should such be available at some point, the receiver might use it in order
>      >            to slow down the rate of text received from the sender."
>      >
>      >[GH]
>      > a)On the third line, did you mean "can indicate" or "indicates" ? I prefer "can indicate" slightly.
>      > b)I dont like the sentence about closing the channel. Please delete. This is just an example of implementor's actions. It
>      > might be better to discard chunks of received text and replace it with one mark for missing text.
>      > c)The note is good
>
> New try:
>
>                    "If the receiver receives text at a higher rate than it can handle, e.g.,
>                    because the sender does not support the cps parameter, the receiver
>                    can indicate to the sender that it is not willing to receive more text at the moment
>                    by using the direction attributes [ref-to-section-4.2.3].
>       
>                    NOTE: At the time of writing this specification, a flow control mechanism for WebRTC data channels
>                   had not been standardized. Should such be available at some point, the receiver might use it in order
>                   to slow down the rate of text received from the sender."
>      
>      ---
>           
>      3/
>            
>      ...
>            
>      >      >>     > So, in order to sort out the text and explain the two different ways to use
>      >      >> the transmission buffer I suggest the following wording for 5.3:
>      >      >>     >
>      >      >>     > OLD 5.3:
>      >      >>     >
>      >      >>     >       "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.
>      >      >>     >         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."
>      >      >>     >
>      >      >>     > NEW:
>      >      >>     >
>      >      >>     >       "As described in [T140], buffering can be used to reduce overhead, with
>      >      >> the maximum transmission interval as long as there is text to send being 500
>      >      >> ms.
>      >      >>     >        Buffering can also be used for staying within the maximum character
>      >      >> transmission rate (Section 4.2.1).
>      >      >>     >
>      >      >>     >       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], for T.140 data channels. Implementers
>      >      >> MAY also use
>      >      >>     >      lower values, for specific applications requiring low latency, taking the
>      >      >> increased overhead in consideration."
>      >      >>     >
>      >      >>     > Note that I added more wording about the lower transmission interval. I got
>      >      >> the impression that that was desired as discussed below.
>      >      >>
>      >      >> [CH]  I am fine with your suggested new text, but it does not address the case
>      >      >> when the interval exceeds 500 ms (e.g., because the sender is about to exceed
>      >      >> the cps value).
>      >      > The proposed text is better than the original wording.
>      >      >
>      >      > As already mentioned, there would (or at least could) be two buffers in the sender:
>      >      > * A buffer in the T.140 message processing (at application level), from which data is handed over to SCTP
>      >      > * A send buffer inside the SCTP stack used e.g. for retransmissions
>      >      >
>      >      > The maximum amount of data that can be queued in the sender is the sum of both buffers. In contrast, as far as I
>      >      > understand, an RFC4103 implementation conceptually may only have one buffer. So, here the different transports
>      >      > actually matter.
>      >      >
>      >      > My understanding is that the "buffer time" would _only_ include the application-level buffer. In that case, it could be useful
>      >      > to mention that addition queuing inside the transport protocol implementation is possible and should be taken into account
>      >      > when setting values.
>      >      >
>      >      > [GH] To [CH]: Deletion of the term "500 ms maximum buffering time" and
>      >      > replacing it with a "maximum transmission interval of 500 ms" was
>      >      > intended to show that some characters might stay in buffers longer than
>      >      > 500 ms if production is more rapid than the CPS, but that transmission
>      >      > is continued at every transmission interval with the number of
>      >      > characters allowed within the CPS mean value, but possibly leaving some
>      >      > characters in the buffer until next interval. The wording "500 ms
>      >      > maximum buffering time" was misleading. Woops, I realize that the text
>      >      > proposal still contains one "maximum buffering time". Can you please
>      >      > replace that also with "transmission interval". Can you after that
>      >      > change still read it as if a solution would be to temporarily increase
>      >      > the transmission interval if the CPS value is reached?
>      >
>      > First, I did not find the remaining "maximum buffering time".
>      >
>      > Send, based on your suggestion, the end of the first sentence now sounds strange.
>      >
>      >          "As described in [T140], buffering can be used to reduce overhead, with
>      >           the maximum transmission interval as long as there is text to send being 500
>      >           ms."
>      >
>      > Third, doesn't T.140 specify that the max buffering time is 500 ms? We shouldn't change that.
>      >
>      > [GH]  New proposal with the last remaining "buffer time" also replaced:
>      >
>      > NEW
>      >
>      >     "As described in [T140], buffering can be used to reduce overhead, with
>      >     the maximum assigned transmission interval of T140blocks from the buffer
>      >     being 500 ms as long as there is text to send.
>      >
>      >     Buffering can also be used for staying within the maximum character
>      >     transmission rate (Section 4.2.1).
>      >
>      >     An implementation needs to take the user requirements for smooth
>      >     flow and low latency in real-time text conversation into consideration when
>      >     assigning a transmission interval. It is RECOMMENDED to use the default transmission
>      >     interval of 300 milliseconds [RFC4103], for T.140 data channels. Implementers
>      >     MAY also use lower values, for specific applications requiring low latency, taking the
>      >     increased overhead in consideration."
>
> Looks ok. I suggest to go with that.
>
>      ---
>      
>      4/
>            
>      >      >>      >>>  [CH] I guess it depends on whether the recommendation is to
>      >      >> specifically use
>      >      >>      >>> 300ms, or whether the recommendation is to use 300 or lower. RFC
>      >      >> 4103 talks
>      >      >>      >>> about specifically using 300ms, so I think we should follow that for T.140
>      >      >> data
>      >      >>      >>> channels. So, I am fine with the text you suggest.
>      >      >>      >>>
>      >      >>      >> OK, then we may have sorted this out
>      >      >>      >>
>      >      >>      > [GH] See my proposal for  5.3 above
>      >      >>
>      >      >> [CH] For synch purpose, no actions for this issue is currently identified, as it is
>      >      >> covered by the suggested way to address issue 3/
>      >
>      >      Still no action for this issue.
>
>      Still no action.
>
>      ---
>           
>      5/
>           
>      ...
>      >
>      >      >>      >>
>      >      >>      > GH] I suggest slight modifications
>      >      >>      >
>      >      >>      >  NEW2
>      >      >>      >      "In case of network failure or congestion, T.140 data channels might
>      >      >>      >       fail and get torn down.  If this happens but the session sustains, it
>      >      >>      >       is RECOMMENDED that implementations tries to reestablish the T.140
>      >      >>      >       data channels. As a T.140 data channel does not provide a mechanism
>      >      >>      >       for the receiver to identify retransmitted T140blocks after channel
>      >      >> reestablishment, the sender MUST
>      >      >>      >       NOT retransmit T140blocks unless it has strong indications that a
>      >      >> T140block has been lost. Similarly, as a T.140
>      >      >>      >       data channel does not provide a mechanism for a receiver to detect
>      >      >> lost T140blocks during channel reestablishment, it
>      >      >>      >       SHOULD NOT insert missing text markers [T140ad1] unless it has
>      >      >> reasons to suspect that a T140block might have been lost.
>      >      >>      >       Different mechanisms used by senders and receivers to detect or
>      >      >> suspect packet loss are outside the scope of this specification."
>      >      >>      >
>      >      >>      > Regarding the change for the receiving side, it is better to insert a loss
>      >      >> mark too much than omitting one.
>      >      >>
>      >      >>       [CH]  Ok. However, I think we could use "MUST NOT insert missing text
>      >      >> markers unless it has reasons to suspect".
>      >      >>
>      >      >>      Because, why would the receiver insert a missing text marker if it does not
>      >      >> suspect that a T140block has been lost?
>      >      > Both variants work for me. At the end of the day, this is mostly about the question what
>      >      > service is delivered to the user.
>      >      >
>      >      > [GH] Yes, I can accept your wording[CH] for the second part of the text.
>      >
>      >      Ok, so the current suggestion is to add the following text:
>      >
>      >     "In case of network failure or congestion, T.140 data channels might
>      >       fail and get torn down.  If this happens but the session sustains, it
>      >       is RECOMMENDED that implementations tries to reestablish the T.140
>      >       data channels. As a T.140 data channel does not provide a mechanism
>      >       for the receiver to identify retransmitted T140blocks after channel
>      >       reestablishment, the sender MUST NOT retransmit T140blocks unless
>      >       it has strong indications that a T140block has been lost. Similarly, as a T.140
>      >       data channel does not provide a mechanism for a receiver to detect
>      >       lost T140blocks during channel reestablishment, it MUST NOT insert missing
>      >       text markers [T140ad1] unless it has reasons to suspect that a T140block might
>      >       have been lost. Different mechanisms used by senders and receivers to detect or
>      >       suspect packet loss are outside the scope of this specification."
>      >
>      > ---
>      > [GH]A small correction: on third line, it should read "implementations try"
>
>      Current suggestion is to add the text above, with the change suggested by Gunnar.
>
> Regards,
>
> Christer
>
-- 

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

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288