Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT)

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

Martin,

Thanks for the review,

Please see my responses inline.

Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker:
> Martin Duke has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - It is not completely clear to me what the actions in the case of congestion
> are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to 500ms. So
> what is the hiearchy here. My guess is:
>
> Step 1. Senders MUST go from 300ms to 2 seconds
> Step 2. Senders SHOULD (further?) limit the number of characters sent
> Step 3. Senders SHOULD go from 2 seconds to 5 seconds
> Step 4. Senders SHOULD exclude nodes from the session
>
> Is this correct?
>
> - Assuming it is correct, I don't understand the motivation behind the
> congestion considerations in Section 8.
>
> The first and third paragraphs make perfect sense to me. But if the total
> traffic to a receiver, regardless of the number of senders, remains limited to
> 1 packet / 300ms, I don't see why you would change the RFC 4103 guidance of
> 500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to be more
> conservative, but I would like to understand your reasoning.

[GH] First, I should clarify that the values are per source in the 
communication to one receiver.
You are right that it is not very logical to require an increase to a 
fixed time of 2 seconds. It does not help much, and the third action is 
anyway according to RFC 4103 an increase to an interval between 0.5 and 
5 seconds.

Therefore, I suggest to replace the second sentence of section 8, so 
that the section begins:

"The congestion considerations and recommended actions from [RFC4103]  
are also valid in multiparty situations.

The time values SHALL then be applied per source of text sent to a 
receiver."


>
> No need to reply to the comments below:
>
> - In (3.16) and (4.2.2), you mention various privacy-sensitive fields and then
> say "Integrity SHALL be considered..." I think you mean confidentiality?
> Integrity means the data hasn't been altered by an attacker.
[GH] Right, I meant "confidentiality". Modified.
>
> - It would be helpful to clarify in this draft that the CPS limit applies only
> to new, not redundant, text, assuming that is in fact the case.
[GH] Thanks, yes. I propose to insert the following sentence after the 
first sentence in section 3.22: "The actual rate is calculated without 
regard to any redundant text transmission and is in the multiparty case 
evaluated for all sources contributing to transmission to a receiver."

[GH] I will submit version -18 with the changes indicated above, 
together with edits because of Lars Eggert's nit findings, but am 
prepared to do further changes if needed on the congestion consideration 
wording.


Thanks,

Gunnar

>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
[e-mail]