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

From: Ari Keranen <[email-masked]>
Date: Wed, 05 Dec 2012 23:22:04 +0200

Hi,

I reviewed the draft-ietf-mmusic-rtsp-nat-14 and I think the document is 
in pretty good shape and ready to move forward. Some (mostly editorial) 
comments to consider:

3.  Solution Overview

         The client then installs the STUN servers on each of
         the local candidates transport addresses it has gathered

I would rather say "The client then prepares to act as a STUN server on 
each [...]"

         If the server has a public
         IP address, then a single candidate per address family

In some cases (e.g., certain ISPs, I've heard) even "public" IP address 
does not mean you're not behind a NAT. Maybe it's better to say here "If 
the server is not behind a NAT". Same issue in step 8.

         If the server has a public IP address with a single candidate
         per media stream, component and address family, then the server
         may be configured to not initiate connectivity checks.

This is the "ICE-RTSP", right? Maybe one (small) subsection defining 
this "feature" would make sense. Now it's a bit trickled around in this 
section, sec 4.8.1, 5.4, etc. For someone not familiar with ICE-RTSP, it 
looks like you're talking about ICE lite.

    the NAT need to be refreshed by the client to server traffic provided
    by the STUN keep-alive.

s/keep-alive/keep-alive mechanism/ (or messages).
Also in section 5.11.

5.7.  Client to Server ICE Connectivity Check

    The client receives the SETUP response and learns the candidate
    address to use for the connectivity checks.

s/address/addresses/ (right?)

    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.

5.12.  Re-SETUP

    If the client decides to change any parameters related to the media
    stream setup

Could clarify (again) here that we talk about ICE parameters.

Cheers,
Ari

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 6 Dec 2012 16:03:07 +0100

Hi Ari,

Thanks for the review. I feel much more confident now that we haven't
significantly screwed up any ICE details.

> I would rather say "The client then prepares to act as a STUN server on

Sure, maybe "runs STUN servers" is better than both "installs" and
"act". They are STUN server, but with limited utility. Act as STUN
servers sounds like it is impersonating STUN, rather than actually being
STUN servers.

> the server is not behind a NAT". Same issue in step 8.

Sure, maybe we need to define what we mean with not being behind a NAT.
It is a matter of being reachable from the top anchorin address domain
in regards to the clients.

> looks like you're talking about ICE lite.

Yes, this is definitely ICE-RTSP. It is still doing triggered checks.

> s/keep-alive/keep-alive mechanism/ (or messages).

Will address.

> 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.

> Could clarify (again) here that we talk about ICE parameters.

Yes, definitely. I actually had to think a long time if this was only
ICE parameters or also RTSP parameters. But, it is so unnecessary to
restart ICE for most RTSP parameter changes.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Dec 2012 10:13:14 +0100

Hi,

Follow up on comments as I have edited proposals to resolve the issues.
I have the general set of changes on review with my co-authors. Hope to
be able to submit next week.

> Yes, this is definitely ICE-RTSP. It is still doing triggered checks.

However, I think you might have misinterpreted what ICE-RTSP really is.
It is the full usage of ICE as defined by this specification. The high
reachability configuration of the RTSP server is a variant of the normal
ICE-RTSP behavior.

I have tried to clarify this and created a special section for
discussing the differences, this include the text in the old 4.8.

5.  ICE-RTSP

   This Section discusses differences to the regular ICE usage defined
   in [RFC5245].  The basic for the modifications in the general
   procedures are in the clearer client/server roles that RTSP provides
   and how the RTSP Session establishment signalling occurs within RTSP
   compared to SIP/SDP Offer/Answer.

5.1.  ICE Features Not Required

   A number of ICE signalling features are not needed with RTSP and are
   discussed below.

5.1.1.  ICE-Lite

   The ICE-Lite attribute shall not be used in the context of RTSP.  The
   ICE specification describes two implementations of ICE: Full and
   Lite, where hosts that are not behind a NAT are allowed to implement
   only Lite.  For RTSP, the Lite implementation is insufficient because
   it does not cause the media server to send a connectivity check,
   which is used to protect against making the RTSP server a denial of
   service tool.

5.1.2.  ICE-Mismatch

   The ice-mismatch parameter indicates that the offer arrived with a
   default destination for a media component that didn't have a
   corresponding candidate attribute.  This is not needed for RTSP as
   the ICE based lower layer transport specification either is supported
   or another alternative transport is used.  This is always explicitly
   indicated in the SETUP request and response.

5.1.3.  ICE Remote Candidate Transport Header Parameter

   The Remote candidate attribute is not needed for RTSP for the
   following reasons.  Each SETUP results in an independent ICE
   processing chain which either fails or results in promoting a single
   candidate pair to usage.  If a new SETUP request for the same media
   is sent, this needs to use a new username fragment and password to
   avoid any race conditions or uncertainty about which round of
   processing the STUN requests relate to.

5.2.  High-Reachability Configuration

   ICE-RTSP contains one variant for RTSP Servers that are not behind
   NATs, i.e. are highly reachable by the clients.  Similar to ICE-Lite
   this allows for some reductions in the servers burden.  However, due
   to the need to still verify that the client is actually present where
   it claims the server must also initiate binding requests and await
   binding responses.  The reduction for the high-reachability
   configuration of ICE-RTSP is that they don't need to initiate its own
   checks, and instead rely on triggered checks for verification.  This
   also removes a denial of service threat where a RTSP SETUP request
   will trigger large amount of STUN connectivity checks towards
   provided candidate addresses.

> restart ICE for most RTSP parameter changes.

When looking at this again, I though it unclear enough that I have
attempted a bit of rewording. I propose the section should read like this:

6.12.  Re-SETUP

   A client that decides to change any parameters related to the media
   stream setup it will send a new SETUP request.  In this new SETUP
   request the client MAY include a new different username fragment and
   password to use in the ICE processing.  New username and password
   SHALL cause the ICE processing to start from the beginning again,
   i.e. an ICE restart (Section 9.1.1.1 of [RFC5245]).  The client SHALL
   in case of ICE restart gather candidates and include the candidates
   in the transport specification for D-ICE.

   ICE restarts may be triggered due to changes of clients or servers
   attachment to the network, i.e. changes to the media streams
   destination or source address or port.  Most RTSP parameter changes
   would not require an ICE restart, instead existing mechanisms in RTSP
   for indicating from where in the RTP stream they apply should be
   used.  These include performing a pause prior to the parameter change
   and then resume or if server supports in do SETUP during PLAY state,
   and thus use RTP-Info header (Section 18.43 of
   [I-D.ietf-mmusic-rfc2326bis]) to indicate from where in the media
   stream the change apply.

   The server SHALL support SETUP requests in PLAY state, as long as the
   SETUP changes only the ICE parameters, which are: ICE-Password, ICE-
   ufrag and the content of ICE candidates.

   If the RTSP session is in playing state at the time of sending the
   SETUP request requiring ICE restart, then the ICE connectivity checks
   SHALL use Regular nomination.  Any ongoing media delivery continues
   on the previously nominated candidate pairs until the new pairs have
   been nominated for the individual candidate.  Once the nomination of
   the new candidate pair has completed, all unused candidates may be
   released.

Cheers

Magnus Westerlund

---

From: Ari Keranen <[email-masked]>
Date: Mon, 17 Dec 2012 17:36:35 +0200

Hi Magnus,

> servers sounds like it is impersonating STUN, rather than actually being

"runs" sounds good to me.

> in regards to the clients.

Yes, that would be good.

[...]
> 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?

Cheers,
Ari

---

From: Ari Keranen <[email-masked]>
Date: Mon, 17 Dec 2012 17:38:18 +0200

Hi Magnus,

These changes look good to me. And please add forward-reference(s) to 
the ICE-RTSP section where applicable. Couple of nits inline.

Cheers,
Ari

>     stream setup it will send a new SETUP request.  In this new SETUP

(remove "it")

>     and then resume or if server supports in do SETUP during PLAY state,

"in do SETUP" ?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Dec 2012 17:07:37 +0100

>> in regards to the clients.

OK, so far I haven't actually done such an addition to the modified
texts. But I will see what I can do before submitting the update.

> 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.

Cheers

Magnus Westerlund

---

From: Ari Keranen <[email-masked]>
Date: Tue, 18 Dec 2012 14:43:08 +0200

[...]
> 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.

Cheers,
Ari

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Dec 2012 14:09:55 +0100

Ari,

Thanks for keep following up on this. Please see below.

> 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.

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.

   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
   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
   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
   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
   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.

-- 

Magnus Westerlund

---

From: Ari Keranen <[email-masked]>
Date: Wed, 19 Dec 2012 19:50:13 +0200

Hi Magnus,

> Thanks for keep following up on this. Please see below.

No problem! Comments inline.

> 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.

>     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".

>     move that candidate pair into Succeeded state and set the Nominated

Can't parse this sentence. Something missing?

>     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).

>     outstanding then some additional timeout or the completion of the

Some word missing from this sentence.

>     For RTSP clients that want to ensure that each media resource uses

Remove "For"

>     server, as its role is the one of being controlled.

But yes, overall the idea looks OK to me.

Cheers,
Ari