Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)

Martin Duke <martin.h.duke@gmail.com> Fri, 10 April 2020 15:55 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D3E3A0408; Fri, 10 Apr 2020 08:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EYmufRD8U7bh; Fri, 10 Apr 2020 08:55:12 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430203A03EF; Fri, 10 Apr 2020 08:55:12 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id y17so2144050iow.9; Fri, 10 Apr 2020 08:55:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tfmqqIZDQRolD3zbrw64eHUtf3Cx8s9Fl/h3yuLJRuA=; b=PT0agJkZ64WMgHmw9cd5KoLNZ884BxbNW+35PyuG498C9hD+zbu2Mj2Zani5+8rXqu fqj5AhiHKDD0xdZePWj575jJzMq3ydDNbvGgyPUZwQmuO32qTW0xxUEUKSIMcEJ09Hyf 0p479oN0+1sHvRRYgLalQGQMwuDqXaX/jCuYEvIBeqKmYpk5N0+yDiDi0a/ctiiMuZBI lAXcwXl8RxBepfsHkqz39JhoqKUMD5u8WA09se5v6lMnLyrQaDCM+elbkVs9mPzKbquz m1I9u3X9fHYYTW3IvYNqUN+aC9QcbPrbvq8r03cyBBx4TXEwnbfdreFxm73NoU6g/jqj QzPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tfmqqIZDQRolD3zbrw64eHUtf3Cx8s9Fl/h3yuLJRuA=; b=CuxvnK9M9cPNul6IYQls1QHY9QhIX1HwPSznLvthVs93Lo+zrGa5yISRZdlLd+jPq0 ItmZRSv/FhI/czMSbGmr4/M/kNEsIv1EucaNqLC20lbomNOtd7VvUMVuoj/HyVHW5eqb GbJmlx0TKM8EJ1IABMCxAnVc1wlFhLtZKosb/dDFHp3HGnOnhSMGceD9kbSkGCyLAJ0D B855AoiS1FD7wPLc+eaEIPYuqSbUuDc49QmSgsIaL2M09zA8gJTSH4B2sGUHG6sAZnIz EiV59JCfkxO8dBaXjh5zrjRT6qKcTszTKPW1iz/IRYgj6pOViO81V7B38QFixP97DShY cLTg==
X-Gm-Message-State: AGi0PuYfYhNPBhhOdMOOtgVnlHROfri2fsmx5cpPl3fRsgvl/sLy+2G2 HzBKwLg78EfMmo43NGvPhYO0XC32b8oPRnK2z4U=
X-Google-Smtp-Source: APiQypLIjNKicVkk1NUeb+hf8AsKY7rBxxnfZUDs4k3yug8oJctu2M6FrNNCGaZPoG/FsSpOM/sM8dj3nij3cdlq1yQ=
X-Received: by 2002:a05:6602:450:: with SMTP id e16mr4750496iov.163.1586534111247; Fri, 10 Apr 2020 08:55:11 -0700 (PDT)
MIME-Version: 1.0
References: <158604858069.27221.2642465321422680007@ietfa.amsl.com> <b37c846e-8b42-48e4-7ef1-a2e3a36600d4@omnitor.se> <CAM4esxTKhuzMis849yKSB5R2k4wys0MgKJEBK81k=XNde57aYQ@mail.gmail.com> <1d0c8c09-e7e6-2fd6-e8a5-32484e04b6f0@omnitor.se> <BCE384F9-E5EA-431B-997E-5B23B1698420@ericsson.com> <CAM4esxQDV8t=AqQ7vBUUSM4Z437kFNngq89kpcDMVC_dst-fhg@mail.gmail.com> <81D8AD0F-8FF8-4EE5-8E6D-B8E1BA3248D7@ericsson.com> <74d7659d-cda4-7d02-1eec-e2b1a708f3a1@omnitor.se> <F6264E03-1307-4BD1-BF67-DCF4C3165C86@ericsson.com> <a1d2dc71-0a76-087c-fbe0-495f2e1a85d2@omnitor.se> <AM0PR07MB3987421AF78431898190933C93C20@AM0PR07MB3987.eurprd07.prod.outlook.com> <CAM4esxTpc1TJKL63LCD=Du8r7FeCpo-rZAbt4xJo3fOAuhmEKQ@mail.gmail.com> <A2547E9C-393D-49D9-84AA-50BA6D17F9AB@ericsson.com> <34eff16c-f04c-717a-fce3-769aed94ee6d@omnitor.se> <1FEB489E-9907-4809-B113-E480A7DC61E0@ericsson.com> <0c19ce39-5dd8-a3bb-4812-cf443c59db3d@omnitor.se> <DB584476-4A35-4C3A-98C5-C0C09EC17784@ericsson.com> <CAM4esxRCV2WqWr3OmoNbYQjqdqTyMecaBGRBFMAptEB4CxX=Gg@mail.gmail.com> <3B0C9C82-3CA6-439E-BBA6-2480AACB715A@ericsson.com> <CAM4esxRRzAPQ1wY553JAOHaDVfyCSVdg30VeaLPBFsJKAMCLLw@mail.gmail.com> <326F734E-F042-4300-A821-1738CD50EE45@ericsson.com> <CAM4esxTrHM1SoVZk3WXqx6DJoTsWyi83KJM-GqfibpysFYVz-w@mail.gmail.com> <804BE4A5-E8EE-49FF-9369-4A816EF71A9F@ericsson.com> <CAM4esxQT+QYT3omJ5h9mSZQ=_9VhkqVpcXFDL_iK31OyEnfYUw@mail.gmail.com> <CAL0qLwZVO1K=0+Sjw3AO385trAHeO95-r6RQfrQTq3HMrpKQpQ@mail.gmail.com>
In-Reply-To: <CAL0qLwZVO1K=0+Sjw3AO385trAHeO95-r6RQfrQTq3HMrpKQpQ@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 10 Apr 2020 08:55:00 -0700
Message-ID: <CAM4esxSZ=_3GfvFUqCY+bFhVAvT7ZQe3+NV1fV4H+ssJqDYOjg@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, "draft-ietf-mmusic-t140-usage-data-channel@ietf.org" <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>, =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>, "fandreas@cisco.com" <fandreas@cisco.com>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000020022805a2f1c2fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/F7zNCddIErij8J63D2HrXp6ozMc>
Subject: Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 15:55:17 -0000

I updated it to make it clearer I consider it addressed.

On Fri, Apr 10, 2020 at 12:12 AM Murray S. Kucherawy <superuser@gmail.com>
wrote:

> Martin,
>
> You left this comment in the datatracker:
>
> Old comment:
> The Tsvarea review cites a few other places where the 2119 language is a little loose, e.g. MUSTs with vague and unenforceable criteria.
>
> Is that still the case?  I believe the authors felt they'd cleared all that up.
>
> -MSK
>
>
> On Thu, Apr 9, 2020 at 6:44 AM Martin Duke <martin.h.duke@gmail.com>
> wrote:
>
>> Thanks for your work on this. You've fully addressed my DISCUSS.
>>
>> On Thu, Apr 9, 2020, 06:37 Christer Holmberg <
>> christer.holmberg@ericsson.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> >Is that inconsistent with MAY?
>>>
>>>
>>>
>>> Perhaps not. I will change it to MAY.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 8, 2020, 23:17 Christer Holmberg <
>>> christer.holmberg@ericsson.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>> > The changes look good. One more thing. In 5.3:
>>>
>>> >
>>>
>>> > Buffering can also be used for staying within the maximum character
>>> transmission rate
>>>
>>> >
>>>
>>> > could we change this to either SHOULD or MAY (whichever you think is
>>> best)?
>>>
>>>
>>>
>>> I think I’d prefer to keep “can”. Because, it would also be handled
>>> e.g., on the application level.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 8, 2020 at 12:06 PM Christer Holmberg <
>>> christer.holmberg@ericsson.com> wrote:
>>>
>>> Hi Martin,
>>>
>>>
>>>
>>> >This is good, because it specifies what the receiver should do when the
>>> sender violates RFC 4103.
>>>
>>> >
>>>
>>> >There still isn't guidance on what senders should do, but IMO that is
>>> an RFC 4103 problem, not a problem with this draft.
>>>
>>> >
>>>
>>> >Can you summarize the total change you plan to make to the draft in
>>> response to my DISCUSS? There was a different thread about 5.3
>>>
>>> >that is related and I'd like to make sure they are addressed
>>> holistically.
>>>
>>>
>>>
>>> The changes based on your review can be seen in the following
>>> PullRequest commits:
>>>
>>>
>>>
>>>
>>> https://github.com/cdh4u/draft-datachannel-t140/pull/56/commits/432cc24a42cec7f084657738bd2b69a8c2f9d380
>>> <https://protect2.fireeye.com/v1/url?k=2b3d9cd7-77e995b1-2b3ddc4c-8610d8a762ca-7a63a12d6e3ecb7c&q=1&e=6c92bb4f-5cff-4c3f-a9cc-c62ea882de13&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F56%2Fcommits%2F432cc24a42cec7f084657738bd2b69a8c2f9d380>
>>> (“strong indication” issue)
>>>
>>>
>>>
>>>
>>> https://github.com/cdh4u/draft-datachannel-t140/pull/56/commits/90c6ff8625004262cce1a434a34b5dae03356932
>>> <https://protect2.fireeye.com/v1/url?k=05b7a05c-5963a93a-05b7e0c7-8610d8a762ca-a9aa36bfd80a5723&q=1&e=6c92bb4f-5cff-4c3f-a9cc-c62ea882de13&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-datachannel-t140%2Fpull%2F56%2Fcommits%2F90c6ff8625004262cce1a434a34b5dae03356932> (sendonly
>>> issue)
>>>
>>>
>>>
>>> (If you prefer me to write the changes in an e-mail reply I can do that.)
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
>>> *Date: *Tuesday, 7 April 2020 at 14.04
>>> *To: *Christer Holmberg <christer.holmberg@ericsson.com>om>, Martin Duke <
>>> martin.h.duke@gmail.com>
>>> *Cc: *"iesg@ietf.org" <iesg@ietf.org>rg>, "
>>> draft-ietf-mmusic-t140-usage-data-channel@ietf.org" <
>>> draft-ietf-mmusic-t140-usage-data-channel@ietf.org>gt;, Flemming Andreasen
>>> <fandreas@cisco.com>om>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>rg>,
>>> "mmusic@ietf.org" <mmusic@ietf.org>
>>> *Subject: *Re: [MMUSIC] Martin Duke's Discuss on
>>> draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
>>>
>>>
>>>
>>> Hi Christer,
>>>
>>> Den 2020-04-07 kl. 12:00, skrev Christer Holmberg:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Your suggestion looks good. I suggest to include it in the same
>>> paragraph, as it is an exemption to the SHOULD.
>>>
>>> Yes, looks good, and my intention was to have it in the same paragraph,
>>> it was only the separation of your text and my text in the mail
>>> presentation that prevented me from that.
>>>
>>>
>>>
>>> Something like:
>>>
>>>
>>>
>>>    If an endpoint receives text at a higher rate than it can handle,
>>>
>>>    e.g., because the sending endpoint does not support the 'cps'
>>>
>>>    attribute parameter, it SHOULD either indicate to the sending endpoint
>>>
>>>    that it is not willing to receive more text, using the direction
>>>
>>>    attributes (Section 4.2.3), or use a flow control mechanism to
>>>
>>>    reduce the rate. However, in certain applications, e.g. emergency
>>> services,
>>>    it is important to regain human interaction as soon as possible, and
>>> it might
>>>
>>>    therefor be more appropriate to simply discard the received overflow,
>>> insert a
>>>
>>>    mark for loss [T140ad1], and continue to process the received text as
>>> soon as possible.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>> Regards
>>>
>>> Gunnar
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
>>> <gunnar.hellstrom@omnitor.se>
>>> *Date: *Tuesday, 7 April 2020 at 12.49
>>> *To: *Christer Holmberg <christer.holmberg@ericsson.com>
>>> <christer.holmberg@ericsson.com>om>, Martin Duke <martin.h.duke@gmail.com>
>>> <martin.h.duke@gmail.com>
>>> *Cc: *"iesg@ietf.org" <iesg@ietf.org> <iesg@ietf.org> <iesg@ietf.org>rg>,
>>> "draft-ietf-mmusic-t140-usage-data-channel@ietf.org"
>>> <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>
>>> <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>
>>> <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>rg>, Flemming
>>> Andreasen <fandreas@cisco.com> <fandreas@cisco.com>om>,
>>> "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
>>> <mmusic-chairs@ietf.org> <mmusic-chairs@ietf..org>, "mmusic@ietf.org"
>>> <mmusic@ietf.org> <mmusic@ietf.org> <mmusic@ietf.org>
>>> *Subject: *Re: [MMUSIC] Martin Duke's Discuss on
>>> draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
>>>
>>>
>>>
>>> Hi,
>>>
>>> This looks reasonably good. But there are cases when it is important to
>>> regain the real-time human conversation as soon as possible, and therefore
>>> discard the overflow instead of turning off the flow by a "sendonly".
>>> Real-time text is e.g. used in emergency services, and it would be more
>>> dangerous to turn off incoming text for an unforseeable time than to throw
>>> away some text and continue the dialogue. The mark for lost text can be
>>> inserted in the received text as soon as there is room for it.
>>>
>>> Therefore, I have proposed an added sentence in the first paragraph.
>>>
>>> Den 2020-04-07 kl. 09:36, skrev Christer Holmberg:
>>>
>>> Hi,
>>>
>>>
>>>
>>> Ok, so a new suggestion. What about the following modified text in
>>> Section 4.2.1:
>>>
>>>
>>>
>>>    If an endpoint receives text at a higher rate than it can handle,
>>>
>>>    e.g., because the sending endpoint does not support the 'cps'
>>>
>>>    attribute parameter, it SHOULD either indicate to the sending endpoint
>>>
>>>    that it is not willing to receive more text, using the direction
>>>
>>>    attributes (Section 4.2.3), or use a flow control mechanism to
>>>
>>>    reduce the rate.
>>>
>>>    In certain applications, e.g. emergency services,
>>>    it is however of importance to regain human interaction as soon as
>>>    possible, and therefore be more appropriate to discard the received
>>> overflow,
>>>    insert a mark for loss [T140ad1] as soon as possible in the received
>>> stream,
>>>    and be prepared to continue real-time conversation.
>>>
>>>
>>>
>>>    NOTE: At the time of writing this specification, the standardized API
>>>
>>>    for WebRTC data channels does not support flow control.  Should such
>>>
>>>    be available at some point, a receiving endpoint might use it in
>>>
>>>    order to slow down the rate of text received from the sending
>>>
>>>    endpoint.
>>>
>>>
>>>
>>> The text explicitly distinguish between the usage of the direction
>>> attributes and a flow control mechanism.. The text is also “future proof”,
>>> as it describes the usage of a flow control mechanism as an alternative
>>> should such become available in the future.
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>> Regards
>>>
>>> Gunnar
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *Martin Duke <martin.h.duke@gmail.com> <martin.h.duke@gmail.com>
>>> *Date: *Tuesday, 7 April 2020 at 8.04
>>> *To: *Christer Holmberg <christer.holmberg@ericsson.com>
>>> <christer.holmberg@ericsson.com>
>>> *Cc: *Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
>>> <gunnar.hellstrom@omnitor.se>se>, "iesg@ietf.org" <iesg@ietf.org>
>>> <iesg@ietf.org> <iesg@ietf.org>rg>,
>>> "draft-ietf-mmusic-t140-usage-data-channel@ietf.org"
>>> <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>
>>> <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>
>>> <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>rg>, Flemming
>>> Andreasen <fandreas@cisco.com> <fandreas@cisco.com>om>,
>>> "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>
>>> <mmusic-chairs@ietf.org> <mmusic-chairs@ietf..org>, "mmusic@ietf.org"
>>> <mmusic@ietf.org> <mmusic@ietf.org> <mmusic@ietf.org>
>>> *Subject: *Re: [MMUSIC] Martin Duke's Discuss on
>>> draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
>>>
>>>
>>>
>>> If sendonly is not a tool to use here, then that removes part of the
>>> confusion.
>>>
>>>
>>>
>>> If section 4.2.1 had a few sentences about what senders MUST, SHOULD,
>>> and MAY do when the user exceeds the peer CPS, including dropping frames if
>>> need be, that would make things much clearer.
>>>
>>>
>>>
>>> On Mon, Apr 6, 2020 at 2:08 PM Christer Holmberg <
>>> christer.holmberg@ericsson.com> wrote:
>>>
>>> Hi,
>>>
>>>
>>>
>>>  >>>>> I gather that is the common use case of sendonly, but in this
>>> particular case we are changing the directionality of the data channel to
>>> prevent a buffer overflow.
>>>
>>>  >>>>>
>>>
>>>  >>>>> I have no strong opinion on the correct behavior here, but I
>>> think the buffering section should address it.
>>>
>>>  >>>>
>>>
>>>  >>>> Perhaps we could say that the application may buffer text for a
>>> while in case of sendonly. But, the sendonly could “go on forever”,
>>>
>>>  >>>> so we cannot require that the application will accept and buffer
>>> all text during that time.
>>>
>>>  >>>>
>>>
>>>  >>>> The other alternative would have been to define a new
>>> please-hold-for-a-few-seconds attribute, but that would have meant more
>>>
>>>  >>>> work. And, in practice I don’t think this will be a big problem.
>>> Sure, you could have someone copy-pasting a large bunch of text, that
>>>
>>>  >>>> would cause a sendonly,  but in my opinion that is the wrong usage
>>> of a RTT function.
>>>
>>>  >>> When I answered Martin that text queued for transmission is kept, I
>>> meant for the case of reaching the CPS limit.
>>>
>>>  >>>
>>>
>>>  >>> I do not think that the sendonly should cause text to be buffered.
>>> People will sort out the appearing situations. We can hope that a proper
>>>
>>>  >>> flow control function is eventually implemented for data channels.
>>>
>>>  >> Works for me. I do agree that sendonly is not a flow control
>>> mechanism (that has been discussed in the past, and we don't want to
>>> re-open that discussion).
>>>
>>>  >>
>>>
>>>  >> Now, Martin DID ask for something to be said.  So, should we in
>>> Section 5.3 explicitly say that a change of the direction does not require
>>> buffering?
>>>
>>>  >
>>>
>>>  > I think that the decision means that the paragraph about direction
>>>
>>>  > attribute in 4.2.1 should be moved to the end of 4.2.3.4 and be
>>> slightly
>>>
>>>  > reworded to:
>>>
>>>  >
>>>
>>>  > If for example an endpoint receives text at a higher rate than it can
>>>
>>>  > handle, the receiving endpoint can indicate to the sending endpoint
>>> that
>>>
>>>  > it is not willing to receive more text, using the direction attribute
>>>
>>>  > "sendonly".
>>>
>>>
>>>
>>> So, first, the suggestion is to *remove* the following paragraph from
>>> Section 4.2.1:
>>>
>>>
>>>
>>>   "If an endpoint receives text at a higher rate than it can handle,
>>>
>>>    e.g., because the sending endpoint does not support the 'cps'
>>>
>>>    attribute parameter, the receiving endpoint can indicate to the
>>>
>>>    sending endpoint that it is not willing to receive more text at the
>>>
>>>    moment, using the direction attributes (Section 4.2.3)."
>>>
>>>
>>>
>>> Then, do we really need to add anything to 4.2.3.4? If we do, we will
>>> still end up with the does-the-remote-peer-buffer question. Could we just
>>> leave 4.2.3.4 as it is?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Christer
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> > Hi,
>>> >
>>> >> If I understand correctly, senders would still buffer T.140 blocks if
>>> over the limit, or while the peer is in sendonly, to
>>> >> preserve the reliability properties of the channel.
>>> > I don't think there is a requirement for that. If the peer is
>>> sendonly, it means that it does not want to receive anything and that the
>>> network should only be used for uni-directional media. For example, in the
>>> cause of audio or video, the sender is not required to (and, in my
>>> experience, will never) buffer the audio/video in the case of sendonly (or
>>> inactive). Sendonly means that the application should not try to send
>>> anything to begin with, and should inform the user about that. I assume
>>> this apply to an RFC4103 compliant sender too.
>>> >
>>> > Regards,
>>> >
>>> > Christer
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >   It would be good to also say in 5.3 that this MUST(?) happen without
>>> any regard for time limits.
>>> > Yes, the intention is to not lose any text even if the sending user
>>> creates more text than the receiver can receive and present.
>>> > However, even if real-time text is intended for human conversation, it
>>> is common that real-time text user interfaces have a cut-and paste
>>> function. It is also still possible that a session will be connected
>>> through a gateway to a TTY ( a US textphone  in the PSTN), with the
>>> extremely slow reception rate of about 5 characters per second. (Yes, it is
>>> true, there might still be the case, e.g. in contact with 9-1-1 emergency
>>> services). A user, using the paste function of the relatively small amount
>>> of text 300 characters, will block the transmission for 60 seconds in that
>>> session before the real-time flow of typing can be regained. Then it is
>>> good that the buffer is at the sender side, so that the sending user can be
>>> informed and maybe provided with the option to interrupt or cancel the
>>> transmission of the pasted text so that typed transmission in real time can
>>> be regained. Such options in the user interface are out of scope for the
>>> current spec, but it is good to know that that opportunity is there, rather
>>> than to send the whole chunk of text out to a combination of network
>>> devices and far end legacy user device without control of where buffer
>>> overflow and loss might occur.
>>> > Regards
>>> > Gunnar
>>> >
>>> >
>>> > Martin
>>> >
>>> > On Sun, Apr 5, 2020 at 12:15 AM Gunnar Hellström <
>>> mailto:mailto:gunnar.hellstrom@omnitor.se
>>> <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>> > Hi Martin,
>>> >
>>> > I can start answering with some clarifications.
>>> >
>>> > Den 2020-04-05 kl. 03:03, skrev Martin Duke via Datatracker:
>>> >> Martin Duke has entered the following ballot position for
>>> >> draft-ietf-mmusic-t140-usage-data-channel-12: Discuss
>>> >>
>>> >> When responding, please keep the subject line intact and reply to all
>>> >> email addresses included in the To and CC lines. (Feel free to cut
>>> this
>>> >> introductory paragraph, however.)
>>> >>
>>> >>
>>> >> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> >> for more information about IESG DISCUSS and COMMENT positions.
>>> >>
>>> >>
>>> >> The document, along with other ballot positions, can be found here:
>>> >>
>>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/
>>> >>
>>> >>
>>> >>
>>> >> ----------------------------------------------------------------------
>>> >> DISCUSS:
>>> >> ----------------------------------------------------------------------
>>> >>
>>> >> I am confused as to the expected/allowed behavior regarding the cps
>>> attribute
>>> >> parameter.
>>> >>
>>> >> In RFC 4103 Section 6 it says receivers MUST be able to handle
>>> temporary bursts
>>> >> over the cps rate but senders MUST stay below the rate.
>>> >>
>>> >> In section 5.3 it says senders “can” (probably need a 2119 word here)
>>> buffer
>>> >> blocks to stay below cps. There is a 500ms limit so this has its
>>> limitations.
>>> >> Shouldn’t the buffer time be unbounded if characters are coming in at
>>> a rate
>>> >> above cps?
>>> > The 500 ms limit is on the sending side. A more normal time is 300 ms.
>>> >
>>> > The idea is that the reader want to have a smooth flow of incoming text
>>> > to read. In 4.2.1 it is said that CPS is calculated over a 10 second
>>> > period. If the sender reaches the CPS limit, and then waits the usual
>>> > 300 ms, then a calculation is done to check how many characters can be
>>> > transmitted at that point in time to keep under the CPS limit. If the
>>> > flow has been high but even, it might be found that it is possible to
>>> > send 10 characters from the buffer, but 290 characters need to wait.
>>> > These 290 characters are not available for sending at the moment
>>> because
>>> > that would make the CPS exceeded.
>>> >
>>> > It might also be found that no character can be allowed to be sent,
>>> e.g.
>>> > because the sending user just recently had pasted a chunk of 300
>>> > characters of text that was transmitted so that the CPS calculation
>>> over
>>> > 10 seconds is still 30.
>>> >
>>> > The first paragraph in 5.3 ends " as long as there is text to send."
>>> > That is intended to take the CPS calculation into consideration and
>>> > regard only characters allowed to be transmitted while keeping under
>>> the
>>> > CPS over a 10 second period to be "text to send".
>>> >
>>> > The wording "as long as there is text to send." might be improved. I
>>> > leave to Christer to propose a conclusion.
>>> >
>>> >> Meanwhile in section 4.2.1 it suggests that receivers use sendOnly or
>>> inactive
>>> >> (I presume these are the right direction values) to effectively flow
>>> control
>>> >> the incoming data. 4566bis seems to only envision this at the start
>>> of a
>>> >> channel.
>>> > In RFC4566bis it is said about inactive: "This is necessary for
>>> > interactive multimedia conferences where users can put other users on
>>> hold."
>>> >
>>> > It is possible to send sdp during the session to modify the session.
>>> > This is also stated in section 4.2.3.4. The usage of the direction
>>> > attributes for the T140 data channel is registered in section 9.4, and
>>> > rfc4566bis says in section 8.2.4.2 that new use of existing attributes
>>> > shall be registered and that offer/answer procedures may be specified
>>> > for the new use (in this case for the use in dcsa in the t140 data
>>> > channel). In section 4.2.3 it is also stated that the principles of
>>> > offer/answer procedures in rfc 3264 for the direction attributes apply
>>> > (as it also does for the original direction attributes in rfc4566bis).
>>> > In rfc 3264 section 8.4 it is clear that the attributes can be changed
>>> > during the session.
>>> > So, I think we are safe in multiple ways here. The use is registered
>>> and
>>> > it is the same as intended in rfc4566bis and RFC 3264.
>>> >
>>> >
>>> >>     What is the impact of pending data if the directionality of the
>>> >> channel changes? How does this interact with the maximum buffer time?
>>> > Text would be held and not be regarded to be "text to send".
>>> >> I suggest 4.2.1 be clearer on what actions a cps sender and receiver
>>> >> MAY/SHOULD/MUST take, and make sure there aren’t contradictory
>>> requirements.
>>> > Thanks, maybe the solution is to find an improvement of the words "as
>>> > long as there is text to send" in 5.3. Let us see what Christer
>>> proposes.
>>> >
>>> > Regards
>>> >
>>> > Gunnar
>>> >
>>> >>
>>> >> ----------------------------------------------------------------------
>>> >> COMMENT:
>>> >> ----------------------------------------------------------------------
>>> >>
>>> >> The Tsvarea review cites a few other places where the 2119 language
>>> is a little
>>> >> loose, e.g. MUSTs with vague and unenforceable criteria.
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> mmusic mailing list
>>> >> mailto:mailto:mmusic@ietf.org <mailto:mmusic@ietf.org>
>>> >> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> --
>>>
>>> + + + + + + + + + + + + + +
>>>
>>> Gunnar Hellström
>>> Omnitor
>>> gunnar.hellstrom@omnitor.se
>>> +46 708 204 288
>>>
>>> --
>>>
>>>
>>>
>>> + + + + + + + + + + + + + +
>>>
>>>
>>>
>>> Gunnar Hellström
>>>
>>> Omnitor
>>>
>>> gunnar.hellstrom@omnitor.se
>>>
>>> +46 708 204 288
>>>
>>> --
>>>
>>>
>>>
>>> + + + + + + + + + + + + + +
>>>
>>>
>>>
>>> Gunnar Hellström
>>>
>>> Omnitor
>>>
>>> gunnar.hellstrom@omnitor.se
>>>
>>> +46 708 204 288
>>>
>>>