From nobody Fri Jan 10 15:38:58 2020 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9483B12008C; Fri, 10 Jan 2020 15:38:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: adam@nostrum.com, ice-chairs@ietf.org, Nils Ohlmeier , draft-ietf-ice-pac@ietf.org, ice@ietf.org, nohlmeier@mozilla.com Content-Transfer-Encoding: 7bit Reply-To: last-call@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157869953053.13247.14567530289090042616.idtracker@ietfa.amsl.com> Date: Fri, 10 Jan 2020 15:38:50 -0800 Archived-At: Subject: [Ice] Last Call: (Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)) to Proposed Standard X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 23:38:51 -0000 The IESG has received a request from the Interactive Connectivity Establishment WG (ice) to consider the following document: - 'Interactive Connectivity Establishment Patiently Awaiting Connectivity (ICE PAC)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract During the process of establishing peer-to-peer connectivity, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur and proposes a way to avoid premature failure. This document updates RFC 8445 and RFC XXXX. [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of draft-ietf-ice-trickle once it has been published. Please also indicate that this specification updates RFC XXXX.] The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ice-pac/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ice-pac/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Jan 17 12:21:49 2020 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF181200E3; Fri, 17 Jan 2020 12:21:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: David Schinazi via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: David Schinazi Message-ID: <157929250406.20252.9598473217660353881@ietfa.amsl.com> Date: Fri, 17 Jan 2020 12:21:44 -0800 Archived-At: Subject: [Ice] Genart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 20:21:44 -0000 Reviewer: David Schinazi Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ice-pac-03 Reviewer: David Schinazi Review Date: 2020-01-17 IETF LC End Date: 2020-01-24 IESG Telechat date: Not scheduled for a telechat Summary: Document is delightfully short and to the point. I found it clear and well written. Major issues: None Minor issues: None Nits/editorial comments: None From nobody Sun Jan 19 00:57:03 2020 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9A120059; Sun, 19 Jan 2020 00:56:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoshifumi Nishida via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoshifumi Nishida Message-ID: <157942421019.19616.10503398711760845208@ietfa.amsl.com> Date: Sun, 19 Jan 2020 00:56:50 -0800 Archived-At: Subject: [Ice] Tsvart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 08:56:50 -0000 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@ietf.org 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 nobody Sun Jan 19 16:35:37 2020 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D976612001E; Sun, 19 Jan 2020 16:35:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rifaat Shekh-Yusef Message-ID: <157948053175.19616.12562131515450060047@ietfa.amsl.com> Date: Sun, 19 Jan 2020 16:35:31 -0800 Archived-At: Subject: [Ice] Secdir last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 00:35:32 -0000 Reviewer: Rifaat Shekh-Yusef Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. This document extends the existing ICE mechanism to allow the ICE agent to wait a bit longer to allow for the discovery of candidates by adding new timer to the ICE agent. The new timer does not change the existing operation of the ICE mechanism and has no security implications. From nobody Sun Jan 19 19:06:17 2020 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E74C120026; Sun, 19 Jan 2020 19:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vekr_PR05Jy1; Sun, 19 Jan 2020 19:06:09 -0800 (PST) Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57701120024; Sun, 19 Jan 2020 19:06:09 -0800 (PST) Received: by mail-lj1-f174.google.com with SMTP id w1so32247101ljh.5; Sun, 19 Jan 2020 19:06:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9p7MeptcT+0EvEFXEsbgpaHwXELh61K8VfGPs5seujA=; b=LEsuq19Xrvc9cbPThW4H9teYk0EoY1Uz0QNSwwYMt/cbzYjrEtz1zbP47eDkigu58R Cdeezw5MAy1ofIqwVO8NAAIKStksBSew972A3SUqUJ//ZHjQD78i7Z+0kyb2NKqBJfyD xtGOhHdCuf0gSXPN75230ABfCoaPQqasKNhlM4jLVE4LwKjmnyktf6540Nb2HKEWI5Z+ F9SNi4qO3Dz0Z2GW1y71MCFMJmR6NExq6YP1wrbIKTHxb8WUf7oFK1tKEYXj8SL2jVMc atBkoP6ccyzaPVK8OfkqYWEjX2bsYylwOBFuW/SuHrwvqvfb3nKnuw6EePMmzfCPx1ON lQWA== X-Gm-Message-State: APjAAAUXPr+yzehFanKrknDdp+PikHnYaiuqUZ0GcgZ4Rf47QWqHtn4K eNS/j+uNgUQekVy8P++afwiq4MfGN6lDCIYdIJU= X-Google-Smtp-Source: APXvYqzdipDKHptJEZKBm/4TJ+9RUPPAcxUiIeoCJD1Jfu1BpjsuR4fBzTTkV63ZA1lNSxGbQpsy1HCotmxuTGEIVtE= X-Received: by 2002:a2e:910b:: with SMTP id m11mr11840997ljg.213.1579489567342; Sun, 19 Jan 2020 19:06:07 -0800 (PST) MIME-Version: 1.0 References: <157942421019.19616.10503398711760845208@ietfa.amsl.com> In-Reply-To: <157942421019.19616.10503398711760845208@ietfa.amsl.com> From: Justin Uberti Date: Sun, 19 Jan 2020 19:05:51 -0800 Message-ID: To: Yoshifumi Nishida Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org Content-Type: multipart/alternative; boundary="000000000000968355059c89924d" Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 03:06:11 -0000 --000000000000968355059c89924d Content-Type: text/plain; charset="UTF-8" On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker < noreply@ietf.org> 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@ietf.org 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. > > 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. --000000000000968355059c89924d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jan 19, 2020 at 12:56 AM Yosh= ifumi Nishida via Datatracker <norep= ly@ietf.org> wrote:
Reviewer: Yoshifumi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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@ietf.org = if you reply to or forward this review.

Summary:
=C2=A0 =C2=A0This document is straightforward and almost ready for publicat= ion,
=C2=A0 =C2=A0but it will be better to clarify the following points.

1: How to calculate the PAC timer is not very clear to me.
=C2=A0 =C2=A0Does this draft recommend to use the equation described in Sec= tion 14.3 of
=C2=A0 =C2=A0RFC8445 or are there other ways? I think this would be better = to be
=C2=A0 =C2=A0clarified.

Yes, the equati= on in 14.3 coupled with the STUN backoff guidance in=C2=A0https://tools.ietf.org/html/rfc5= 389#section-7.2, although these values are just recommendations. The po= int here is to say that whatever is used for the check timeouts should also= be used for the PAC timer.

2: I presume this draft only focuses on UDP candidates, but I think clarify= ing
it would be useful.
=C2=A0 =C2=A0I am also wondering how to treat PAC timer if agents have a mi= x of TCP and
=C2=A0 =C2=A0UDP candidates.

The guidan= ce 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 can= didates, as in S 3.1.
=C2=A0
--000000000000968355059c89924d-- From nobody Mon Jan 20 22:42:58 2020 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6041B120071; Mon, 20 Jan 2020 22:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkyNkSPn2Gwd; Mon, 20 Jan 2020 22:42:45 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3E1120045; Mon, 20 Jan 2020 22:42:45 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id s16so1059663vsc.10; Mon, 20 Jan 2020 22:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W6BcBkK0XcRhVv/Fm9Wew32waehkWlhTX8Z4/G90I3A=; b=ZIiUb1PtLWC53oNKjXEXRodZY4FBX2RSOgCafGYjXy8LVAR50MlHAHnWX1PHZC3Xbd 3HXO2U481e8+Iyb3EJa1tpTstJlHpxWLOXBwo3tHuvKqq6JQrFiOgCCqE9hbIEsxQ46s lnfi+mLBdT4ew522vK5nJ/aM/0KOLeKBC676/3YuUj1PJyJ7YOjl/OSCRoF5rXy7K4ET rPKtpynzJeiX/LoP/H7JiEze7hkiu3xDFmsO2M1QOWTYM/8G5CDWpxnOdWlAHtJ3OU+J C935qrA1jD1tjp77cSCJjOsXLLmw3TAomvwuyhjnrV9iRnnC02DuRfzXPzC3L8TiT0vB yw2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W6BcBkK0XcRhVv/Fm9Wew32waehkWlhTX8Z4/G90I3A=; b=ieeryoYNn3Kc9eJ8aFJEa3RNZuONdlErIxvVtS4zHVtDrtC3exBq+/ELPk7pVJsU+4 eupvtzOSUi8ymnq51XhrsWeAMyhPXdobvpM3RQRYNL2Wm1PDwhIigL158mskcbNI6vAk KhsexkLY/AmQYmIOh31gQG1FizsLURv943VLF2FGyABfEG5zuLO2qvFQ/KE+zV8EG4qI +UPIfmjso6od5tNb1q2nvOT0t2CFlkUHoxKIv7zQrm/YMnx1ml0z38rXkM0bbzEqgBDY MXGs9w248B6TlaedspogrL/Ni9bgo5jVzS4yFyOBkMTWSvjljeZjp/bk/Ewp2p/7xDxp H7Bg== X-Gm-Message-State: APjAAAXSjwZbOs1eydlx1Ux+SrK5V9UnPtDQG1n63UEYLlT33xIIMGhl 1WGh7PBcIBPdN/krjZzgK4FUSZM0uw/YLHqmUPE= X-Google-Smtp-Source: APXvYqwiM9PU0vRItqgKAjWQMmjpPJDpcYUZtqNM6XtHhMGVIC+Inic0MJ88oJxiXQ9Ftp3nckiiOYELrnGQpOeIanM= X-Received: by 2002:a67:ec88:: with SMTP id h8mr1742839vsp.65.1579588964829; Mon, 20 Jan 2020 22:42:44 -0800 (PST) MIME-Version: 1.0 References: <157942421019.19616.10503398711760845208@ietfa.amsl.com> In-Reply-To: From: Yoshifumi Nishida Date: Mon, 20 Jan 2020 22:42:33 -0800 Message-ID: To: Justin Uberti Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org Content-Type: multipart/alternative; boundary="00000000000023cef6059ca0b7e2" Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 06:42:49 -0000 --00000000000023cef6059ca0b7e2 Content-Type: text/plain; charset="UTF-8" Hi Justin, Thanks for the response. I put my comments in lines. On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti wrote: > > > On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker < > noreply@ietf.org> 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@ietf.org 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? -- Yoshi --00000000000023cef6059ca0b7e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

Thanks for the re= sponse.
I put my comments in lines.

On Sun, Jan 19, 2020 at 7:06 P= M Justin Uberti <justin@uberti.nam= e> wrote:


On Sun, Jan 19, 2020 at 12:56 AM Yos= hifumi Nishida via Datatracker <noreply@ietf.org> wrote:
Reviewer: Yoshifumi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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@ietf.org = if you reply to or forward this review.

Summary:
=C2=A0 =C2=A0This document is straightforward and almost ready for publicat= ion,
=C2=A0 =C2=A0but it will be better to clarify the following points.

1: How to calculate the PAC timer is not very clear to me.
=C2=A0 =C2=A0Does this draft recommend to use the equation described in Sec= tion 14.3 of
=C2=A0 =C2=A0RFC8445 or are there other ways? I think this would be better = to be
=C2=A0 =C2=A0clarified.

Yes, the equati= on in 14.3 coupled with the STUN backoff guidance in=C2=A0https://tools.= ietf.org/html/rfc5389#section-7.2, although these values are just recom= mendations. The point here is to say that whatever is used for the check ti= meouts 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.=C2=A0
If the readers know what'll be the recommandation value, I thi= nk they can have some ideas about whether their values are conservative or = aggressive.
=C2=A0=C2=A0

2: I presume this draft only focuses on UDP candidates, but I think clarify= ing
it would be useful.
=C2=A0 =C2=A0I am also wondering how to treat PAC timer if agents have a mi= x of TCP and
=C2=A0 =C2=A0UDP candidates.

The guidan= ce 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 can= didates, as in S 3.1.
=C2=A0
I= see. But, in this case, will there be a need to update RFC6544?=C2=A0
Also, if we set PAC timer around 500 msec but establishing a TCP conn= ection takes longer than it, should it be considered failed or not?
--
Yoshi



--00000000000023cef6059ca0b7e2-- From nobody Tue Jan 21 09:25:56 2020 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBB9120979; Tue, 21 Jan 2020 09:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx5GzwCnoWZ9; Tue, 21 Jan 2020 09:25:49 -0800 (PST) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306EB120969; Tue, 21 Jan 2020 09:25:49 -0800 (PST) Received: by mail-lf1-f54.google.com with SMTP id z18so2974551lfe.2; Tue, 21 Jan 2020 09:25:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KmODlDqqB70uhLBo8j0ze1aZ3iCGUQ/D3GiDO+ARYJI=; b=hhfQax0sFkjk3k/6/fjce6Gzxt1gin2sHs5GhSQfoJEl8LjfL9jmmbxJNujoaHXGWv IjHTwn7lha0wvUBv3LzIa//xm1IbDuBG+1/Vj2f/Jq93F1VnrDtnAJKniRvqEy9GTmYy Vahv08DAE9kkDup9whTT4II2Q3TVSzqKHkGW995uGDpRjfFkAVmRBYuNFbLqQXILHq+6 5kNf7h4tyOlUFMvy5211hbqUcsNgNFheT7070mWYRuk4rt8q5H+UUjL3o9qU3wH0u20n l4uBq1YLq5ZxFZQkBjTYofkf61sz4FX1KMO29JQFxIYtNJvUy0rIqHNMvyAVtNvw5aM7 EbSw== X-Gm-Message-State: APjAAAU65Mqkw8dtvSWFIgEvVF30zMTg8TfsrocqLmGUBmUn/q++NNHc M4n/RtGEHhqyvMcBz+GiJ/2d2hPqLcQfsSb3UYQ= X-Google-Smtp-Source: APXvYqxFjlSFBD75NbpoKNkHavCliZoZCPCMrilThENkBl+vgz+mk8qpmZGK8indOBKVkpAv9mB0GB0UTN74KC9Ku7c= X-Received: by 2002:ac2:4adc:: with SMTP id m28mr3304688lfp.26.1579627547210; Tue, 21 Jan 2020 09:25:47 -0800 (PST) MIME-Version: 1.0 References: <157942421019.19616.10503398711760845208@ietfa.amsl.com> In-Reply-To: From: Justin Uberti Date: Tue, 21 Jan 2020 09:25:31 -0800 Message-ID: To: Yoshifumi Nishida Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org Content-Type: multipart/alternative; boundary="000000000000d436ef059ca9b2dd" Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 17:25:54 -0000 --000000000000d436ef059ca9b2dd Content-Type: text/plain; charset="UTF-8" On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida wrote: > Hi Justin, > > Thanks for the response. > I put my comments in lines. > > On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti wrote: > >> >> >> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker < >> noreply@ietf.org> 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@ietf.org 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. --000000000000d436ef059ca9b2dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 20, 2020 at 10:42 PM Yosh= ifumi Nishida <nsd.ietf@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">
Hi Justin,

Thanks for the res= ponse.
I put my comments in lines.

On Sun, Jan 19, 2020 at 7:06 PM= Justin Uberti <= justin@uberti.name> wrote:


On Sun, Jan 19, 202= 0 at 12:56 AM Yoshifumi Nishida via Datatracker <noreply@ietf.org> wrote:
Reviewer: Yoshifumi Nishida<= br> Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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@ietf.org = if you reply to or forward this review.

Summary:
=C2=A0 =C2=A0This document is straightforward and almost ready for publicat= ion,
=C2=A0 =C2=A0but it will be better to clarify the following points.

1: How to calculate the PAC timer is not very clear to me.
=C2=A0 =C2=A0Does this draft recommend to use the equation described in Sec= tion 14.3 of
=C2=A0 =C2=A0RFC8445 or are there other ways? I think this would be better = to be
=C2=A0 =C2=A0clarified.

Yes, the equati= on in 14.3 coupled with the STUN backoff guidance in=C2=A0https://tools.= ietf.org/html/rfc5389#section-7.2, although these values are just recom= mendations. The point here is to say that whatever is used for the check ti= meouts 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.=C2=A0
If the readers know what'll be the recommandation value, I thi= nk they can have some ideas about whether their values are conservative or = aggressive.
=C2=A0=C2=A0

2: I presume this draft only focuses on UDP candidates, but I think clarify= ing
it would be useful.
=C2=A0 =C2=A0I am also wondering how to treat PAC timer if agents have a mi= x of TCP and
=C2=A0 =C2=A0UDP candidates.

The guidan= ce 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 can= didates, as in S 3.1.
=C2=A0
I= see. But, in this case, will there be a need to update RFC6544?=C2=A0
Also, if we set PAC timer around 500 msec but establishing a TCP conn= ection takes longer than it, should it be considered failed or not?

Given RTO floor of 500 ms and ex= ponential backoff per 5389, the PAC timer will typically be around 30 secon= ds. Perhaps a note to this effect would clarify this and point #1.
--000000000000d436ef059ca9b2dd-- From nobody Tue Jan 21 14:57:40 2020 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B931200C3; Tue, 21 Jan 2020 14:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PQNejfkzKaF; Tue, 21 Jan 2020 14:57:25 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D79E12002E; Tue, 21 Jan 2020 14:57:25 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id b79so3007955vsd.9; Tue, 21 Jan 2020 14:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sDVFVFurxZggXiPh/Yht3crATUX1wVe8zRnh4KlqfuU=; b=CKNUFe/uykooREZ0ZzV1Thx8Bm1uIgsflcvXz0pJ/mENxUuvYaB2rxmQR2Me5mz5sm KdgONjhGlV/4AdJ9E6muS9lPGKbSYMB44fYpIRpPBm106Uh1Cc7o+mlWKZahjYcb3HL7 03cGpnwPHTta4kbTxOeTkE9JQpjRqgKkFYgJRhLodeXoU4MCicohrjTDCyMnz/qKga/D n37/DU66FBCMNHKimIKRJvovTpj/MADc5VTnV2GGfZ630ZlV3tLlQ2xdsfxEiHGQ6DZ0 iis9bs5wkPPC6KgPgI+mIc1zWyMCEVBbcvsjklNgXSCT4LzJXyBiIjae2EKVQz65cw6B VkTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sDVFVFurxZggXiPh/Yht3crATUX1wVe8zRnh4KlqfuU=; b=A6+KxlgZRj3vXLj5J1EYD5glN731UBS462jcNdm0pkKQ+dGEVld6waBo9gd9T8RNWj PzC+ZFy8iWEEv4TpgAqVGd/UCgQfNNzjz0FwrEauQrNIDkq3hO5cH1M9I9CbCCcbkW82 Ic3cytsPBahjjgAzvE5mTnYOGvf/65GTLpg4xXXZ1zedv9yVPTL+bD+QHmI/N1IHX58Z /aXYLdxCUP2NAUho8Vl0Qi6IpNOApFeyeIXxY+UzeC18RWbaewrKN+mJldJuRW1K8fi6 TTRuttiLmPQdjMihbSFa3US86sDN1nyEx7BJSCaeUZrOFw1I3eI0SyU7gMHAo4cmRs3x EFbQ== X-Gm-Message-State: APjAAAVQXDQMAXKrf3Xa48PDvZ/QVh3kWLHEQuwhovqHSbuLlnBdboqo AaQtgRTgNYgBn5tLIRIawSR/2xgbgIuSAEYQe7ltkQ== X-Google-Smtp-Source: APXvYqzSSST3sIV0x5dyQw4qmtIg2vW5cXxY8MT2CN1xAwcFA9syKK6gxw48X9tr48XudnbasKWRHRjqXRwe3HIcMOQ= X-Received: by 2002:a67:ec12:: with SMTP id d18mr825572vso.129.1579647444487; Tue, 21 Jan 2020 14:57:24 -0800 (PST) MIME-Version: 1.0 References: <157942421019.19616.10503398711760845208@ietfa.amsl.com> In-Reply-To: From: Yoshifumi Nishida Date: Tue, 21 Jan 2020 14:57:13 -0800 Message-ID: To: Justin Uberti Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org Content-Type: multipart/alternative; boundary="000000000000cc92ba059cae5486" Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 22:57:28 -0000 --000000000000cc92ba059cae5486 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti wrote: > > > On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida > wrote: > >> Hi Justin, >> >> Thanks for the response. >> I put my comments in lines. >> >> On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti wrote: >> >>> >>> >>> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker < >>> noreply@ietf.org> 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@ietf.org 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 --000000000000cc92ba059cae5486 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 21, 2020 at 9:25 AM Justi= n Uberti <justin@uberti.name&g= t; wrote:


On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi = Nishida <nsd.iet= f@gmail.com> wrote:
Hi Justin,

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

On Sun, Jan 19, 202= 0 at 7:06 PM Justin Uberti <justin@uberti.name> wrote:

<= br>
On Sun,= Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker <noreply@ietf.org> wrote:<= br>
Reviewer: Yoshif= umi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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@ietf.org = if you reply to or forward this review.

Summary:
=C2=A0 =C2=A0This document is straightforward and almost ready for publicat= ion,
=C2=A0 =C2=A0but it will be better to clarify the following points.

1: How to calculate the PAC timer is not very clear to me.
=C2=A0 =C2=A0Does this draft recommend to use the equation described in Sec= tion 14.3 of
=C2=A0 =C2=A0RFC8445 or are there other ways? I think this would be better = to be
=C2=A0 =C2=A0clarified.

Yes, the equati= on in 14.3 coupled with the STUN backoff guidance in=C2=A0https://tools.= ietf.org/html/rfc5389#section-7.2, although these values are just recom= mendations. The point here is to say that whatever is used for the check ti= meouts 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.=C2=A0
If the readers know what'll be the recommandation value, I thi= nk they can have some ideas about whether their values are conservative or = aggressive.
=C2=A0=C2=A0

2: I presume this draft only focuses on UDP candidates, but I think clarify= ing
it would be useful.
=C2=A0 =C2=A0I am also wondering how to treat PAC timer if agents have a mi= x of TCP and
=C2=A0 =C2=A0UDP candidates.

The guidan= ce 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 can= didates, as in S 3.1.
=C2=A0
I= see. But, in this case, will there be a need to update RFC6544?=C2=A0
Also, if we set PAC timer around 500 msec but establishing a TCP conn= ection takes longer than it, should it be considered failed or not?

Given RTO floor of 500 ms and ex= ponential backoff per 5389, the PAC timer will typically be around 30 secon= ds. Perhaps a note to this effect would clarify this and point #1.

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

=C2=A0
<= /div> --000000000000cc92ba059cae5486-- From nobody Sat Jan 25 17:09:30 2020 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3665120044; Sat, 25 Jan 2020 17:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaCHzjym3vfz; Sat, 25 Jan 2020 17:09:23 -0800 (PST) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36D912001E; Sat, 25 Jan 2020 17:09:22 -0800 (PST) Received: by mail-lj1-f182.google.com with SMTP id n18so6942232ljo.7; Sat, 25 Jan 2020 17:09:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PINoLnR0QXH7UsujdJPR7vmAbDWtj2JpKOx6P4aOdjI=; b=qIYp4vYxWqLoGuost+k4eRfdt9WqiyO8DR8u2aD7jcrRwTHR5I4uL6tj2e3TvoBZQm KD8zVBR2aacofp8JSQxDYakY9a9NcB7pI+EDGdgjtKXyiqLOy4lRmc0S+rZWUhW093Ro OOOV5f4f9et+IUviBVu7wfYEybGlXUH1sIsB0y6JMqXPRZ1ufLdRDAnEaOw5varJsTB9 SIjr7iKUIwWpMIFfwPZEclntMEW//DnpNpVVK6/4f2/VBYoDgX2FNN/d0G7QIXKOBj2Z FbsZ2Ab/O833tlDqXXIUabYoDBh2aafRkHUFlaxfixiPeXyTeJn6wbC9mjhaa388ETd4 QyaQ== X-Gm-Message-State: APjAAAU6M5AiG66wN1LoxWDzgXpm/LaQBh0fgvUs9bXST4r1d0V7WWoG FYS56jmR/QnQwnefbCcNYJWCVLKc7sh5ApQmcJA= X-Google-Smtp-Source: APXvYqy+mrkmb+LGMaShQZpoUbdWT/AZa4GNg4GNd/HC5/RS4fPkb7ADM20O9bphz0QDWa3UIv35gBZO1uyncCwu+/w= X-Received: by 2002:a2e:844e:: with SMTP id u14mr6239064ljh.183.1580000960969; Sat, 25 Jan 2020 17:09:20 -0800 (PST) MIME-Version: 1.0 References: <157942421019.19616.10503398711760845208@ietfa.amsl.com> In-Reply-To: From: Justin Uberti Date: Sat, 25 Jan 2020 17:09:04 -0800 Message-ID: To: Yoshifumi Nishida Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org Content-Type: multipart/alternative; boundary="00000000000005ffc9059d00a484" Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jan 2020 01:09:25 -0000 --00000000000005ffc9059d00a484 Content-Type: text/plain; charset="UTF-8" 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 , 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 wrote: > > > On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti wrote: > >> >> >> On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida >> wrote: >> >>> Hi Justin, >>> >>> Thanks for the response. >>> I put my comments in lines. >>> >>> On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti >>> wrote: >>> >>>> >>>> >>>> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker < >>>> noreply@ietf.org> 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@ietf.org 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 > > > --00000000000005ffc9059d00a484 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Added the bolded text below. Full details at=C2=A0https://github.com= /ice-wg/draft-ice-pac/pull/20.

The RECOMMEN= DED duration for the timer is equal to the agent's
connectivity chec= k transaction timeout, including all retransmissions.=C2=A0
<= /div>
When using default values for RTO and Rc, this amounts to 3= 9.5 seconds,
as explained in <xref target=3D= "RFC5389" />, Section 7.2.1.
This tim= eout value is chosen to roughly coincide with the maximum [...]


On Tue, Jan 21, 2020 at 2:57 PM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:


On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti <justin@uberti.name>= wrote:


On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Ni= shida <nsd.ietf@= gmail.com> wrote:
Hi Justin,

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

On Sun, Jan 19, 202= 0 at 7:06 PM Justin Uberti <justin@uberti.name> wrote:

<= br>
On Sun,= Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker <noreply@ietf.org> wrote:<= br>
Reviewer: Yoshif= umi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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@ietf.org = if you reply to or forward this review.

Summary:
=C2=A0 =C2=A0This document is straightforward and almost ready for publicat= ion,
=C2=A0 =C2=A0but it will be better to clarify the following points.

1: How to calculate the PAC timer is not very clear to me.
=C2=A0 =C2=A0Does this draft recommend to use the equation described in Sec= tion 14.3 of
=C2=A0 =C2=A0RFC8445 or are there other ways? I think this would be better = to be
=C2=A0 =C2=A0clarified.

Yes, the equati= on in 14.3 coupled with the STUN backoff guidance in=C2=A0https://tools.= ietf.org/html/rfc5389#section-7.2, although these values are just recom= mendations. The point here is to say that whatever is used for the check ti= meouts 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.=C2=A0
If the readers know what'll be the recommandation value, I thi= nk they can have some ideas about whether their values are conservative or = aggressive.
=C2=A0=C2=A0

2: I presume this draft only focuses on UDP candidates, but I think clarify= ing
it would be useful.
=C2=A0 =C2=A0I am also wondering how to treat PAC timer if agents have a mi= x of TCP and
=C2=A0 =C2=A0UDP candidates.

The guidan= ce 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 can= didates, as in S 3.1.
=C2=A0
I= see. But, in this case, will there be a need to update RFC6544?=C2=A0
Also, if we set PAC timer around 500 msec but establishing a TCP conn= ection takes longer than it, should it be considered failed or not?

Given RTO floor of 500 ms and ex= ponential backoff per 5389, the PAC timer will typically be around 30 secon= ds. Perhaps a note to this effect would clarify this and point #1.

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

=C2=A0
<= /div>
--00000000000005ffc9059d00a484-- From nobody Tue Jan 28 20:43:27 2020 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C0C120142; Tue, 28 Jan 2020 20:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6O0IGpRLp2x; Tue, 28 Jan 2020 20:43:22 -0800 (PST) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF712120130; Tue, 28 Jan 2020 20:43:22 -0800 (PST) Received: by mail-vs1-xe36.google.com with SMTP id 7so1060297vsr.10; Tue, 28 Jan 2020 20:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Enf6XiIwzXArLPsNO3kGgwmt61uzDpl1xdZ1bSYEfVQ=; b=DknBvNvBlm1vwQr7P5Rn33NUHJMHHsuAB/0Zi4crvpPuXiX+HicgSgy8y89LWzPD3Q 9zINDkMKHsOe/kNH5Niget13mhoBr9pBK7Hnw1Ys80p8DrD+zJLNJim+AY68WPTrpQGj fiJu3KiUi/kkPNWyuPm7hkRB3PFVvyrC2hP8V+hDAG40LxJp+P7b3LT35Saip42yHQZl kz/Ippg3Qwq779R7on3jkIAzxC+E/I6Kifz4ota16PZVCoNwKV+6Rjt9dt85Q8vcLFYJ 9AM9ctABbS4eW0X1PJ20/aQhJi6v4huSKP+CcvXo3boo4q/j6uvXIrqErw65+Pw6nHwf Dq0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Enf6XiIwzXArLPsNO3kGgwmt61uzDpl1xdZ1bSYEfVQ=; b=orVFRflNkY/EhkoeupgzNhoamugkq5EMMu+xkXTjl7nUKdBnayccL9+CPTXYCyFpzY UzQ6gn9kjeOI/2wz2P80CAZKLk1i8oq123tzxB9nRA8yPrYqp0QEEhAS5lHrEwIdEQzB 1hwBmxKv35/VzuW58MubnfZavnu8kaS6no4J7BUOSi5rgKAT9e0JHPlm+n8xB/0sLHYp OPO4sNDFSRBhm2NQAJ2hOsvWG9LVy7uvHTD38e7NoC7S7TuCxjw/1dnyy+AGorKDaPPI 3W7tCYrd5d5CPu/XKwbysBUsEhfRk6MacTC+ND4r0adZ6KeyVefQ6pkMIQHMTI9qj3E2 b9yA== X-Gm-Message-State: APjAAAXZD2w1yiCwOVX5WUcImvSLtl+OnTZ/l66duPn8bmlMn+RNU9xe Rt4dBc9I0NUHQENHMiwZrjM38xMWHc5dRu+RVO4= X-Google-Smtp-Source: APXvYqyjS0WzcH7XcPfJD7GOgF2Owm4UmkFhoMBJrz8DwuFzIMzdBcUL7Q+0lLPUetQMlhXf1IUg6rdMtFjR11ykddA= X-Received: by 2002:a67:ec12:: with SMTP id d18mr15972577vso.129.1580273001857; Tue, 28 Jan 2020 20:43:21 -0800 (PST) MIME-Version: 1.0 References: <157942421019.19616.10503398711760845208@ietfa.amsl.com> In-Reply-To: From: Yoshifumi Nishida Date: Tue, 28 Jan 2020 20:43:10 -0800 Message-ID: To: Justin Uberti Cc: tsv-art@ietf.org, last-call@ietf.org, draft-ietf-ice-pac.all@ietf.org, ice@ietf.org Content-Type: multipart/alternative; boundary="000000000000ec88a4059d3ffa5e" Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-pac-03 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jan 2020 04:43:25 -0000 --000000000000ec88a4059d3ffa5e Content-Type: text/plain; charset="UTF-8" Hi Justin, The text looks good to me. Thanks for updating. -- Yoshi On Sat, Jan 25, 2020 at 5:09 PM Justin Uberti wrote: > 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 , 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 > wrote: > >> >> >> On Tue, Jan 21, 2020 at 9:25 AM Justin Uberti wrote: >> >>> >>> >>> On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida >>> wrote: >>> >>>> Hi Justin, >>>> >>>> Thanks for the response. >>>> I put my comments in lines. >>>> >>>> On Sun, Jan 19, 2020 at 7:06 PM Justin Uberti >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sun, Jan 19, 2020 at 12:56 AM Yoshifumi Nishida via Datatracker < >>>>> noreply@ietf.org> 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@ietf.org 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 >> >> >> > --000000000000ec88a4059d3ffa5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Justin,

The text looks go= od to me. Thanks for updating.
--
Yoshi
On Sat, = Jan 25, 2020 at 5:09 PM Justin Uberti <justin@uberti.name> wrote:
Added the bolded text below. F= ull details at=C2=A0https://github.com/ice-wg/draft-ice-pac/pull/20.=

The RECOMMENDED duration for the timer is equa= l to the agent's
connectivity check transaction timeout, including a= ll retransmissions.=C2=A0
When using default= values for RTO and Rc, this amounts to 39.5 seconds,
as explained in <xref target=3D"RFC5389" />, Section= 7.2.1.
This timeout value is chosen to roughly co= incide with the maximum [...]


On Tue, Jan 21, 2= 020 at 2:57 PM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:

<= /div>
O= n Tue, Jan 21, 2020 at 9:25 AM Justin Uberti <justin@uberti.name> wrote:


On Mon, Jan 20, 2020 at 10:42 PM Yoshifumi Nishida <nsd.ietf@gmail.com>= wrote:
Hi Justin,

Thanks for the response.<= /div>
I put my comments in lines.

<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 19, 2020 at 7:06 PM Justin= Uberti <justin@= uberti.name> wrote:


On Sun, Jan 19, 2020 at 12= :56 AM Yoshifumi Nishida via Datatracker <noreply@ietf.org> wrote:
Reviewer: Yoshifumi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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@ietf.org = if you reply to or forward this review.

Summary:
=C2=A0 =C2=A0This document is straightforward and almost ready for publicat= ion,
=C2=A0 =C2=A0but it will be better to clarify the following points.

1: How to calculate the PAC timer is not very clear to me.
=C2=A0 =C2=A0Does this draft recommend to use the equation described in Sec= tion 14.3 of
=C2=A0 =C2=A0RFC8445 or are there other ways? I think this would be better = to be
=C2=A0 =C2=A0clarified.

Yes, the equati= on in 14.3 coupled with the STUN backoff guidance in=C2=A0https://tools.= ietf.org/html/rfc5389#section-7.2, although these values are just recom= mendations. The point here is to say that whatever is used for the check ti= meouts 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.=C2=A0
If the readers know what'll be the recommandation value, I thi= nk they can have some ideas about whether their values are conservative or = aggressive.
=C2=A0=C2=A0

2: I presume this draft only focuses on UDP candidates, but I think clarify= ing
it would be useful.
=C2=A0 =C2=A0I am also wondering how to treat PAC timer if agents have a mi= x of TCP and
=C2=A0 =C2=A0UDP candidates.

The guidan= ce 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 can= didates, as in S 3.1.
=C2=A0
I= see. But, in this case, will there be a need to update RFC6544?=C2=A0
Also, if we set PAC timer around 500 msec but establishing a TCP conn= ection takes longer than it, should it be considered failed or not?

Given RTO floor of 500 ms and ex= ponential backoff per 5389, the PAC timer will typically be around 30 secon= ds. Perhaps a note to this effect would clarify this and point #1.

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

=C2=A0
<= /div>
--000000000000ec88a4059d3ffa5e--