Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
"Murray S. Kucherawy" <superuser@gmail.com> Fri, 10 April 2020 07:36 UTC
Return-Path: <superuser@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 D456C3A0D0E; Fri, 10 Apr 2020 00:36:38 -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 XsuLIyFnuc43; Fri, 10 Apr 2020 00:36:32 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 7E0CD3A18B4; Fri, 10 Apr 2020 00:36:32 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id h11so419016plk.7; Fri, 10 Apr 2020 00:36:32 -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=HHduk33M0o4DmrxIyEfCFPbsBY98dRoduujWo32iEUM=; b=d3Mb2ixymCcTRIpWHpZgvljiwjdroBzxVR3xaGoRzdxM4QjB04mSMxo5cUq7CYKl6i JvcKE5a6N3BKpuogOxsAXFARAH4urLVg+RrSAB1j+YnmcJV5z5D9rkvRzIaVv78WnKM9 ANwL8geWNH4SJcV3nopZxkaVyWrlokmKRiuCZ/tKGaqVKJyUKXFXx7hcYS/StC5Z3zqA 8vf+nqAyKk5V2+PgzUHUuEFkxUZ0epMR7iulOw3v3AriQzZd0AF3nCIKFCotlgm98aGS ZvjthNne1+BL+LkhaYZaA/JRIN3yWbHpdmEZH+acHN/Y03LG5hhTDJJSlJL+J7ATrCQt Tp3w==
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=HHduk33M0o4DmrxIyEfCFPbsBY98dRoduujWo32iEUM=; b=WYa6DmsB3nLTy9TFFw+HmknVxvslfgIp45edF1uKsdM8Kw+0kWzeb1bdAQP+PPSDXq TuN9cGH6cXHq2+MylWthxtseUjx8s2VxkcuHQiCf/QWQz/z8RWQdGalsts0+dLPh243j IpRYtBGfe0d3iAhhsGRM17cic6yvsIm8/V/m0RQFL1m+Ko3rj7KgB/GxoqlVEM+Brc00 j5AaESbcRySb1sbWs5OmuErTfFWfw1TYFxFu8nwd2ixijUQ86Zt3EpyNiC9dMkw/EBjQ 4AHmK3WfF6axf+0+NvfKnZOVauc79OVlC5Bub5pvLgz8H6kBCDT4x80jrb8VdXAut6pM a1CA==
X-Gm-Message-State: AGi0PuZT6IWlTIhfDxxxHFktJ7f93wBdQLsQLK43UW+5wt1zu/UoNs6v Dx0rQBLbc3slbimDoeW9fxM+w4p31VhMxIf1sow1bIkJ3MY=
X-Google-Smtp-Source: APiQypJYpAdUm9f6sd4+5xKOyK5kB3jVmUyi5l2E5KlHgBP0HGazL00KQj7DLM+XjYzOwDwx/dYJlN8NnyCun6rzyHQ=
X-Received: by 2002:a67:804a:: with SMTP id b71mr2764260vsd.175.1586502728062; Fri, 10 Apr 2020 00:12:08 -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>
In-Reply-To: <CAM4esxQT+QYT3omJ5h9mSZQ=_9VhkqVpcXFDL_iK31OyEnfYUw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Fri, 10 Apr 2020 00:11:56 -0700
Message-ID: <CAL0qLwZVO1K=0+Sjw3AO385trAHeO95-r6RQfrQTq3HMrpKQpQ@mail.gmail.com>
To: Martin Duke <martin.h.duke@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>, Gunnar Hellström <gunnar.hellstrom@omnitor.se>, "fandreas@cisco.com" <fandreas@cisco.com>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008a9db305a2ea7335"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/N3GeQR-PzYNKQzgJmzTtjg3bHA4>
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 07:36:39 -0000
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>, Martin Duke < >> martin.h.duke@gmail.com> >> *Cc: *"iesg@ietf.org" <iesg@ietf.org>, " >> draft-ietf-mmusic-t140-usage-data-channel@ietf.org" < >> draft-ietf-mmusic-t140-usage-data-channel@ietf.org>, Flemming Andreasen < >> fandreas@cisco.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@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 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>, 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>, >> "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>, Flemming Andreasen >> <fandreas@cisco.com> <fandreas@cisco.com>, "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>, "iesg@ietf.org" <iesg@ietf.org> >> <iesg@ietf.org> <iesg@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> >> <draft-ietf-mmusic-t140-usage-data-channel@ietf.org>, Flemming Andreasen >> <fandreas@cisco.com> <fandreas@cisco.com>, "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 >> >>
- [MMUSIC] Martin Duke's Discuss on draft-ietf-mmus… Martin Duke via Datatracker
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Gunnar Hellström
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Gunnar Hellström
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Gunnar Hellström
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Gunnar Hellström
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Paul Kyzivat
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Paul Kyzivat
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Paul Kyzivat
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Gunnar Hellström
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Gunnar Hellström
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Christer Holmberg
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Murray S. Kucherawy
- Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-… Martin Duke