Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-14 review

[Ari Keranen <[e-mail]>]

Hi Magnus,

On 12/19/12 3:09 PM, Magnus Westerlund wrote:
> Ari,
>
> Thanks for keep following up on this. Please see below.

No problem! Comments inline.

> On 2012-12-18 13:43, Ari Keranen wrote:
>> On 12/17/12 6:07 PM, Magnus Westerlund wrote:
>>> On 2012-12-17 16:36, Ari Keranen wrote:
>>>> On 12/6/12 5:03 PM, Magnus Westerlund wrote:
>>>>> On 2012-12-05 22:22, Ari Keranen wrote:
>> [...]
>>>>>>       Aggressive nomination SHALL be used with RTSP.  This doesn't have
>>>>>> the
>>>>>>       negative impact that it has in offer/answer as media playing only
>>>>>>       starts after issuing a PLAY request.
>>>>>>
>>>>>> But it does have the downside of possibly selecting a lower-priority
>>>>>> pair due to single dropped (e.g., due to congestion) connectivity
>>>>>> check
>>>>>> message for a higher priority pair. That said, probably SHALL is
>>>>>> appropriate here, just wanted to make sure the implications are
>>>>>> understood.
>>>>>
>>>>> Yes, but with ICE-RTSP you will retransmit the higher priority also,
>>>>> thus if that works and you get a response that alternative is nominated
>>>>> and will be used. But we probably should clarify what it means when
>>>>> multiple candidate pairs are nominated, and in worse case the server
>>>>> will use different paths for different media streams.
>>>>
>>>> According to ICE RFC, if multiple pairs end up nominated due to
>>>> aggressive nomination, the highest priority one will be used (you get
>>>> some transient behavior).
>>>>
>>>> But do you mean that you will keep retransmitting on a higher priority
>>>> pair even if a lower priority pair has been (aggressively) selected and
>>>> all check lists are in Completed state?
>>>
>>> I guess this needs to be expanded a bit. What I mean is that if due to
>>> some reason one get a lower prioritized pair to respond and then get an
>>> answer from the more prioritized then it actually makes sense to unlock
>>> the full checklist for the more prioritized and let it run to completion
>>> prior to sending the PLAY request.
>>
>> By unlocking checklist, do you mean moving it from Completed back to
>> Running state and continuing all running checks (until when)? And in the
>> case you mention above, both candidates are in the same check list, right?
>>
>> Anyway, it would be good to clarify this.
>
> I have produced a bit of new text. However, having thought about this I
> don't want to make any change to the ICE procedures as that could easily
> introduce issues and makes the changes for ICE-RTSP even bigger. Instead
> I propose that we change the SHALL to a SHOULD so that client
> implementations that see issues with using aggressive nomination can
> select to do regular nomination instead and always accept a bit more
> delay instead of possibly ending up with different network paths between
> different media resources SETUP in the RTSP session.

Makes sense. I also now remember another problem with aggressive 
nomination. I'll send a separate mail to the list about that.

> Thus I have written the following text, please review and comment.
>
> 6.7.  Client to Server ICE Connectivity Check
>
>     The client receives the SETUP response and learns the candidate
>     addresses to use for the connectivity checks.  The client SHALL
>     initiate its connectivity check, following the procedures in Section
>     6 of ICE [RFC5245].  The STUN transaction pacer SHALL be used across
>     all media streams part of the same RTSP session.

BTW, how is this (transaction pacer) different from regular ICE? If it's 
not, does it need to be mentioned?

Also "(that are) part of".

>     Aggressive nomination SHOULD be used with RTSP during initial SETUP
>     for a resource.  This doesn't have all the negative impact that it
>     has in offer/answer as media playing only starts after issuing a PLAY
>     request.  Thus the issue with a change of the media path being used
>     for delivery can be avoided by not issuing a PLAY request while STUN
>     connectivity checks are still outstanding.  Aggressive nomination can
>     result in multiple candidate pairs having their nominated flag set
>     but according to Section 8.1.1.2 of ICE [RFC5245] when the PLAY
>     request is sent the media will arrive on the pair with the highest
>     priority.  Note, different media resources may still end up with
>     different foundations.
 >
>     Note: The above does not change ICE and its handling of aggressive
>     nomination.  Using aggressive nomination a given media stream can
>     have a higher priority candidate pair with an outstanding
>     connectivity check message when its check list completes, to also
>     move that candidate pair into Succeeded state and set the Nominated

Can't parse this sentence. Something missing?

>     flag.  Thus moving the used pair to this higher priority candidate
>     pair.  To avoid this occurring during actual media transport, the
>     RTSP client can add an additional checks when getting the ICE

Remove "an" and "getting"

Also, I guess you mean "continue sending checks" (i.e., no "new" 
additional checks).

>     processing overall is completed to indicate if there is still higher
>     priority connectivity checks outstanding.  If some check is still
>     outstanding then some additional timeout or the completion of the

Some word missing from this sentence.

>     outstanding checks before progressing with a PLAY request.  One
>     alternative is to accept the risk for a path change during media
>     delivery.
>
>     For RTSP clients that want to ensure that each media resource uses

Remove "For"

>     the same path can use regular nomination where both the ICE
>     processing completion criteria can be controlled in addition to which
>     media streams being nominated for use.  This does not affect the RTSP
>     server, as its role is the one of being controlled.

But yes, overall the idea looks OK to me.


Cheers,
Ari