Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multi-party-rtt-mix-08.txt

From: James Hamlin <[email-masked]>
Date: Wed, 2 Sep 2020 10:39:15 +0000

Gunnar

I think the compromise in V08 is a good one; we have considered quite a few options, and allowing just one sender per packet, with a fixed limit of 1 on the CC field is the only solution that can be achieved with only a small change to RFC4103. We have to acknowledge that SSRC switching time increases as the level of redundancy increases. It also increases with more participants typing at once but people typing over one another is generally the smaller part of the conversation. These two caveats have previously been acknowledged.

Because redundant generations from one SSRC have to be cleared before another SSRC can be sent, recovery of redundant data is fairly simple. But working out which SSRC has missing text, is more difficult. The current text has a clear example where it is possible to verify that nothing is missing but it would be useful to have a defined algorithm so that implementations don't get that wrong. That said, there are a lot of cases to consider, and some error cases where the sender has not followed the rules. Perhaps we just accept that implementers must work this out for themselves.

Best regards

James

[X][X]

[X]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 <[email-masked]>
Date: Sun, 6 Sep 2020 10:08:50 +0200

James, thanks for the comment,

Den 2020-09-02 kl. 12:39, skrev James Hamlin:
>
> Gunnar
>
>
> I think the compromise in V08 is a good one; we have considered quite 
> a few options, and allowing just one sender per packet, with a fixed 
> limit of 1 on the CC field is the only solution that can be achieved 
> with only a small change to RFC4103.
>
Or it can even be seen as a clarification on the use of RFC 4103 for the 
multi-party case. Plus the added capability negotiation.
>
>  We have to acknowledge that SSRC switching time increases as the 
> level of redundancy increases. It also increases with more 
> participants typing at once but people typing over one another is 
> generally the smaller part of the conversation. These two caveats have 
> previously been acknowledged.
>
>
> Because redundant generations from one SSRC have to be cleared before 
> another SSRC can be sent, recovery of redundant data is fairly simple. 
> But working out which SSRC has missing text, is more difficult. The 
> current text has a clear example where it is possible to verify that 
> nothing is missing but it would be useful to have a defined algorithm 
> so that implementations don't get that wrong. That said, there are a 
> lot of cases to consider, and some error cases where the sender has 
> not followed the rules. Perhaps we just accept that implementers must 
> work this out for themselves.
>
Yes, the packet sequence example in section 2.1.23 is from a sequence 
where 3 sequential packets were lost and yet no text lost. It is quite 
easy to add more clear information about which cases of loss of 4 
packets in sequence can be totally recovered, and which cases of loss of 
three packets in sequence can be totally recovered. When there is 
resulting loss, it can not be deducted exactly from which source it was 
lost. In some cases there may be a high likelihood for being from a 
specific source, but I do not think that the specification should go 
into discussing such possibilities, just as RFC 4103 mentions the 
possible use of the M-bit for some more advanced loss evaluations 
without specifying exactly how.

Thanks for reviewing this section. Because of that I found an error. 
"A1" in the text under packet 6 in section 2.1.23 should be "A3".

Having a sender that does not follow the rules for redundancy 
composition can of course cause unexpected results, just as any protocol 
error. We cannot specify what kind of protocol errors the receiver must 
be able to handle. As usual, the implementer needs to take care that 
protocol errors do not cause dramatic failure situations.

It is complex to test a good variation of packet loss scenarios and it 
is strongly recommended that implementers create test material with 
known packet loss sequences so that the mechanisms for recovery and 
indication of loss can be tested and verified. But that is beyond what 
is expected from this draft.

Regards

Gunnar

> James Hamlin
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[email-masked]