[MMUSIC] Trickle ICE

[[e-mail] (Dale R. Worley)]

> From: Alan Johnston <[e-mail]>
> 
> I admit that my first thought was that UPDATE was more appropriate than INFO. 
> 
> But the more I think about it, trickling in new candidates is not
> necessarily a part of O/A, rather it can be thought of as
> communication between two ICE Agents. For tunneling another protocol
> using SIP as transport, INFO is the right choice. 

Ah, yes, I now agree with that -- the trickle-ICE updates are "back
channel" amendments to the original offer/answer transfer, not
additional offer/answer transactions.

Within generic trickle ICE, there is the possibility that additional
candidates are provided "incrementally", that is, each protocol
message includes only the new candidates (and end-of-candidate
indications).  There is also the possibility that additional
candidates are provided "cumulatively", that is, each protocol message
includes all of the previously provided candidates.

We could specify that trickle ICE uses one method or the other, but I
think that we should consider these to be logically equivalent at the
level of generic trickle ICE, and allow the choice between methods to
be done by the usage.  The reason for this is that the decision of
method seems to be heavily dependent on the specifics of the usage.
(Allowing each usage to make its own choice requires that we not allow
cumulative updates to withdraw candidates previously offered, as that
functionality cannot be provided with incremental updates.)

For instance, if updates are carried by an ordered, reliable channel
like TCP, then there is no benefit in sending updates cumulatively.
Similarly if the SIP usage sends updates in UPDATE requests, because
the UAC must serialize UPDATE requests.  But if we carry updates in
INFO messages, and we wish to not require the UAC to serialize them,
then cumulative updates are desirable, as out-of-order receipt of INFO
messages can cause an earlier-sent INFO to be permanently blocked by a
later-sent INFO which reaches the UAS first.

This leads to the point that INFO is preferable to UPDATE because the
UAC does not have to serialize INFOs, which reduces blocking.  (As
Paul notes, we've done a lot of work to define how to properly handle
complex cases involving UPDATE, but that work is needed because
UPDATEs have to be serialized with respect to each other, and with
certain other requests.)

This leads to a broader issue:  Generic trickle ICE needs to define
its expectations regarding reliability, correlation, and sequencing of
updates.  If both generic ICE and its usages were defined in one I-D,
these issues would just be design considerations, but since the
generic specification and the usage specification are separate, these
issues are requirements defined in the generic ICE document and each
usage document has to show how it satisfies the requirements.  That's
hard to do if the requirements aren't explicitly stated.

In particular, if cumulative updating is used, and candidates are
allowed to be withdrawn, the receiver cannot determine wihch of two
updates is "newer" by inspection, updates need to be sequenced by the
transport mechanism.  If incremental updating is used, sequencing is
not relevant.  Similarly, if candidates cannot be withdrawn, the newer
of two cumulative updates has the larger candidate list.

Also, the updates need to be correlated with the "ICE negotiation
context", so if there is an ICE restart, any delayed updates for a
previous context that arrive can be recognized as such and ignored.

For the SIP usage, a considerable amount of sequencing and correlation
is provided by the CSeq values:  A trickle ICE update INFO must have a
CSeq higher than the message containing the offer/answer that started
the corresponding ICE context, and will have a CSeq lower than the
offer/answer that starts the next ICE context.  Similarly, CSeq
sequences INFOs.

Other usages may need other mechanisms to provide this information.

One matter that I haven't seen discussed is how trickle ICE ensures
that both UAs always test the same candidate pair at the same time.
Even if we assume that the transport of updates is quick and reliable,
slight differences in timing at the two UAs could cause them to choose
(at some moment) different pairs to test.  Since vanilla ICE seems to
have been constructed to prevent this, this seems to me that it might
be a problem and must be investigated and documented.

Dale