Subject: [MMUSIC] Draft new version: t140-data-channel-usage-03

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Sep 2019 10:40:46 +0000

Hi,

I have submitted a new version (-03) of the T.140 data channel usage draft.

The following pull requests were merged and incorporated in the new version:

https://github.com/cdh4u/draft-datachannel-t140/pull/30
https://github.com/cdh4u/draft-datachannel-t140/pull/31<https://github.com/cdh4u/draft-datachannel-t140/pull/310>

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 17 Sep 2019 11:26:52 -0400

The changes made in -03 seem fine to me.

Then I realized that I have only been looking at diffs for awhile, and 
haven't carefully reviewed the full document for awhile. So I did that, 
and found some other thing that I think are worthy of consideration:

* Section 4:

s/proceudres/procedures/

* Section 4.2:

The subsections 4.2.n describe some specific SDP attributes that may be 
used with T.140 data channels. But it isn't definitive about other 
attributes. I think you should be explict whether other attributes maybe 
included. In any case, I think it would be prudent to specify that if 
other attributes are *received* and are not understood then they are to 
be ignored, in order to be consistent with SDP treatment of attributes.

* Section 4.2.1:

This section is a little hard to follow. The use of fmtp with data 
channels is complicated, since the value part of fmtp is dependent on 
the fmt in the m= line. You do reference RFC4103, but it is still a leap 
to put this all together.

I suggest you first discuss the general use of fmtp with data channels - 
that the value syntax of fmtp is to follow RFC4103.

*Then* you can move on to discuss the use of 'cps'.

It isn't clear to me if there are any other meaningful or permitted fmtp 
parameters. I suggest you make a definitive statement about this.

* Section 5:

These examples are good. But there is no example for CPS, and it would 
be nice to have one. Rather than having a separate example for each, I 
think it would be sufficient to fold multiple attributes into a single 
example.

* Section 5.3:

In the following:

    As described in [T140], buffering can be used to reduce overhead,
    with the maximum buffering time being 500 ms.  It can also be used
    for staying within the maximum character transmission rate
    (Section 4.2), if such has been provided by the peer.

it is unclear to me whether the 500ms max time is applicable when using 
buffering to stay within the max transmission rate. I presume not. Can 
you be more explicit?

* Section 5.4:

It isn't clear to me whether this is talking about failure and 
re-establishment of individual data *channels*, or of the containing 
SCTP association. I guess you mean both. But it would be good to be 
explicit, since the process for doing so is a bit different.

* General:

Perhaps replace the references to RFC4566 throughout with references to 
RFC4566bis. It is already in the editor's queue so shouldn't cause a 
delay. Since you have no dependency on the updates in RFC4566bis this 
isn't an essential change. It is just a nice-to-have.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Sep 2019 16:23:54 +0000

Hi,

>Then I realized that I have only been looking at diffs for awhile, and haven't carefully reviewed the full document for awhile. 
>So I did that, and found some other thing that I think are worthy of consideration:
>
>* Section 4:
>
>s/proceudres/procedures/

I'll fix that (however, I think that could be considered a WGLC comment).

---

>* Section 4.2:
>
>The subsections 4.2.n describe some specific SDP attributes that may be used with T.140 data channels. But it isn't definitive about 
>other attributes. I think you should be explict whether other attributes maybe included. In any case, I think it would be prudent to 
>specify that if other attributes are *received* and are not understood then they are to be ignored, in order to be consistent with SDP treatment of attributes.

I think SDPNEG shall (unless it already does) define generic procedures for receiving non-supported SDP attributes in dcsa. I assume it would be the same as for non-supported SDP attributes in general - ignore them.

---

>* Section 4.2.1:
>
>This section is a little hard to follow. The use of fmtp with data channels is complicated, since the value part of fmtp is dependent on
>the fmt in the m= line. You do reference RFC4103, but it is still a leap to put this all together.
>
>I suggest you first discuss the general use of fmtp with data channels - that the value syntax of fmtp is to follow RFC4103.
>
> It isn't clear to me if there are any other meaningful or permitted fmtp parameters. I suggest you make a definitive statement about this.

Ok, I can have a look at that.

>* Section 5:
>
>These examples are good. But there is no example for CPS, and it would be nice to have one. Rather than having a separate example for each, 
>I think it would be sufficient to fold multiple attributes into a single example.

CPS is used in the second SDP example.

But, I guess I can remove the SDP examples everything, and include everything in O/A example(s).

---

* Section 5.3:

> it is unclear to me whether the 500ms max time is applicable when using buffering to stay 
>within the max transmission rate. I presume not. Can you be more explicit?

I will let Gunnar give his opinion on that.

Personally I would assume that it is an implementation issue when it comes to buffering in order to stay within the max transmission rate, and at some point an implementation may simply choose to terminate the session due to buffer overload

---

* Section 5.4:

>It isn't clear to me whether this is talking about failure and re-establishment of individual data *channels*, or of the
>containing SCTP association. I guess you mean both. But it would be good to be explicit, since the process for doing
>so is a bit different.

As far as the T.140 procedure is concerned, it doesn't matter only the data channel or the whole association went done - the procedure describes what happens once the data channel has been re-established.

But, I can add text clarifying that individual data channels, or the whole SCTP association, mail fail.

---

* General:

>Perhaps replace the references to RFC4566 throughout with references to RFC4566bis. It is already in the editor's queue
>so shouldn't cause a delay. Since you have no dependency on the updates in RFC4566bis this isn't an essential change. It is just a nice-to-have.

I can do that. After all, SDPNEG also references 4566bis, so..

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Sep 2019 11:21:57 +0000

Hi,

...
    
* Section 4.2:
    
> I think SDPNEG shall (unless it already does) define generic procedures for receiving non-supported SDP attributes in dcsa. 
> I assume it would be the same as for non-supported SDP attributes in general - ignore them.
   
Section 6.7 of SDPNEG says:

"SDP offer or answer has an "a=dcsa" attribute, whose subprotocol
      attribute is unknown.

      *  The receiver of such an SDP offer or answer SHOULD ignore this
         entire "a=dcsa" attribute line."

So, I think that covers your comment.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Sep 2019 12:11:10 +0000

Hi,

...

    > Ok, I can have a look at that.
    
    I had a look at this.

    First, a general description of fmtp with data channels belong to SDPNEG.

    Second, I am not really sure how I could modify the text in order to make it more clear. I CAN add a sentence clarifying that no other usage of fmtp is defined for T.140 data channels.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Sep 2019 12:20:26 -0400

Christer,

>      First, a general description of fmtp with data channels belong to SDPNEG.

I don't think so. The syntax of the value to use with a=fmtp depends on 
the <fmt> parameter of the m= line. (In the case of RTP this is the 
codec.) When used with a data channel we can't refer to that. Instead, 
it needs to be determined based on the subprotocol from the dcmap. And I 
don't think there is necessarily a consistent mapping for all 
subprotocols. So I think each subprotocol needs to specify where to go 
for the syntax of fmtp.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 18 Sep 2019 20:58:52 +0000

Hi, see comment on buffering below.

--------------------------------------------------------------------

Hi,

---

---

---

Personally I would assume that it is an implementation issue when it comes to buffering in order to stay within the max transmission rate, and at some point an implementation may simply choose to terminate the session due to buffer overload
[GH] The 500 ms max time between transmissions still apply when one participant produces more text than the cps value allows. You keep on transmitting from the buffer, but do not take more than allowed.  Rfc 4103 says that the mean cps is over any 10 second period. It might be good torepeat that in thi draft.

Regards
Gunnar

---

---

Regards,

Christer

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2019 06:26:20 +0000

Hi,

...

* Section 5.3:

>>>    (Section 4.2), if such has been provided by the peer..
>>>
>> Personally I would assume that it is an implementation issue when it comes to
>> buffering in order to stay within the max transmission rate, and at some point
>> an implementation may simply choose to terminate the session due to buffer overload
>
> [GH] The 500 ms max time between transmissions still apply when one participant produces
> more text than the cps value allows. You keep on transmitting from the buffer, but do not
> take more than allowed.  Rfc 4103 says that the mean cps is over any 10 second period.
> It might be good torepeat that in thi draft.

Could you write a pull request, or suggest text on the list?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2019 07:47:40 +0000

Hi,

I updated the pull request, by adding a sentence regarding the 10-second internval.

Regards,

Christer

From: mmusic <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
Date: Thursday, 19 September 2019 at 9.26
To: Gunnar Hellstrom <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] Draft new version: t140-data-channel-usage-03 -buffering

Hi,

…

* Section 5.3:

>>>    with the maximum buffering time being 500 ms..  It can also be used

Regards,

Christer

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 20 Sep 2019 12:03:05 +0000

----------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 20 42 88

________________________________
Från: Christer Holmberg <[email-masked]>
Skickat: den 20 september 2019 09:47
Till: Gunnar Hellström <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked] <[email-masked]>
Ämne: Re: [MMUSIC] Draft new version: t140-data-channel-usage-03 -buffering

Hi,

[GH] Fine. I made minor comments in the pr.  It is good to just indicate the interval for the cps calculation and not the details for how to handle transmission intervals when there is a need to limit transmission. The latter is best kept as an application decision.

Regards

Gunnar

Regards,

Christer

…

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2019 12:20:43 +0000

> [GH] Fine. I made minor comments in the pr.  It is good to just indicate the interval for the cps calculation and not the details for how to handle

> transmission intervals when there is a need to limit transmission. The latter is best kept as an application decision.

I have updated the pull request according to your suggestions.

Regards,

Christer