Subject: Re: [Ice] Trickle ICE and ICE restarts

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Feb 2016 21:05:21 -0700

On 1/6/16 9:38 AM, Jonathan Lennox wrote:
>
>> On Jan 6, 2016, at 11:21 AM, 🔓Dan Wing <[email-masked]> wrote:
>>
>>
>> On 06-Jan-2016 06:51 am, Jonathan Lennox <[email-masked]> wrote:
>>>
>>>>
>>>> On Jan 5, 2016, at 6:29 PM, 🔓Dan Wing <[email-masked]> wrote:
>>>>
>>>>
>>>> On 05-Jan-2016 01:38 pm, Jonathan Lennox <[email-masked]> wrote:
>>>>>
>>>>>> On Jan 5, 2016, at 4:05 PM, Peter Saint-Andre <[email-masked]> wrote:
>>>>>>
>>>>>> A few months ago, Emil Ivov and I chatted off-list about how to specify the handling of ICE restarts in the context of Trickle ICE. As I recall the conversation, we thought that one possible approach would be to send a new ufrag and pwd without triggering a full offer/answer exchange. This should be OK because Trickle (and ICE itself) can be used with application protocols that are not tied to O/A. Although there is an SDP dependency because of the syntax of the a= line, we have disengaged Trickle ICE from SDP, so that shouldn't be a deciding factor, either. Also, if the sender doesn't include a media description then a new offer might not be necessary anyway.
>>>>>>
>>>>>> Do WG participants feel this is something we should cover in one of our documents? If so, does it belong in the Trickle spec or in ICEbis?
>>>>>
>>>>> As I mentioned in Yokohama, one issue that'll need to be addressed if we support this is how the protocol ensures that the two ICE agents agree on how the agents’ respective ICE restart “generations” (i.e., ufrag / password sets) correspond to each other.  Offer / answer guarantees this, but other protocols don’t. (This is in fact a problem that we’ve seen in practice, when torture-testing ICE restarts on Jingle.)
>>>>>
>>>>> This is an issue for “base ICE”, and I think we vaguely said it was a problem for the Using protocol, but it becomes much more concrete a problem with Trickle.
>>>>>
>>>>> One solution (that Justin proposed, I think) would be to not *require* that the generations match up — allow checks to be done against multiple generations at once. This is a pretty big conceptual change to ICE’s model, though.
>>>>>
>>>>> To recap, the problem we saw was:
>>>>>
>>>>> * Agent A sends ICE restart A1, with a new ufrag and password compared to its previous messaging, and some candidates.
>>>>> * Agent A sends *another* ICE restart A2, with another new ufrag, password, and candidates.
>>>>> * Agent A receives an ICE message B1, with a previously-unseen ufrag and password, and a set of candidates.
>>>>>
>>>>> Should A expect to receive the ufrag it found out about in B1 on the candidates it put in A1, or on those in A2?  Should it send checks to the B1 candidates from its A1 candidates, or from its A2 candidates?
>>>>
>>>> I like Justin's approach, to not require the generations to match up.  A refinement is that when Agent A decided to send its second restart, A2, it move all of the candidates it had from A1 to a lower priority (below all of its A2 candidates) in its internal ICE priority list.  It does that de-prioritization whenever it does a restart.  That allows B to respond to previous ICE starts/restarts/re-restarts, so connectivity can be established.  But if connectivity can be established over higher-priority paths (belonging to more recent restarts), those more recent paths are preferred.  This also provides an answer to your final question, which is that A should send its checks from its A2 candidates, as the A1 candidates are very low priority.
>>>
>>> The difficulty with this is that at the time Agent B sent B1, it presumably hadn’t yet received A2 — it sent B1 in response to A1. So it won’t know the B2 ufrag or password, and won’t start opening pinholes toward the B2 candidates.
>>>
>>> If you knew explicitly that B1 was in response to A1, there wouldn’t be any ambiguity.  This is what offer/answer gives you.  Is there any way we can achieve that property without having the other limitations of offer/answer?
>>
>> Would introducing a new STUN attribute (and SDP) for Generation Number (as Peter described in his email), but keeping the ufrag and password the same for the duration of the session, get us to a happy place?  I mean today we're using a new ufrag (and password) to indicate "ICE restart", but we're really trying to do something that is not a full ICE restart (that is, the previous candidates may well still be working fine and media flowing, but we are trying to see if new candidates work better).
>
> Generation number would be useful (and Jingle has it), but it’s not sufficient for this problem.  What you really need is something like “remote generation number”, giving the peer’s generation that your generation is paired with (if any).  This is the semantic that offer/answer transactions give you implicitly — the SDP in the INVITE and the SDP in the 200/1xx are naturally associated.

I'd always thought that was the intent of generation: a method for 
keeping the parties in sync about which version of the candidate (or 
candidate-set) is in play right now. My reading of your remark is that 
the parties could get out of sync regarding generations, which seems 
avoidable if generation is signaled as Peter Thatcher described.

Sorry about the delayed reply.

Peter