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

From: Martin Duke via Datatracker <[email-masked]>
Date: Sat, 04 Apr 2020 18:03:00 -0700

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?

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. What is the impact of pending data if the directionality of the
channel changes? How does this interact with the maximum buffer time?

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.

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

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 5 Apr 2020 09:15:12 +0200

Hi Martin,

I can start answering with some clarifications.

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-t140-usage-data-channel/

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.

> 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
Text would be held and not be regarded to be "text to send".
> 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

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 

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

Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Martin Duke <[email-masked]>
Date: Sun, 5 Apr 2020 07:34:51 -0700

Gunnar,

Thanks for the clarification. I agree that defining or rewording ‘text to
send’ solves the consistency issue.

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. It would be good to also say in 5.3 that this
MUST(?) happen without any regard for time limits.

Martin

On Sun, Apr 5, 2020 at 12:15 AM Gunnar Hellström <
[email-masked]> wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 5 Apr 2020 19:36:36 +0200

Martin,

Den 2020-04-05 kl. 16:34, skrev Martin Duke:
> Gunnar,
>
> Thanks for the clarification. I agree that defining or rewording ‘text 
> to send’ solves the consistency issue.
>
> 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. 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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Martin,
>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     +46 708 204 288
>
-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 5 Apr 2020 19:17:31 +0000

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:[email-masked]> wrote:
Hi Martin,

Regards

Gunnar

> mailto:[email-masked]

-- 

Gunnar Hellström
Omnitor
mailto:[email-masked]
+46 708 204 288
-- 

Gunnar Hellström
Omnitor
mailto:[email-masked]
+46 708 204 288

---

From: Martin Duke <[email-masked]>
Date: Sun, 5 Apr 2020 16:59:42 -0700

Hi Christer,

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.

Thanks.

On Sun, Apr 5, 2020 at 12:17 PM Christer Holmberg <
[email-masked]> wrote:

> over the limit, or while the peer is in sendonly, to
> 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
>
>
>
>
>
> 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
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 06:40:22 +0000

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.

Regards,

Chrsiter

Hi,

Regards,

Christer

Martin

On Sun, Apr 5, 2020 at 12:15 AM Gunnar Hellström <mailto:[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

Regards

Gunnar

> mailto:[email-masked]<mailto:[email-masked]>

--

Gunnar Hellström
Omnitor
mailto:[email-masked]<mailto:[email-masked]>
+46 708 204 288
--

Gunnar Hellström
Omnitor
mailto:[email-masked]<mailto:[email-masked]>
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 6 Apr 2020 16:13:14 +0200

Hi,

Den 2020-04-06 kl. 08:40, skrev Christer Holmberg:
>
> 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.
>
> >
>
> 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.

Regards

Gunnar

> Regards,
>
> Chrsiter
>
>     Hi,
>
>     > If I understand correctly, senders would still buffer T.140
>     blocks if over the limit, or while the peer is in sendonly, to
>     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
>
>
>
>
>
>     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
>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>> wrote:
>     Hi Martin,
>
>     > mailto:[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     +46 708 204 288
>     -- 
>
>     <mailto:[email-masked]>
>     +46 708 204 288
>
-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 15:19:01 +0000

Hi,
 
>> 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

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?

Regards,

Christer

 

Hi,

Regards,

Christer

Martin

On Sun, Apr 5, 2020 at 12:15 AM Gunnar Hellström <mailto:mailto:[email-masked]> wrote:
Hi Martin,

Regards

Gunnar

> mailto:mailto:[email-masked]

-- 

Gunnar Hellström
Omnitor
mailto:mailto:[email-masked]
+46 708 204 288
-- 

Gunnar Hellström
Omnitor
mailto:mailto:[email-masked]
+46 708 204 288
-- 

Gunnar Hellström
Omnitor

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 6 Apr 2020 19:51:26 +0200

Hi,

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

Regards

Gunnar

-- 

Gunnar Hellström
Omnitor

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 6 Apr 2020 13:55:21 -0400

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

ISTM that if the local end of the connection is recvonly (or inactive) 
then user input SHOULD not be accepted from the user, and if received it 
MUST be discarded.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 21:08:06 +0000

Hi,

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

--

Gunnar Hellström
Omnitor

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 6 Apr 2020 17:26:21 -0400

On 4/6/20 5:08 PM, Christer Holmberg wrote:

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

I think it depends on what the intent was of that paragraph. The current 
discussion seems to take it to mean that an endpoint that is being 
overwhelmed by excess incoming text might change the direction to 
sendonly in order to *throttle* the sender while it catches up. I'm 
inclined to agree with you that this is an inappropriate technique.

An alternative interpretation is that in such a case the overwhelmed 
receiver may change the direction to sendonly in order to permanently 
silence the misbehaving sender. I have no problem with that.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Apr 2020 21:36:24 +0000

Hi,

> silence the misbehaving sender. I have no problem with that.

I am fine describing the usage of sendonly, but the question is how we make it clear that it is not a throttle/flow control mechanism, and that the remote peer is not expected to buffer text etc.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 6 Apr 2020 19:36:50 -0400

On 4/6/20 5:36 PM, Christer Holmberg wrote:
> I am fine describing the usage of sendonly, but the question is how we 
> make it clear that it is not a throttle/flow control mechanism, and that 
> the remote peer is not expected to buffer text etc.

Maybe just say that it SHOULD NOT be used as a flow control mechanism, 
leaving it (implicitly) open for use for other reasons.

	Thanks,
	Paul

---

From: Martin Duke <[email-masked]>
Date: Mon, 6 Apr 2020 22:03:44 -0700

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 <
[email-masked]> 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.
>
>  >>>>>
>
>  >>>> Perhaps we could say that the application may buffer text for a
> while in case of sendonly. But, the sendonly could “go on forever”,
>
> 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.
>  >> 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?
>
>  >
>
> 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,
> >
> > 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
> >
> >
> >
> >
> >
> 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
> >
> >> mailto:mailto:[email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 07:36:55 +0000

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.

   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

From: Martin Duke <[email-masked]>
Date: Tuesday, 7 April 2020 at 8.04
To: Christer Holmberg <[email-masked]>
Cc: Gunnar Hellstrom <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

--

Gunnar Hellström
Omnitor
[email-masked]<mailto:[email-masked]>
+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 7 Apr 2020 11:49:32 +0200

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.

>    attributes (Section 4.2.3), or use a flow control mechanism to
    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.
> 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 <[email-masked]>
> *Date: *Tuesday, 7 April 2020 at 8.04
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Gunnar Hellstrom <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, Flemming 
> Andreasen <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [MMUSIC] Martin Duke's Discuss on 
> draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)
>
> 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 
> <[email-masked] 
> <mailto:[email-masked]>> 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
>     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".
>
>     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,
>     >
>     <mailto:mailto:[email-masked]> wrote:
>     > Hi Martin,
>     >
-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Apr 2020 10:00:28 +0000

Hi,

Your suggestion looks good. I suggest to include it in the same paragraph, as it is an exemption to the SHOULD.

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

From: Gunnar Hellstrom <[email-masked]>
Date: Tuesday, 7 April 2020 at 12.49
To: Christer Holmberg <[email-masked]>, Martin Duke <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Flemming Andreasen <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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.

   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,

Regards,

Christer

Regards

Gunnar

From: Martin Duke <[email-masked]><mailto:[email-masked]>
Date: Tuesday, 7 April 2020 at 8.04
To: Christer Holmberg <[email-masked]><mailto:[email-masked]>
Cc: Gunnar Hellstrom <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Flemming Andreasen <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)

Hi,

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 7 Apr 2020 13:04:44 +0200

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

Gunnar

> *From: *Gunnar Hellstrom <[email-masked]>
> *Date: *Tuesday, 7 April 2020 at 12.49
> *To: *Christer Holmberg <[email-masked]>, Martin Duke 
> <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, 
> "[email-masked]" 
> This looks reasonably good. But there are cases when it is important 
> to regain the real-time human conversation as soon as possible, and 
>     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
>
>     <mailto:[email-masked]>
>     <mailto:[email-masked]>
>     *Cc: *Gunnar Hellstrom <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked]"
>     <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>,
>     "[email-masked]"
>     <mailto:[email-masked]>
>     <[email-masked]>
>     <mailto:[email-masked]>,
>     Flemming Andreasen <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked]"
>     <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>, "[email-masked]"
>     <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>     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.
>
>          >>>>> 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.
>
>          >>>>
>
>         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.
>
>          >>>
>
>         buffered. People will sort out the appearing situations. We
>         can hope that a proper
>
>          >> 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?
>
>          >
>
>          > 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
>
>         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,
>         >
>         > 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.
>         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
>         devices and far end legacy user device without control of
>         where buffer overflow and loss might occur.
>         > Regards
>         > Gunnar
>         >
>         >
>         > Martin
>         >

-- 

Gunnar Hellström
Omnitor

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Apr 2020 10:31:21 +0000

Hi Martin,

Are you ok with the proposed change below?

Regards,

Christer

Date: Tuesday, 7 April 2020 at 14.04

Hi Christer,

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:

Regards,

Christer

Regards

Gunnar

From: Gunnar Hellstrom <[email-masked]><mailto:[email-masked]>
Date: Tuesday, 7 April 2020 at 12.49
To: Christer Holmberg <[email-masked]><mailto:[email-masked]>, Martin Duke <[email-masked]><mailto:[email-masked]>
Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, Flemming Andreasen <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)

Hi,

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Martin Duke <[email-masked]>
Date: Wed, 8 Apr 2020 11:02:46 -0700

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.

On Wed, Apr 8, 2020 at 3:31 AM Christer Holmberg <
[email-masked]> wrote:

> *Date: *Tuesday, 7 April 2020 at 14.04
> *To: *Christer Holmberg <[email-masked]>, Martin Duke <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Flemming Andreasen <
> [email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> 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:
>
>
>
> <[email-masked]>
> <[email-masked]>, Martin Duke <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>,
> <[email-masked]>, Flemming Andreasen
> <[email-masked]> <[email-masked]>, "[email-masked]"
> <[email-masked]> <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
> 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.
>
> 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 <[email-masked]> <[email-masked]>
> <[email-masked]>
> <[email-masked]>, "[email-masked]" <[email-masked]>
> <[email-masked]> <[email-masked]>,
> <[email-masked]>, Flemming Andreasen
> <[email-masked]> <[email-masked]>, "[email-masked]"
> <[email-masked]> <[email-masked]> <[email-masked]>,
> "[email-masked]" <[email-masked]> <[email-masked]> <[email-masked]>
>  >> 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).
>
>  >>
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 8 Apr 2020 19:06:50 +0000

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 (“strong indication” issue)

https://github.com/cdh4u/draft-datachannel-t140/pull/56/commits/90c6ff8625004262cce1a434a34b5dae03356932 (sendonly issue)

(If you prefer me to write the changes in an e-mail reply I can do that.)

Regards,

Christer

From: Gunnar Hellstrom <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 7 April 2020 at 14.04
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Martin Duke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Flemming Andreasen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Martin Duke's Discuss on draft-ietf-mmusic-t140-usage-data-channel-12: (with DISCUSS and COMMENT)

Hi Christer,

Something like:

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Martin Duke <[email-masked]>
Date: Wed, 8 Apr 2020 20:10:37 -0700

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

On Wed, Apr 8, 2020 at 12:06 PM Christer Holmberg <
[email-masked]> wrote:

> response to my DISCUSS? There was a different thread about 5.3
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Apr 2020 06:17:27 +0000

Hi,

> Buffering can also be used for staying within the maximum character transmission rate
>

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

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)

Regards,

Christer

Hi Christer,

Something like:

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Martin Duke <[email-masked]>
Date: Thu, 9 Apr 2020 06:30:39 -0700

Is that inconsistent with MAY?

On Wed, Apr 8, 2020, 23:17 Christer Holmberg <[email-masked]>
wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Apr 2020 13:37:47 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

Hi Christer,

Something like:

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: Martin Duke <[email-masked]>
Date: Thu, 9 Apr 2020 06:43:18 -0700

Thanks for your work on this. You've fully addressed my DISCUSS.

On Thu, Apr 9, 2020, 06:37 Christer Holmberg <[email-masked]>
wrote:

> On Wed, Apr 8, 2020, 23:17 Christer Holmberg <

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Apr 2020 14:34:26 +0000

Hi,

>Thanks for your work on this. You've fully addressed my DISCUSS.

Excellent! Thanks!

Regards,

Christer

On Thu, Apr 9, 2020, 06:37 Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

Regards,

Christer

Hi Christer,

Something like:

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

Regards

Gunnar

Hi,

Regards,

Christer

--

Gunnar Hellström
Omnitor

--

Gunnar Hellström

Omnitor

+46 708 204 288

--

Gunnar Hellström

Omnitor

+46 708 204 288

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 10 Apr 2020 00:11:56 -0700

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 <[email-masked]> wrote:

> On Thu, Apr 9, 2020, 06:37 Christer Holmberg <
>> <[email-masked]> <[email-masked]>
>> <mmusic-chairs@ietf..org>, "[email-masked]" <[email-masked]>
>> <[email-masked]> <[email-masked]>
>> attributes and a flow control mechanism.. The text is also “future proof”,
>> <[email-masked]> <[email-masked]>
>> <mmusic-chairs@ietf..org>, "[email-masked]" <[email-masked]>
>> <[email-masked]> <[email-masked]>

---

From: Martin Duke <[email-masked]>
Date: Fri, 10 Apr 2020 08:55:00 -0700

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

On Fri, Apr 10, 2020 at 12:12 AM Murray S. Kucherawy <[email-masked]>
wrote:

> The Tsvarea review cites a few other places where the 2119 language is a little loose, e.g. MUSTs with vague and unenforceable criteria.
>
>>> >There still isn't guidance on what senders should do, but IMO that is
>>> an RFC 4103 problem, not a problem with this draft.
>>>
>>> >
>>>
>>> [email-masked]>, Flemming Andreasen
>>> <[email-masked]>, "[email-masked]" <[email-masked]>,
>>> "[email-masked]" <[email-masked]>
>>> Andreasen <[email-masked]> <[email-masked]>,
>>> "[email-masked]" <[email-masked]>
>>> <[email-masked]> <mmusic-chairs@ietf..org>, "[email-masked]"
>>> <[email-masked]> <[email-masked]> <[email-masked]>
>>> Andreasen <[email-masked]> <[email-masked]>,
>>> "[email-masked]" <[email-masked]>
>>> <[email-masked]> <mmusic-chairs@ietf..org>, "[email-masked]"
>>> <[email-masked]> <[email-masked]> <[email-masked]>
>>> and MAY do when the user exceeds the peer CPS, including dropping frames if
>>>  >>>>> I have no strong opinion on the correct behavior here, but I
>>> think the buffering section should address it.
>>>
>>>  >>>>
>>>
>>> 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
>>> >
>>> >
>>> >
>>> >
>>> >