Re: [MMUSIC] Trickle ICE

Dale,

this is an excellent analysis and I agree completely.

Regards
Thomas

Dale R. Worley wrote:
>> From: Alan Johnston <alan.b.johnston@gmail.com>
>> 
>> 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
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic