Subject: [MMUSIC] ICE-SIP-SDP: Question on ice-pacing attribute

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Jul 2019 14:02:53 +0000

Hi,

I have a couple of questions on the ice-pacing attribute. For some reason I have missed this earlier:

Q1:

Section 4.5 says:

   “Following the procedures defined in [RFC8445], a default value of
   50ms is used for an agent when the ice-pacing attribute is omitted in
   the offer or the answer.

   The same rule applies for ice-pacing attribute values lower than
   50ms.  This mandates that, if an agent includes the ice-pacing
   attribute, its value MUST be greater than 50ms or else a value of
   50ms is considered by default for that agent.”

I don’t understand the “the same rule applies” text. What rule? 8445 does not forbid values lower than 50 ms – it only defines 50 ms as the default value.

Q2:

The attribute is not mentioned in the offer/answer procedures, so it is unclear whether:

  *   It can be modified during the session
  *   Whether it should be included in subsequent offers/answers

Before I suggest text, my question is: do we allow modifying the pacing mid-session?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 17 Jul 2019 17:41:13 -0400

> Before I suggest text, my question is: do we allow modifying the pacing
We should allow modifying pacing attribute mid-session on ICE restart. Due
to 3PCC, a new end point might join the session without the prior knowledge
of the negotiated pacing value. In order to support this, changes in pacing
attribute in combination with ICE-restart must be supported. Changes of
pacing during ICE nomination process (i.e. without ICE restart) are
extremely hard to implement and should be prohibited.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Jul 2019 22:12:11 +0000

Hi,

> We should allow modifying pacing attribute mid-session on ICE restart. Due to 3PCC, a new end point
> might join the session without the prior knowledge of the negotiated pacing value. In order to support this,
> changes in pacing attribute in combination with ICE-restart must be supported. Changes of pacing during ICE
> nomination process (i.e. without ICE restart) are extremely hard to implement and should be prohibited.

If there is a subsequent offer/answer while the ICE processing is ongoing, and if we do NOT allow modifying the value (without ICE restart), we need to say how/of the attribute is included in such offer/answers. Are endpoint mandated to include the previously negotiated value?

And, what happens if an agent tries to modify the value (again, without ICE restart)?

Also, when reading Roman’s 3PCC use-case, I assume we need to specify the same for the ice-options attribute?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 17 Jul 2019 18:40:46 -0400

On Wed, Jul 17, 2019 at 6:12 PM Christer Holmberg <
[email-masked]> wrote:

> If there is a subsequent offer/answer while the ICE processing is ongoing,
> and if we do NOT allow modifying the value (without ICE restart), we need
> to say how/of the attribute is included in such offer/answers. Are endpoint
> mandated to include the previously negotiated value?
>

I would assume that the same values for pacing, ice-options, or ice-lite
should be included unless ICE restart was initiated.

> And, what happens if an agent tries to modify the value (again, without

Ignoring the change would be the safer option.

Also, when reading Roman’s 3PCC use-case, I assume we need to specify the
> same for the ice-options attribute?
>

I think this should apply to ice-options and ice-lite attributes as well.
Changing these values mid ICE nomination is not well defined and, most
likely, unnecessary.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jul 2019 06:18:16 +0000

So, it seems like we need some additional text regarding the attributes.

Roman, did you have any opinion regarding Q1, whether we should allow to indicate pacing values smaller than 50ms?

Regards,

Christer

Lähettäjä: Roman Shpount <[email-masked]>
Lähetetty: torstai 18. heinäkuuta 2019 1.41
Vastaanottaja: Christer Holmberg <[email-masked]>
Kopio: [email-masked]; [email-masked]
Aihe: Re: [MMUSIC] ICE-SIP-SDP: Question on ice-pacing attribute

I would assume that the same values for pacing, ice-options, or ice-lite should be included unless ICE restart was initiated.

I think this should apply to ice-options and ice-lite attributes as well. Changing these values mid ICE nomination is not well defined and, most likely, unnecessary.

Best Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 18 Jul 2019 18:03:03 -0400

On Thu, Jul 18, 2019 at 2:18 AM Christer Holmberg <
[email-masked]> wrote:

> Roman, did you have any opinion regarding Q1, whether we should allow to
> indicate pacing values smaller than 50ms?
>

This is a complicated question. On one hand this value was set to avoid
creating remote denial of service attacks using initial ICE connectivity
checks. On the other hand, this value might be too high.

So, my opinion that we should set the minimum pacing and ignore anything
smaller, but the value might be lower 50ms. I think 50 ms value was set to
avoid crashing a specific model of long deceased Linksys router. I remember
Cullen giving a presentation about lower pacing values a while back, so I
copied him on this email.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Jul 2019 22:09:05 +0000

Hi,

> This is a complicated question. On one hand this value was set to avoid creating remote denial of service attacks using
> initial ICE connectivity checks. On the other hand, this value might be too high.
>
> So, my opinion that we should set the minimum pacing and ignore anything smaller, but the value might be lower 50ms.
> I think 50 ms value was set to avoid crashing a specific model of long deceased Linksys router. I remember Cullen giving a
> presentation about lower pacing values a while back, so I copied him on this email.

50 ms is the recommended value – per ICE agent.

Note that an endpoint might have multiple agents – e.g., a browser with multiple tabs, each doing ICE – and in that case the combined pacing must not be smaller than 5 ms.

But, in any case, this draft is not the place to define pacing value limits – that belongs to RFC 8445.

Regards,

Christer