Draft: draft-ietf-ice-pac

Commentary: You are right , eventhoug 8445 in some places do say " whenever Ta fires " . I 'll update the PR . I think it is much easier to talk about " timer  " than " the timer that does this and that " . For example , during the ICEbis work , we often talked about " timer Ta " . It may not sound like a big differnce at this point , when we are still working on the draft , but I think it will make a difference in the future when / if people start referring to the timer . 
 wdyt ? 
 I do n't think we need this , but if we want to name the timer , I would suggest : Call it " Tpac " and not " Timer Tpac " Not change so much of the existing text . Maybe put in the name ( for future conversations ) and just replace the once place where we say " the aforementioned timer " . 
 I initially did that , but Justin pointed out that , when comparing to Ta , Ta is just the interval used by a timer . I think that , when we talk about about a timer , we should use the name of the timer . 
 The first mentions of timers in 8445 says " The gathering process is controlled using a timer , Ta . Every time Ta expires " but then later is says " The generation of ordinary and triggered connectivity checks is governed by timer Ta " . So it looks like 8445 is n't self consistent . Meanwhile , we call the RTO timer " timer RTO " , so we do n't need the " Tfoo " model . How about we just call it " timer PAC " , or better yet " the PAC timer " ? 
 I left that part out on purpose :) The Terminology section uses " Timer Ta " , though . I want to have a timer name . As I indicated to Justin when we discussed this , it will make future discussions much easier , when we refer to the timer . It will also make life easier for implementers . What about using " timer  " in the first occurrence , and then " Tpac " ? BTW , if you are concerned about the number of changes in the PR , note that we have already merged a set of PRs , so the new version of the draft will contain changes from the current version no matter what . 
 I do n't see any reason to use the T prefix when always say " timer " along with it . It 's redundant . I 'd prefer " PAC timer or " timer PAC " . But I do n't care enough to keep talking about it . I 'd rather just pick something and move on . 
 I have no problem with " timer PAC " if you prefer that . All I want is a timer name that people can be refer to . 
 I think it 's very useful to have a name for the timer and both  and PAC timer work for me . 
 I will merge the pull request . There will still be time ( during WGLC , IESG review ) to fine tune the timer name , if there is a need to . 
 There ’s still more to do on the PR , but sounds like we have a path forward . 
 Ok , so I will not merge yet . 
 Updated the PR to use ' PAC timer ' , and only where necessary . I 'm happy with this if you are . 
 Looks good . 
 I think we should give the timer a name . Other ICE timers have names , and it also makes it easier to refer to it in future discussions , drafts , and implementations . I previously suggested  . Tupac would also be cool :) 
 I created a pull request for this , 
 Note that ' Ta ' in 8445 is the interval , not the timer . It uses ' timer Ta ' to refer to the actual timer . I 'm not sure this change is an improvement , but open to considering it . LGTM
Typically, when using ICE, endpoints will exchange candidate
addresses, form a list of candidate pairs, and then test each
candidate pair to see if connectivity can be established.  If the
test for a given pair fails, it is marked accordingly, and if all
pairs have failed, the overall ICE process is considered to have
failed.
When using ICE, endpoints will typically exchange ICE candidates,
form a list of candidate pairs, and then test each candidate pair to
see if connectivity can be established.  If the test for a given pair
fails, it is marked accordingly, and if all pairs have failed, the
overall ICE process typically is considered to have failed.
Even if the ICE agent provides candidates, they may be discarded by
the peer agent if it does not know what to do with them.  For
example, candidates may use an address family that the peer agent
does not support, (e.g., a host candidate with an IPv6 address in a
NAT64 scenario), or may not be usable for some other reason (e.g., a
candidate that contains a FQDN that fails to resolve).
Even if the ICE agent provides candidates, they may be discarded by
the peer agent if it does not know what to do with them.  For
example, candidates may use an address family that the peer agent
does not support, (e.g., a host candidate with an IPv6 address in a
NAT64 scenario), or may not be usable for some other reason.
In order to avoid the problem raised by this document, the ICE agent
needs to wait enough time to allow peer-reflexive candidates to be
discovered.  Accordingly, when a full ICE implementation begins its
ICE processing, as described in RFC8445, Section 6.1, it MUST set a
timer to ensure ICE will run for a minimum amount of time before
determining failure.
In order to avoid the problem raised by this document, the ICE agent
needs to wait enough time to allow peer-reflexive candidates to be
discovered.  Accordingly, when a full ICE implementation begins its
ICE processing, as described in RFC8445, Section 6.1, it MUST set a
timer, henceforth known as the PAC timer, to ensure ICE will run for
a minimum amount of time before determining failure.
Specifically, the ICE agent will start its timer once it believes ICE
connectivity checks are starting.  This occurs when the agent has
sent the values needed to perform connectivity checks (e.g., the
Username Fragment and Password denoted in RFC8445, Section 5.3) and
has received some indication that the remote side is ready to start
connectivity checks, typically via receipt of the values mentioned
above; note that receipt of an ICE candidate is not required.
Specifically, the ICE agent will start its timer once it believes ICE
connectivity checks are starting.  This occurs when the agent has
sent the values needed to perform connectivity checks (e.g., the
Username Fragment and Password denoted in RFC8445, Section 5.3) and
has received some indication that the remote side is ready to start
connectivity checks, typically via receipt of the values mentioned
above.  Note that the agent will start the timer even if it has not
sent or received any ICE candidates.
One consequence of this behavior is that in cases where ICE should
fail, e.g., where both sides provide candidates with unresolvable
FQDNs ICE will no longer fail immediately, and only fail when the
aforementioned timer expires.  However, because most ICE scenarios
require an extended period of time to determine failure, the fact
that some specific scenarios no longer fail fast should have minimal
application impact, if any.
One consequence of this behavior is that in cases where ICE should
fail, e.g., where both sides provide candidates with unsupported
address families, ICE will no longer fail immediately, and only fail
when the PAC timer expires.  However, because most ICE scenarios
require an extended period of time to determine failure, the fact
that some specific scenarios no longer fail fast should have minimal
application impact, if any.
Note also that the timer is potentially relevant to the ICE
nomination procedure described in RFC8445, Section 8.1.1.  That
specification does not define a minimum duration for ICE processing
prior to nomination of a candidate pair, but in order to select the
best candidate pair, ICE needs to run for enough time in order to
allow peer-reflexive candidates to be discovered and checked, as
noted above.  Accordingly, the controlling ICE agent SHOULD wait a
sufficient amount of time before nominating candidate pairs, and it
MAY use the timer described above to do so.  As always, the
controlling ICE agent retains full discretion, and MAY decide, based
on its own criteria, to nominate pairs prior to the timer elapsing.
Note also that the PAC timer is potentially relevant to the ICE
nomination procedure described in RFC8445, Section 8.1.1.  That
specification does not define a minimum duration for ICE processing
prior to nomination of a candidate pair, but in order to select the
best candidate pair, ICE needs to run for enough time in order to
allow peer-reflexive candidates to be discovered and checked, as
noted above.  Accordingly, the controlling ICE agent SHOULD wait a
sufficient amount of time before nominating candidate pairs, and it
MAY use the PAC timer to do so.  As always, the controlling ICE agent
retains full discretion, and MAY decide, based on its own criteria,
to nominate pairs prior to the timer elapsing.