Draft: draft-ietf-ice-pac

Commentary: Would have liked this to wait for a review before merging
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.
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 updates
RFC8445 and RFC XXXX by requiring that an ICE agent wait a minimum
amount of time before declaring ICE failure, even if there are no
candidate pairs left to check.
It is entirely legal for an ICE agent to provide zero candidates of
its own.  If the agent somehow knows that the remote endpoint is
directly reachable, gathering local candidates is unnecessary and
will only cause delays; the peer agent can discover the appropriate
local candidate via connectivity checks.
Per RFC XXXX, an ICE agent could provide zero candidates of its own.
If the agent somehow knows that the remote endpoint is directly
reachable, gathering local candidates is unnecessary and will only
cause delays; the peer agent can discover the appropriate local
candidate via connectivity checks.
While the timer is running, the ICE agent MUST NOT set the state of a
checklist to Failed, even if the checklist has no pairs left to
check.  As a result, the ICE agent will not remove any data streams
or set the state of the ICE session to Failed as long as the timer is
running.
When the timer eventually elapses, the ICE agent MUST resume typical
ICE processing, including setting any checklists containing only
Failed pairs to the Failed state, as usual, and handling any
consequences as indicated in RFC8445, Section 8.1.2.  Naturally, if
there are no such checklists, no action is necessary.
While the timer is still running, the ICE agent MUST NOT update a
checklist state from Running to Failed, even if there are no pairs
left in the checklist to check.  As a result, the ICE agent will not
remove any data streams or set the state of the ICE session to Failed
as long as the timer is running.  As a result, the ICE agent will not
remove any data streams or set the state of the ICE session to Failed
as long as the timer is running.
When the timer eventually elapses, the ICE agent MUST resume typical
ICE processing, including setting the state of a checklist to Failed
if there are no pairs left to check, and handling any consequences as
indicated in RFC8445, Section 8.1.2.  Naturally, if there are no such
checklists, no action is necessary.
to nominate pairs prior to the timer elapsing.
to nominate pairs prior to the PAC timer elapsing.
Note also that sending an end-of-candidates indication is only a
SHOULD-strength requirement, which means that ICE agents will need to
implement an backup mechanism to decide when all candidates have been
received, typically a timer.  Accordingly, ICE agents MAY use the PAC
timer to also serve as an end-of-candidates fallback.
Note also that sending an end-of-candidates indication is only a
SHOULD-strength requirement, which means that ICE agents will need to
implement a backup mechanism to decide when all candidates have been
received, typically a timer.  Accordingly, ICE agents MAY use the PAC
timer to also serve as an end-of-candidates fallback.