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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dale Worley via Datatracker
Martin Duke has entered the following ballot position for
draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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.

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.

- 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.



_______________________________________________
Audio/Video Transport Core Maintenance
[hidden email]
https://www.ietf.org/mailman/listinfo/avt
Reply | Threaded
Open this post in threaded view
|

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

Gunnar Hellström-2
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
> [hidden email]
> https://www.ietf.org/mailman/listinfo/avt

--
Gunnar Hellström
GHAccess
[hidden email]

_______________________________________________
Audio/Video Transport Core Maintenance
[hidden email]
https://www.ietf.org/mailman/listinfo/avt
Reply | Threaded
Open this post in threaded view
|

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

Gunnar Hellström-2
In reply to this post by Dale Worley via Datatracker
The new version mentioned in a recent mail answering the comments by
both Martin Duke and Lars Eggert is available.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-18.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-18


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/

Regards
Gunnar

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
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> 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.
>
> 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.
>
> - 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.
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [hidden email]
> https://www.ietf.org/mailman/listinfo/avt

--
Gunnar Hellström
GHAccess
[hidden email]

_______________________________________________
Audio/Video Transport Core Maintenance
[hidden email]
https://www.ietf.org/mailman/listinfo/avt
Reply | Threaded
Open this post in threaded view
|

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

Martin Duke
LGTM

On Mon, May 17, 2021 at 2:29 PM Gunnar Hellström <[hidden email]> wrote:
The new version mentioned in a recent mail answering the comments by
both Martin Duke and Lars Eggert is available.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-18.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-18


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/

Regards
Gunnar

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
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> 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.
>
> 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.
>
> - 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.
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [hidden email]
> https://www.ietf.org/mailman/listinfo/avt

--
Gunnar Hellström
GHAccess
[hidden email]


_______________________________________________
Audio/Video Transport Core Maintenance
[hidden email]
https://www.ietf.org/mailman/listinfo/avt