Re: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT)

[Peter Saint-Andre <[e-mail]>]

On 3/31/18 11:52 AM, Benjamin Kaduk wrote:
> On Thu, Mar 29, 2018 at 05:15:45PM -0600, Peter Saint-Andre wrote:
>> On 3/29/18 4:02 PM, Benjamin Kaduk wrote:
>>> On Thu, Mar 29, 2018 at 03:36:13PM -0600, Peter Saint-Andre wrote:
>>>> On 3/29/18 2:59 PM, Benjamin Kaduk wrote:

<snip/>

>>>>> Section 13 says that trickled candidate information may cause an ICE
>>>>> restart using the 5245bis semantics, but I don't see anywhere in
>>>>> 5245bis that would have additional candidate information induce a
>>>>> restart.  Is this the right reference?
>>>>
>>>> 5245bis states:
>>>>
>>>>    To restart ICE, an agent MUST change both the password and the
>>>>    username fragment for the data stream(s) being restarted.
>>>>
>>>> Such a change could be included when sending candidate information.
>>>
>>> Thanks for the clarification.  There is perhaps some subtle
>>> state-keeping requirement on implementations, then, as section 8 (of
>>> -18) notes:
>>>
>>>    Also, candidate trickling needs to be correlated to a specific ICE
>>>    session, so that if there is an ICE restart, any delayed updates for
>>>    a previous session can be recognized as such and ignored by the
>>>    receiving party.
>>>
>>> In that one needs to keep state in order to tell between ignoring
>>> delayed updates from a previous session and detecting a desire to
>>> start a new session.
>>
>> Yes, this is handled by ICE agents by tracking which ICE session is in
>> force (through the combination of Username Fragment and Password). I'm
>> not sure it's all so subtle, though.
> 
> I think it's a question of do you only keep one ufrag+password as
> state ("the current sesion"), or some level of history.  In the
> former case, you can't tell between a delayed packet coming in from
> an old session and a request to start a new one, IIUC.  So the
> subtlety would be if there is actually a requirement to track more
> history than just the current session.

Yes, this is something implementations need to handle (e.g., in order to
discard candidates from an old ICE session), but it seems to me they
could do so by knowing which ICE session is currently in force, not by
keeping a history of old sessions. In any case, this feels like an
implementation detail.

Peter