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

Christer Holmberg <> Wed, 29 January 2020 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF130120810; Tue, 28 Jan 2020 22:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KwvSCgUaqxU8; Tue, 28 Jan 2020 22:05:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D5DA1200EF; Tue, 28 Jan 2020 22:05:49 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=nu0C9Y+h3Ko6ct/jPmijmDIkZXc9guSwOwF+zy8Qlrgiap6un0lYfUrODVnvJVpFKNaj2rxUxIavQYtwXJ9yY4fHQpDJkx9khLgHJi5Ar3KYQBkcVpCH6MkdIKp0pTP61YeadrafklSqswwV3pyQrauzBPSITG3oaKHonbTcTJUnEgbRayWEFtU7btMmWeZLK9uYxu4Y7yxD/UI0mTa1v4UAd3rXJdRSFfykJsHnuyKWew4Wgpoj9yBkCWEjiw4YmQDre3l6+hzJlxQRdAHnn9lEo8G7HZ3J+g+4ZuoXftbAaFZ+GxDIwWECNbMk89Mxa8/TbcqBe4aT+Tt0//y/Aw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7O/gKdyUryipqTYbA5fxqmiQycUeQ5JjjVejljmaYpA=; b=TzxR3iH8brk3j00R4nkhCZcAoaUu36Jym7/Vft26ETUSDvbnheWIgXPLWGYyfCJ7+5Olp/qBKoqYem+WurqRtWtZLFDTaYEysuBQEjIxsUHbLMmnzKWsmOCnzey2hiY0jiGpOMV32OVXxllt7ZBQRhWubS4qhue19x+uEgphHG+pvfzbGykZL70AJ+LDqjnoacukUOqWZKlrCX6rEXBMB7x7ZlVkMjqjF+DusOJc5B5ZPcm1WyZLU1UI++Wt1QuiBHtzz/eIU5XsWoP7DuQuF4BMQPgI6UfVrJx45Uubbklvn+OflNrLWqDpSPeTWW7gT5FmerMdXvdr6F2xXM90Kw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7O/gKdyUryipqTYbA5fxqmiQycUeQ5JjjVejljmaYpA=; b=IR1wdIQQpW2eWHvGEVRwxXTsC3DeFd41tNHQqlvIqTz7fEyjpYSag1jz3xMRrKAPFQNH81oHJtjzU57KrMdfZ92pmM/RtfUID4WBMp3ss10BgzWl9wU2nhoKXb0zt5Y8kzOsYoa0pR9FeVRrd3/HznSj3dKorDXVxmuBzj7wJMc=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.18; Wed, 29 Jan 2020 06:05:47 +0000
Received: from ([fe80::f13d:8825:4c6b:600f]) by ([fe80::f13d:8825:4c6b:600f%4]) with mapi id 15.20.2686.019; Wed, 29 Jan 2020 06:05:47 +0000
From: Christer Holmberg <>
To: Michael Scharf <>, "" <>, Gunnar Hellstrom <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11
Thread-Index: AQHV1kHDtmOQPS0AHEqkz1O0GS2056gBSU4A
Date: Wed, 29 Jan 2020 06:05:47 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 56609a11-9d3b-456b-4fc5-08d7a48148a3
x-ms-traffictypediagnostic: AM6PR07MB3975:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02973C87BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(39860400002)(366004)(396003)(199004)(189003)(4326008)(5660300002)(33656002)(86362001)(44832011)(71200400001)(66574012)(2616005)(6512007)(66476007)(54906003)(6506007)(66556008)(26005)(316002)(110136005)(6486002)(76116006)(91956017)(66446008)(66946007)(81166006)(36756003)(8936002)(81156014)(8676002)(2906002)(478600001)(186003)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB3975;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: L8RKRpJKhrrsDvqvK9Aw8sWLzqwARNSzw5o3uFnOV2MHi83lGWas9weTOTpT6CJxHSaN4scH7iwDSPqZbevwVKoZEWysDk0ZWc/8v/K7JjO5NJl6CzYnk3/sIxQeJ0ueaFWq4uY1CXxpktkLCH8G3bF88Mxp0P/Gg6n9bcuUZinHCHk2f+Gyxk8Z6pMOyk760qCKR/3AdvJDSerQHRMjmvZdfU9FcPFPZWlMbzA5sFB4a4HWUhb3XJ46oU2t+5+UW4cf2Joln8d4UGLfjLY8Mts3Nc149G/b1OgMhTy26R0KuV2+PDI4Qzg3rwLffNQUi68wPu86NBGaJsRxDWgh3sv6hJxgbmRscZh8LkF4iDpSXbk3f4D3O/TLU1pZntHYifke/a7lBEcwcVYZ3doTK7Kqa+pGh9BlIn5QgI/crNqqEz7I7UF0pD/+S0+doNi+
x-ms-exchange-antispam-messagedata: juccD6NshDFPGeZEFozgVt3NJAaJklFLJMG/rb1i6ttf3a5GPSQO7Jw+AvnGhYVaObUN6F6bwbJUkkkbEn5SuXaPyjewcKPeKRNQ1e5JAd3KXd5aCzTVRClpzRyjySCHbAF0sZsiEN9GfLTojTgBjQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 56609a11-9d3b-456b-4fc5-08d7a48148a3
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2020 06:05:47.1084 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +fCR10+Zjms2dG6glxPVJl36AGjiBhhplL15rgOoWX92RKaBhk4coCMIpT62jztZTKfElZ5LDd7PbrGW7Jqqnz7LKJzHaMkELCUWixcp+4M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB3975
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-mmusic-t140-usage-data-channel-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jan 2020 06:05:54 -0000

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.

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?

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

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


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