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's
connectivity check transaction timeout, including all retransmissions.
connectivity 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 <nsd.ietf@xxxxxxxxx> wrote:
On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti <justin@xxxxxxxxxxx> wrote:On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida <nsd.ietf@xxxxxxxxx> wrote:Hi Justin,Thanks for the response.I put my comments in lines.On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti <justin@xxxxxxxxxxx> wrote:On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker <noreply@xxxxxxxx> wrote: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
tsv-art@xxxxxxxx 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.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.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.
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.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.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?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.Sounds like an idea. I think it will be useful for readers to add a note for it.Thank you so much..--Yoshi
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
