Re: [AVTCORE] Source switching performance in draft-hellstrom-avtcore-multi-party-rtt-source-01.txt - suggested text changes

[Gunnar Hellström <[e-mail]>]

Hi James,

Thanks for good proposals.


Comments inline.

Den 2020-03-18 kl. 12:50, skrev James Hamlin:
>
>
>
> Hi Gunnar
>
>
> Having thought through some alternatives, it is now easier to suggest 
> possible changes to the current text.
>
>
> In Section 11 SDP Capability negotiation, append:-
>
>
>     When an rtp-mixer offers the "rtt-mix" capability, it SHOULD be
>     willing to provide a mixed stream according to
>     https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#appendix-A
>     [or should this be in-lined?] that is compatible with RFC4103
>     implementations that do not implement this specification, unless
>     it is known that it will not need to inter-operate with such
>     implementations.
>
[GH] Interesting proposal. I had imagined this multi-party-rtt-source 
draft to be a pure technical specification for the multi-party rtt 
transport. This proposal makes it a slightly wider prescription on what 
mixers should do also in other cases. It is good that you link this with 
the rtt-mix capability indication, because that provides an opportunity 
to make the presentation on an un-aware device just a little bit better.
I would like to hear comments from the expected users of this 
specification if we shall have this requirement here.

Next thing. I do not want to make us depend on the progress of the 
draft-hellstrom-mmusic-multi-party-rtt 
<https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-00#appendix-A> 
draft. Therefore if we decide to have this requirement included, I would 
like to include a minimal description of the mixing procedure for 
multi-party unaware terminals. A rewording of this section:
https://tools.ietf.org/html/draft-hellstrom-mmusic-multi-party-rtt-02#section-9 

>
>
> In section 10.  Usage without redundancy:-
>
>     When transmitting, using the text/t140 format, to a party that has
>     indicated the "rtt-mix" capability, the CSRC-list SHOULD
>     contain exactly one member.
>
>     To avoid potential interoperability problems with older RFC 4103
>     implementations which do not expect a CSRC-list, the CSRC-list
>     SHOULD be empty when transmitting to a party that has not has
>     indicated the "rtt-mix" capability.
>
[GH]That would be against RTP RFC 3550. I assume that current 
implementations simply ignore the CSRC list. Therefore including CSRC 
would be the right thing to do to follow RFC 3550.
>
>     The text/red format SHOULD be used unless some other protection
>     against packet loss is utilized, for example a reliable transport
>     such as TCP.
>
[GH]I will not mention TCP. It is more likely that there are other 
resons for why the network or transport can be called reliable.
>
> Section 10 could move to after the current section 11 so the SDP gets 
> defined first.
>
[GH]OK
>
>
> In section 4 "Use of fields in the RTP packets" insert:
>
>     Note: This specification departs from section 4 of RFC2198 which
>     associates the whole of the CSRC-list with the primary data and
>     assumes that the same list applies to reconstructed redundant
>     data. In this specification a text block is associated
>     with exactly one CSRC as described above. Also RFC2198 anticipates
>     infrequent change to
>
>     CSRCs; implementers should be aware that the order of the
>     CSRC-list according to this specification will rotate during
>     transitions between different participants sending text.
>
[GH]Good catch
>
> In "9.  Use with SIP centralized conferencing framework" insert:
>
>     The CSRC-list in an RTP packet
>     only includes participants who's text is included in one or
>     more text blocks. It is not the same as the list of participants
>     in a conference. With audio and video media, the CSRC-list would
>     often contain all participants who are not muted whereas text
>     participants that don't type are completely silent and so don't
>     show up in RTP packet CSRC-lists.
>
[GH]Yes, can be good to have that explanation.


Thanks,


Gunnar

>
> Best regards
>
>
> James
>
>
>
>
> James Hamlin
> Contractor
> Purple, a Division of ZP Better Together, LLC
> purplevrs.com
>
> The information contained in this e-mail message is intended only for 
> the personal and confidential use of the recipient(s) named above. If 
> you have received this communication in error, please notify us 
> immediately by e-mail, and delete the original message.
>
> ------------------------------------------------------------------------
> *From:* Gunnar Hellström <[e-mail]>
> *Sent:* 13 March 2020 16:41
> *To:* [e-mail]; James Hamlin
> *Subject:* Source switching performance in 
> draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
>
> Hi,
>
> I want to follow-up on the good discussion on source switching 
> performance a couple of days ago, under the subject "[AVTCORE] 
> Improved RTP-mixer performance for RFC 2198 and RFC 4103 redundancy 
> coding"
>
> *Two parts in the performance increase solution.*
> Two actions are proposed in 
> draft-hellstrom-avtcore-multi-party-rtt-source:
> a) Reduce the packet transmission interval from 300 to 100 ms.
> b) Use a strict relation between members in the CSRC list and the 
> parts of the payload that is original text and first generation 
> redundancy and second generation redundancy so that the mixer can 
> switch source for every new packet and the sources of text recovered 
> from redundancy can be assessed by the receiver.
>
> I think it is worth while to move forward with the complete 
> improvement a) and b) proposed in the draft. It will cause less 
> complexity, lower delays and lower risk for stalling in case of many 
> participants entering new text simultaneously.
>
> Here is my reasoning:
>
> I have the following view of the achievable performance improvements 
> for different cases:
>
> 1. With the original source switching with RFC 4103 and an RTP-mixer 
> using 300 ms transmission interval and not allowing a mix of sources 
> in one packet, there can be one source switching per second by the 
> mixer with an introduced delay of up to one second.
>
>
> 2. By just reducing the transmission interval from 300 to 100 ms, it 
> will be possible to have three source switches per second with an 
> introduced delay of up to one second. (with just two parties sending 
> text simultaneously, the delay will be maximum 300 ms. )
>
> 3. And by applying the proposal from the multi-party-rtt-source draft 
> with the CSRC-list as a source list for the redundancy, and also using 
> 100 ms transmission interval, there can be switching between five 
> source per second with an introduced delay of max 500 ms. With just 
> two parties typing simultaneously, the delay will be a maximum of 100 ms.
>
> The delays are extreme values from when all sources start to type 
> simultaneously.  It was agreed that at least the improvement from the 
> reduced transmission interval is needed.
>
> Case 1 and 2 are a bit complex for the mixer to implement. From the 
> moment it has text queued for transmission from another source B than 
> the one currently transmitted A, then the mixer needs to stop adding 
> new text from A to the packets, but still send two more packets with 
> the agreed transmission interval, progressing the latest transmitted 
> original text to first generation redundancy and then again one more 
> packet with the text as second level redundancy. Not until that is 
> done, the mixer is allowed to start taking text from the transmission 
> queue from B to transmit. This is the background of the 1 s vs 300 ms 
> delays in case 1 and 2.
>
> In case 3, there is much less complexity. When there is something from 
> B in queue for transmission, the mixer can decide to insert that in 
> next packet and add the redundancy from earlier transmissions from A, 
> because their sources are included in the CSRC list in the same packet.
>
> Therefore I want to move on with the complete solution in case 3.
>
> -----------------------------------
>
> *Influence on the multi-party capability negotiation:*
> There is an installed park of RTT implementations without multi-party 
> awareness. The receiver need to take active part in planning the 
> multi-party RTT presentation. Therefore a capability negotiation is 
> needed. A simple sdp attribute a=rtt-mix without value is proposed in 
> the draft.
>
> It is important to let this attribute mean capability of the complete 
> solution case 3).  If there is a temptation to have different levels 
> of implementation, some only implementing the shorter transmission 
> interval (2) and some implementing the complete solution (3), then 
> threre will be a need for two different attributes, or one attribute 
> with a list of parameter values for the two cases. That would 
> complicate the evaluation of the negotiation. Therefore I would prefer 
> that the attribute can mean capability to use the complete mixing 
> solution (3).
>
> Regards
>
> Gunnar
>
>
> Den 2020-02-29 kl. 20:13, skrev [e-mail]:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>          Title           : Indicating source of multi-party Real-time text
>>          Author          : Gunnar Hellstrom
>> 	Filename        : draft-hellstrom-avtcore-multi-party-rtt-source-01.txt
>> 	Pages           : 13
>> 	Date            : 2020-02-29
>>
>> Abstract:
>>     Real-time text mixers need to identify the source of each transmitted
>>     text chunk so that it can be presented in suitable grouping with
>>     other text from the same source.  An enhancement for RFC 4103 real-
>>     time text is provided, suitable for a centralized conference model
>>     that enables source identification, for use by text mixers and
>>     conference-enabled participants.  The mechanism builds on use of the
>>     CSRC list in the RTP packet.  A capability exchange is specified so
>>     that it can be verified that a participant can handle the multi-party
>>     coded real-time text stream.  The capability is indicated by an sdp
>>     media attribute "rtt-mix".
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-hellstrom-avtcore-multi-party-rtt-source/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-hellstrom-avtcore-multi-party-rtt-source-01
>> https://datatracker.ietf.org/doc/html/draft-hellstrom-avtcore-multi-party-rtt-source-01
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-hellstrom-avtcore-multi-party-rtt-source-01
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories:http://www.ietf.org/shadow.html
>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt
> -- 
>
> + + + + + + + + + + + + + +
>
> Gunnar Hellström
> Omnitor
> [e-mail]
> [phone]

-- 

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

Gunnar Hellström
Omnitor
[e-mail]
[phone]