Re: [AVTCORE] Improved RTP-mixer performance for RFC 2198 and RFC 4103 redundancy coding

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

Hi James,

Thanks for your review and good comments,

Den 2020-03-09 kl. 18:11, skrev James Hamlin:
>
> Hi Gunnar
>
>
> This is a very interesting draft. It seems to me to fix the stated 
> problem.
>
>
> We'll have some comments on the use of the CSRC-list, and packet 
> format, but I'll start with a more general thread:-
>
>
> There have been interoperability issues within VRS to do with 
> redundancy, which have taken time to iron out. It will be 
> important to maintain interoperability with current implementations - 
> which you've specified with the rtt-mix attribute.
>
Yes, I agree that the redundancy mechanism requires some well planned 
test tools and tests to verify that the recovery is correctly done and 
loss detection correctly done.
>
>
> I think, the latency incurred with current 
> implementations can probably be kept within acceptable limits. For 
> example when 2 participants are typing concurrently a transmission 
> interval of 100ms and 2 redundant generations would incur no more 
> latency that one participant at 300ms intervals.
>
Right. A decreased transmission interval from 300 to 100 ms helps a lot 
in a well managed conference. Usually you only have one person at a time 
transmitting text. At a few occasions there may be two, and very 
seldomly three.  When the mixer sees a reason to switch transmission of 
text from one source A to another B, it needs to send the last text 
chunk from A as primary, and then 100 ms later as first redundancy and 
100 ms later as second reduncancy and then 100 ms later it can sent all 
waiting text from B. So, that is just 300 ms after the need to switch 
was discovered, which matches the waiting time incurred in two-party 
calls with the default interval of 300 ms. T.140 requires buffering to 
be no more than 500 ms in order to keep latency low and flow even, so 
that is within limits of what users tend to accept.


So, it is not until we have a quite unmanaged conference with e.g. 5 
concurrent users sending text that the performance problems become 
apparent. Then the delay between transmissions from source A will be 1.5 
seconds, and there will be a number of characters to transmit, so if the 
receiver displays them immediately, the presentation will be 
unpleasantly jerky, or if the receiver smoothens the presentation you 
will have another second before everything from A is presented.


With the proposed mixing with the strict use of the CSRC list, the delay 
between transmissions from source A will be 500 ms, and that is withing 
the performance requirements of T.140 ( and the users)


However, it can of course be questioned how important it is to support 5 
concurrently transmitting users with low latency and jerky-free 
presentation. The most discussed applications are 1) emegency service 
calls where one call-taker hands over the call smoothly to a first 
responder. And 2) a few participants in a multi-media conference, where 
there might be a speech-to-text service.


So, do you recommend that we drop the proposal to increase the switching 
performance by other means than reducing the transmission interval?


> There is some reduction in fault tolerance because the redundant 
> generations are closer in time and therefore their loss probabilities 
> are likely to be more correlated.
>
Right. The default transmission interval of 300 ms is very good for 
keeping the likelihood high that a burst of loss will not hit all three 
transmissions of a text chunk. With 100 ms there is a higher risk, but 
still lower than if packets were sent right after each other.
>
>  Some further timing tweaks could improve further. Most of the time 
> people don't type over each other so the need 
> for higher transmission rates would not be sustained and networks can 
> generally handle much higher rates if required.
>
Right, the mixer can be allowed to have a flexible transmission interval 
between e.g. 100 ms and 300 ms depending on the queues.


So, the very key to multi-party rtt is the capability negotiation and 
the acceptance of shorter transmission interval by multi-party capable 
UAs, while the performance increase by the CSRC-list is a good add-on.


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.
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

-- 

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

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