Subject: [Tsv-art] Tsvart last call review of draft-ietf-ice-pac-03

From: Yoshifumi Nishida via Datatracker <[email-masked]>
Date: Sun, 19 Jan 2020 00:56:50 -0800

Reviewer: Yoshifumi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

Summary:
   This document is straightforward and almost ready for publication,
   but it will be better to clarify the following points.

1: How to calculate the PAC timer is not very clear to me.
   Does this draft recommend to use the equation described in Section 14.3 of
   RFC8445 or are there other ways? I think this would be better to be
   clarified.

2: I presume this draft only focuses on UDP candidates, but I think clarifying
it would be useful.
   I am also wondering how to treat PAC timer if agents have a mix of TCP and
   UDP candidates.

Thanks,
--
Yoshi

---

From: Justin Uberti <[email-masked]>
Date: Sun, 19 Jan 2020 19:05:51 -0800

>    RFC8445 or are there other ways? I think this would be better to be

Yes, the equation in 14.3 coupled with the STUN backoff guidance in
https://tools.ietf.org/html/rfc5389#section-7.2, although these values are
just recommendations. The point here is to say that whatever is used for
the check timeouts should also be used for the PAC timer.

>    I am also wondering how to treat PAC timer if agents have a mix of TCP

The guidance here applies to both UDP and TCP candidates. It would not be
unheard of for a server to only offer TCP candidates, and the client to
offer zero candidates, as in S 3.1.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 20 Jan 2020 22:42:33 -0800

Hi Justin,

Thanks for the response.
I put my comments in lines.

On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti <[email-masked]> wrote:

> https://tools.ietf.org/html/rfc5389#section-7.2, although these values
> are just recommendations. The point here is to say that whatever is used
> for the check timeouts should also be used for the PAC timer.
>

Right. I was just wondering that it might be useful to mention the
recommended value can be calculated from the equation.
If the readers know what'll be the recommandation value, I think they can
have some ideas about whether their values are conservative or aggressive.

> offer zero candidates, as in S 3.1.

I see. But, in this case, will there be a need to update RFC6544?
Also, if we set PAC timer around 500 msec but establishing a TCP connection
takes longer than it, should it be considered failed or not?
--
Yoshi

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 Jan 2020 09:25:31 -0800

On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida <[email-masked]>
wrote:

> Also, if we set PAC timer around 500 msec but establishing a TCP
> connection takes longer than it, should it be considered failed or not?
>
> Given RTO floor of 500 ms and exponential backoff per 5389, the PAC timer
will typically be around 30 seconds. Perhaps a note to this effect would
clarify this and point #1.

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 21 Jan 2020 14:57:13 -0800

On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti <[email-masked]> wrote:

>>> The guidance here applies to both UDP and TCP candidates. It would not
>>> be unheard of for a server to only offer TCP candidates, and the client to

Sounds like an idea. I think it will be useful for readers to add a note
for it.
Thank you so much.
--
Yoshi

---

From: Justin Uberti <[email-masked]>
Date: Sat, 25 Jan 2020 17:09:04 -0800

Added the bolded text below. Full details at
https://github.com/ice-wg/draft-ice-pac/pull/20.

*The RECOMMENDED duration for the timer is equal to the agent'sconnectivity
check transaction timeout, including all retransmissions. *

*When using default values for RTO and Rc, this amounts to 39.5 seconds,*

*as explained in <xref target="RFC5389" />, Section 7.2.1.*
*This timeout value is chosen to roughly coincide with the maximum [...]*

On Tue, Jan 21, 2020 at 2:57 PM Yoshifumi Nishida <[email-masked]>
wrote:

>>> If the readers know what'll be the recommandation value, I think they
>>> can have some ideas about whether their values are conservative or
>>> aggressive.
>>>
>>>
>>>>
>>> Given RTO floor of 500 ms and exponential backoff per 5389, the PAC
>> timer will typically be around 30 seconds. Perhaps a note to this effect
>> would clarify this and point #1.
>>
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 28 Jan 2020 20:43:10 -0800

Hi Justin,

The text looks good to me. Thanks for updating.
--
Yoshi

On Sat, Jan 25, 2020 at 5:09 PM Justin Uberti <[email-masked]> wrote:

> *The RECOMMENDED duration for the timer is equal to the
> agent'sconnectivity check transaction timeout, including all
> retransmissions. *
>
>>>>> https://tools.ietf.org/html/rfc5389#section-7.2, although these
>>>>> values are just recommendations. The point here is to say that whatever is
>>>>> used for the check timeouts should also be used for the PAC timer.
>>>>>
>>>>