Re: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5)

[Christer Holmberg <[e-mail]>]

Hi,

>So basically add that it should be evenly distributed to avoid starving one check list?

Correct.

>That sounds good to me.  Just make sure you don't have 101 check lists :).

In normal cases I guess we’d be nowhere near 100, but note that if we have separate check lists for RTP and RTCP (see your other e-mail) we are talking about 50 RTP/RTCP (non-mused) flows – which still is a very big number.

Regards,

Christer






On Sun, May 28, 2017 at 11:13 PM Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

> - If we remove lower-priority candidate pairs across check lists, what
>happens if a certain check list is starved because all of its candidate
>pairs are lower priority?
> One option might be to say the limit is per check list.  Another is to
>recognise that it might happen but live with it.

My understanding was always that the limit is per check list, but I agree
it may not be very clear.

Perhaps we could modify the text as below:

   In order to limit the attacks described in Section 15.4.1, an agent
   MUST limit the total number of connectivity checks the agent performs
   across all CHECK LISTs to a specific value, and this value MUST be
   configurable. A default of 100 is RECOMMENDED.  This limit is
   enforced by, within each CHECK LIST, discarding the lower-priority
candidate
   pairs of that CHECK LIST, until there are less than a total of 100
candidate
   pairs in the CHECK LIST SET. The discarding of candidate pairs SHOULD be
   distributed equally throughout the CHECK LISTs in the CHECK LIST SET.


Regards,

Christer