Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)

[Thomas Stach <[e-mail]>]

Mirja,

sorry for the loong delay in responding.

Based on your recommendation I'd re-write section 10.9 as follows

10.9.  Rate of INFO Requests

    Given that IP addresses may be gathered rapidly a Trickle ICE Agent
    with many network interfaces might create a high rate of INFO
    requests if every newly detected candidate is trickled individually
    without aggregation.

    Implementors MUST aggregate ICE candidates in
    case that UDP is used as transport protocol and send only one INFO
    request per estimated round-trip time (RTT). It is RECOMMENDED that
    Trickle ICE implementations also implement a way to estimate RTT,
    since [RFC8085] advises that application don't send UDP datagrams
    more often than one every 3 seconds if the RTT is unknown.

    If the INFO requests are sent on top of TCP, which is probably the
    standard way, this is not an issue for the network anymore, but it
    can remain one for SIP proxies and other intermediaries forwarding
    the SIP INFO messages.  Also, an endpoint may not be able to tell
    that it has congestion controlled transport all the way, such that
    the recommendations for UDP remain valid also in case of TCP.

Would that be aceptable?

Kind Regards
Thomas


On 2018-04-13 17:06, Mirja Kuehlewind (IETF) wrote:
> Hi again!
>
> I actually looked up the recommendation in RFC8085 section 3.1.3 which says:
>
> "A second case of applications cannot maintain an RTT estimate for
>         a destination, because the destination does not send return
>         traffic.  Such applications SHOULD NOT send more than one UDP
>         datagram every 3 seconds and SHOULD use an even less aggressive
>         rate when possible."
>
>> Am 08.04.2018 um 20:57 schrieb Thomas Stach <[e-mail]>:
>>
>> In general, it is RECOMMENDED that a Trickle ICE Agent sends only one INFO request per RTT.
>> A quarantine period of 100ms would be on the safe side, but lower values might be fine as well
>> if the typically deployment scenario assumes a shorter RT.“
> So a recommendation of 100ms is probably not appropriate here. Inline with RFC8085 it would be 3 seconds. Thus it probably makes sense to strongly recommend to implement a way to estimate RTT. Please also add a reference to RFC8085.
>
> Sorry for my late input. I should have double checked with RFC8085 earlier. I hope this can still be addressed appropriately.
>
> Mirja
>
>