Subject: [Ice] draft-trickle-11: Comment on section 15

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Jun 2017 08:34:07 +0000

Section 15

The text says:

 o  A signaling protocol MUST deliver each trickled candidate not more
      than once and in the same order it was conveyed (see Section 8).

- I think you should use MUST NOT deliver more than once terminology. “MUST … not more than” sounds strange.

- This may belong to MMUSIC, but draft-music-trickle-ice-sip defines that each each SIP INFO request (used to carry trickled candidates) contains all known candidates - including previously trickled ones. Is that aligned with the requirement above?

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Mon, 5 Jun 2017 21:59:29 +0200

Christer,

On 2017-06-05 10:34, Christer Holmberg wrote:
> *Section 15*
> *
> *
> - This may belong to MMUSIC, but draft-music-trickle-ice-sip defines 
> that each each SIP INFO request (used to carry trickled candidates) 
> contains all known candidates - including previously trickled ones. Is 
> that aligned with the requirement above?
The actual  text in section 4.2 of draft-music-trickle-ice-sip is as 
follows,
with "agent" meaning a SIP UA and "ICE agent" meaning the entity that 
actually deals with ICE:

    Since the agent is not fully aware of the state of the ICE
    Negotiation Session at its peer it MUST include all currently known
    and used local candidates in every INFO request.  I.e. all candidates
    that were previously sent under the same combination of "a=ice-pwd:"
    and "a=ice-ufrag:" need to be repeated.  Although repeating all
    candidates creates some overhead, it also allows easier handling of
    problems that could arise from unreliable transports, like e.g. loss
    of messages and reordering, which can be detected through the CSeq:
    header field in the INFO request.

    When receiving INFO requests carrying any candidates, agents will
    therefore first identify and discard the attribute lines containing
    candidates they have already received in previous INFO requests or in
    the Offer/Answer exchange preceding them.  Two candidates are
    considered to be equal if their IP address port, transport and
    component ID are the same.  After identifying and discarding known
    candidates, the ICE agents will then process the remaining, actually
    new candidates according to the rules described in
    [I-D.ietf-ice-trickle 
<https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-07#ref-I-D.ietf-ice-trickle>].

So, the requirement is covered by the second paragraph.

Regards
Thomas

>
> Regards,
>
> Christer
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Jun 2017 06:45:47 +0000

Hi Thomas,

The fact that the receiver discards the candidates doesn¹t change the fact
that they are *delivered* using the signaling protocol (SIP INFO).

So, rather than talking about the singling protocol, perhaps the
requirement should be that endpoint need to be able to detect repeated
candidates?

Regards,

Christer

On 05/06/17 22:59, "Ice on behalf of Thomas Stach" <[email-masked]
on behalf of [email-masked]> wrote:

>> - I think you should use MUST NOT deliver more than once terminology.
>> ³MUST Š not more than² sounds strange.
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Jun 2017 21:22:21 -0600

There are two delivery "levels" here:

(a) signaling-layer transport of a particular message (such as a SIP
INFO request or XMPP IQ stanza), which could include information about
one or more candidates

(b) semantic communication of a candidate, potentially across multiple
messages (as in the example from draft-ietf-mmusic-trickle-ice-sip)

As I understand it, this text in the trickle spec was meant to address
(a), not (b).

If we're talking about (a), then do people have concerns with specifying
that the signaling protocol needs to ensure in-order delivery and "at
most once" delivery? (Note that this could include things like acks and
retries as necessary in order to ensure delivery.)

If we're talking about (b), then we'd probably want to specify that the
signaling protocol needs to send each candidate "at least once", and
that endpoints need to detect duplicates.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Jun 2017 21:46:45 -0600

Does anyone have further input / insights on this topic? If not, I will
propose some textual clarifications.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 15 Jun 2017 06:20:37 +0000

Hi,

I was writing a reply earlier, but realised it got stucked in my Drafts
folder.

Before you suggest text, I have a couple of questions on Peter’s earlier
reply.

>> retries as necessary in order to ensure delivery.)

I am not sure whether we need to say “at most once”. Isn’t is enough to
say “ensure delivery”?

Why do we need to require in-order delivery?

>> that endpoints need to detect duplicates.

I think we could say that the signalling protocol needs to provide a
mechanism for the application to detect duplicates.

Regards,

Christer

>>>><https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-07#ref-I
>>>>-D.
>>>> ietf-ice-trickle>].
>>>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Jun 2017 14:58:57 -0600

> I am not sure whether we need to say “at most once”. Isn’t is enough to

That's probably fine. Some people care about "at most once" vs. "at
least once" (the former is a lot harder).

> Why do we need to require in-order delivery?

Because that enables the agents to figure out which version of the
candidate information is most current. If the initiator sends versions
A, B, and C of Candidate 1 in that order, but the responder receives
them in the order C, B, A, then confusion will result.

> mechanism for the application to detect duplicates.

De-duping is usually done in the user agent. I suppose you're saying
that the signalling protocol (e.g., the payload formats for candidate
information) need to provide unique identification of each candidate so
that the user agent is able to reliably perform de-duplication.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Jun 2017 18:52:05 -0600

> that the user agent is able to reliably perform de-duplication.

I've looked into this again. The current text in Section 8 reads:

   When candidates are trickled, each candidate MUST be delivered to the
   receiving Trickle ICE implementation not more than once and in the
   same order it was conveyed.  If the signaling protocol provides any
   candidate retransmissions, they need to be hidden from the ICE
   implementation.

Christer, can you live with that text?

If not, we could impose a less strict requirement on the signaling
protocol (i.e., "at least once" delivery and unique identification of
each instance of candidate information), but at the cost of more
complexity in the user agent (because it might need to perform
de-duplication).

Personally I don't see a compelling need to modify the existing text.

I've provisionally made fixes to all the other issues raised during WGLC
and can post version -12 as soon as we agree on this issue.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Jun 2017 06:58:10 +0000

Hi,

Š

>and can post version -12 as soon as we agree on this issue.

THAT text I am ok with :)

My issue was the requirement text. I don¹t think the requirement text is
aligned with the text above, because the requirement text explicitly talks
about the signalling protocol.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Jun 2017 16:04:59 -0600

> about the signalling protocol.

Section 15 "Requirements for Signaling Protocols" is our attempt to
capture in one place (for convenience) all the requirements that the
trickle method places on signaling protocols, and to point back from
there to the relevant sections in the specification.

I don't see a conflict between the text in Section 8:

And the text in Section 15:

Is your concern that the text in Section 8 uses the passive voice
whereas Section 15 explicitly mentions this as a requirement for the
signaling protocol? It's not clear to me what else provides delivery
services, if not the signaling protocol...

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jun 2017 12:36:10 -0600

> services, if not the signaling protocol...

Because the passive voice is confusing here in Section 8, I suggest that
we modify that text to read:

   When candidates are trickled, the signaling protocol MUST deliver
   each candidate to the receiving Trickle ICE implementation not more
   than once and in the same order it was conveyed.  If the signaling
   protocol provides any candidate retransmissions, they need to be
   hidden from the ICE implementation.

If you can't live with this text, please say so in the next ~24 hours.
Around that time I will submit version -12 to address WGLC feedback.

Thanks!

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Jun 2017 05:21:12 +0000

Hi,

>Around that time I will submit version -12 to address WGLC feedback.

I can live with the text.

Regards,

Christer

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Jun 2017 08:39:14 -0600

> I can live with the text.

OK, great. I'll wait until this evening in my timezone to publish -12.

Peter

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 22 Jun 2017 16:14:24 +0000

So this requirement means that for WebRTC, either this is a requirement on Javascript application implementors, or else JSEP will need some way of doing deduplication and loss detection. Are people okay with that?

> On Jun 22, 2017, at 1:21 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Jun 2017 14:59:25 -0600

> So this requirement means that for WebRTC, either this is a requirement on Javascript application implementors, or else JSEP will need some way of doing deduplication and loss detection. Are people…

I can't speak for JSEP, but if an application uses a signaling protocol
that doesn't provide in-order delivery then it will need to perform
de-duplication no matter what we say. Loss detection is a bit harder for
a single user agent to handle on its own.

The other approach we can take is to say SHOULD (not MUST) and then
describe what the user agent developer needs to consider if using a less
"robust" signaling protocol.

Peter

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Jun 2017 08:48:56 +0000

Hi,

Keep in mind that in-order delivery, loss detection and duplication are all separate things.

For example, with SIP trickle, core SIP provides certain mechanisms to help with in-order delivery (and you can improve that within the Info Package specification if needed), but the detection of candidate duplication will have to be taken care of the application - whatever that means in WebRTC.

Regards,

Christer

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: 23 June 2017 22:59
To: Jonathan Lennox <[email-masked]>; Christer Holmberg <[email-masked]>
Cc: Thomas Stach <[email-masked]>; [email-masked]
Subject: Re: [Ice] draft-trickle-11: Comment on section 15

> So this requirement means that for WebRTC, either this is a requirement on Javascript application implementors, or else JSEP will need some way of doing deduplication and loss detection. Are people…

I can't speak for JSEP, but if an application uses a signaling protocol that doesn't provide in-order delivery then it will need to perform de-duplication no matter what we say. Loss detection is a bit harder for a single user agent to handle on its own.

The other approach we can take is to say SHOULD (not MUST) and then describe what the user agent developer needs to consider if using a less "robust" signaling protocol.

Peter

>>>>>>  When candidates are trickled, each candidate MUST be delivered 
>>>>>> to the  receiving Trickle ICE implementation not more than once 
>>>>>> and in the  same order it was conveyed.  If the signaling 
>>>>>> If not, we could impose a less strict requirement on the 
>>>>>> signaling protocol (i.e., "at least once" delivery and unique 
>>>>>> identification of each instance of candidate information), but at 
>>>>>> the cost of more complexity in the user agent (because it might 
>>>>>> need to perform de-duplication).
>>>>>>
>>>>>> I've provisionally made fixes to all the other issues raised 
>>>>>> during WGLC and can post version -12 as soon as we agree on this 
>>>>>> issue.
>>>>>
>>>>>
>>>>> My issue was the requirement text. I don¹t think the requirement 
>>>>> text is aligned with the text above, because the requirement text 
>>>>> explicitly talks about the signalling protocol.
>>>>
>>>> capture in one place (for convenience) all the requirements that 
>>>> the trickle method places on signaling protocols, and to point back 
>>>> from there to the relevant sections in the specification.
>>>>
>>>> whereas Section 15 explicitly mentions this as a requirement for 
>>>> the signaling protocol? It's not clear to me what else provides 
>>>> delivery services, if not the signaling protocol...
>>>
>>> Because the passive voice is confusing here in Section 8, I suggest 
>>> that we modify that text to read:
>>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 25 Jun 2017 19:50:49 -0600

> Keep in mind that in-order delivery, loss detection and duplication

Agreed.

> For example, with SIP trickle, core SIP provides certain mechanisms
> to help with in-order delivery (and you can improve that within the
> Info Package specification if needed), but the detection of candidate
> duplication will have to be taken care of the application - whatever
> that means in WebRTC.

Yes, de-duplication is the responsibility of the user agent application.
All the signaling protocol needs to do in this context is provide a way
to identify a unique candidate so that the user agent has what it needs
to perform de-duplication.

Peter