Subject: Re: [AVT] Port mapping draft

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 1 Mar 2010 10:24:33 +0100

Hi Ali (and Dan),

I now understand the "cookie" can be a real "cookie" (as with http), and
I was confused because the draft also uses "cookie" terminology for the
receiver-generated cookie approach which is clearly then not a cookie
akin http cookie, and requires storage at the server-side of that cookie
value. So, cookie storage is only really required for receiver-generated
cookie approach, and for server-generated approach it is implementation
dependent.  

If AVT decides to keep the receiver-generated cookie approach next to
server-generated cookie approach (but I'd rather stick to one single
"hybrid" approach), we should have more clear text on that IMO.

You mention that if a receiver is not mandated to support RTP/RTCP port
muxing, a NACK or other RTCP message issued by the client would require
the receiver to send along two different cookies (for port c2 and c3).
But isn't it possible that a single cookie -as generated by the server-
contains the information on both ports c2 and c3?

Tom

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: donderdag 25 februari 2010 18:45
To: VAN CAENEGEM Tom; [email-masked]
Cc: Dan Wing (dwing)
Subject: RE: [AVT] Port mapping draft

Hi Tom, All,

...
> If the NAT is doing endpoint-independent mappings (definition is from 
> RFC 4787), there is no delay penalty. The client gets the necessary 
> cookies at the beginning and uses them whenever necessary. If the 
> mappings are endpoint-dependent, the client needs to generate specific

> cookies for each port on RS and different RS addresses (Section
4.2.2).
> 
> TOM: With "delay" I meant the delay for the RTP receiver between being

> able to send its 1st RTCP FB message (NACK or RAMS-R for the
considered
> example applications) with embedded cookie and the sending of the 1st 
> port mapping message. I agree this delay implies only "at the
beginning"
> : for instance mapping to the IPTV use case, if I switch on the STB,
it
> first needs to go through the port mapping before it can send the
RAMS-R
> message. After that, if the same port mapping can be used, it does not

> matter anymore (no delay).

Yes.
 
... 
> Not sure whether this would reliably work in cases where multiple 
> clients behind the same NAT wanted to communicate with the same
server.
> 
> Tom: good point, but would a NAT do the same mapping to the same 
> external source port (and same public IP address) for two receivers in

> the local network issuing messages with same ports (source and public)

> and same destination IP address? I do not think so, as there would be
a
> null effect of the NAT, i.e. the NAT would not do what it is supposed
to
> do (and it would hence not know to which receiver on the local network

> it should forward any packets sent by the RS to one of the two
> receivers) . However, the big problem with the default port approach
is
> that the NAT traversal will not work, independent from the fact if one

> or multiple receivers are behind this NAT, because the receiver does
not
> know which local port maps to the advertised default public port (so
my
> explanation in previous mail (above) to address NAT traversal was
wrong)

OK. In our initial pubports proposal, we used a stun server co-located
with RS to figure out the external ports and these ports were reported
back to RS in an RTCP message but as you know this idea was not favored
in the breakout session.

> The client needs to keep the NAT bindings open and to do that
keepalive
> messages are needed. We will add more explicit text for this.
> 
> > the server to which the port mapping messages are addressed? Perhaps
> it makes sense to include
> > additional field(s) in the port mapping message, which allows a
server
> to distinguish between such
> > "keep alive" port mapping messages and "1st" port mapping
message(s)?
> 
> The keepalive messages do not have to be a portmapping message.
> 
> Tom: they can be any RTCP messages related to the unicast RTP flow, is

> that what you mean, like SDES, RR (which can be empty)?

I believe so.

> Why is there a need for a timeout mechanism? The cookies are not
stored
> on the server. The needed cookies can be generated when the client is 
> booted and be used later as long as client uses the same local ports
and
> client's public address and ports do not change. I believe we need to 
> consider what happens when NAT fails and restarts, though since public

> IP address may change and mappings may change.

Update: If NAT fails, the public IP/port information will likely change
and the reverse transform will fail. Eventually the client will get
suspicious and will need to request new cookie(s).
 
> TOM: this is what I do not get (see my pre-previous comment): when a 
> FT/RS receives a NACK/RAMS-R/whatever with a cookie, how does the
server
> deduce the port for the unicast RTP stream? By looking up which cookie

> corresponds with which port, no? Hence cookies must be stored at the 
> server-side. This is valid for all approaches, IMO.

That information is built into the cookie by using a processing only
known to the server. When the server receives a NACK with a cookie, it
will "decode" the cookie and know which port(s) the client wants to use
in the unicast session. 

In the current draft, in Figure 4, only one cookie (for c2) is included
with the NACK message. But, the cookie for c3 also needs to be included
with the NACK, otherwise the server cannot send sender reports to the
right port.

It is easy to see that not doing port-muxing complicates either approach
(server or client-based). In particular, the client-based approach is
pretty heavily impacted in terms of reliability. Does the WG think
mandating port muxing on the client side will be useful?

Please share your comments.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 1 Mar 2010 04:32:13 -0800

Hi Tom,

> From: VAN CAENEGEM Tom [mailto:[email-masked]]
> Sent: Monday, March 01, 2010 4:25 AM
> To: Ali C. Begen (abegen); [email-masked]
> Cc: Dan Wing (dwing)

Text needs improvement, I agree. Once we agree on a solution, a more
structured document is to follow.
 
> contains the information on both ports c2 and c3?

Server encodes the cookie information based on the address/port it sees
in the incoming request packet. If client is not muxing, two requests
will have to come from two different address/port pairs (regardless of
whether there is a nat or not). When generating the 2nd cookie
(server-based approach), the server may convolute both cookies if you
like, but what is the benefit? You will have already paid for the delay.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Wed, 10 Mar 2010 14:09:14 +0200

Hi,
For the keep alive maybe the draft should reference
http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-07 

Roni Even
As individual 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dan Wing
> Sent: Monday, February 22, 2010 8:29 PM
> To: 'VAN CAENEGEM Tom'; [email-masked]
> Subject: Re: [AVT] Port mapping draft
> 
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of VAN CAENEGEM Tom
> > Sent: Monday, February 22, 2010 8:18 AM
> > To: [email-masked]
> > Subject: [AVT] Port mapping draft
> 
> [... I had no comments on the hybrid cookie approach ...]
> 
> > But even with respect to delay, there  is a strong
> > improvement possible:  as the port-mapping solution MUST be
> > supported by an RTP receiver in situations where a unicast
> > RTP session is coupled to a SSM -as is the case for RAMS and
> > for unicast Retransmissions coupled to SSM- I see no reason
> > why we cannot have a (default) port indicated in the SDP (or
> > whatever signaling means is used for transferring session
> > parameters) for the unicast RTP stream. The retransmission
> > server uses default this port mapping for the requesting RTP
> > receivers, unless it receives (normal) portmapping RTCP
> > messages. However, we still may want to address NAT traversal
> > in this case. This is possible, when the RTP receiver sends
> > RTCP Port mapping message(s) from the RTP port/RTCP port
> > announced in the SDP to the RS. The RS will see that the
> > source port(s) match the default destination port for the RTP
> > flow, and can ignore these messages.
> >
> > This allows an RTP receiver to request the RTP flow from the
> > RS  -which will traverse the NAT -without any delay as the
> > portmapping messages can be sent simultaneously with the RTCP
> > FB/NACK, when this RTP receiver agrees with the proposed
> > default port(s). In particular, when a RTCP RAMS-R or RTCP FB
> > NACK is received without cookie attached, the RS will use the
> > default port.
> 
> I worry about default ports, because it changes the behavior for
> the 1st RTP receiver behind a NAT (which might be able to get the
> NAT to assign it that same port) versus the behavior for the
> 2nd or 3rd RTP receiver.  This complicates code (rather than
> simplifying it) and complicates testing/validation.
> 
> I admit I don't fully understand the proposal for a default port,
> but it seems it could cause a RS to believe it is helping an
> RTP receiver when it is helping the wrong RTP receiver (or helping
> no RTP receiver at all).
> 
> > These are some other points that need to be addressed by this
> > draft, IMO:
> >
> > -how does the RTP receiver send the cookie together with RTCP
> > messages that address the feedback target (RAMS-R and NACK
> > FB)?  Do we envisage  an app-specific RTCP message or define
> > a new RTCP message? What about defining a new TLV for the
> > RAMS-R message for containing this cookie value.  Realising
> > this is only applicable for RAMS, but it would be the most
> > efficient way, and would also work in deployment like IPTV
> > where RAMS and retransmissions are used in parallel.
> >
> > -as a port mapping RTCP message  allows NAPT traversal,
> > should there not be some text indicating that to keep the
> > NAPT open, an RTP receiver may have to repeat sending a port
> > mapping message, when no RTP/RTCP messages  are received on
> > the unicast RTP session for a long time?
> 
> To keep the NAPT open, most NAPTs need to see occasional
> messages from the inside (RTP receiver) to outside (RS).
> 
> There is existing text in Section 4.3.1 (receiver-generated cookie),
> 
>    4.  The client sends separate RTCP packets from its ports c2 and c3
>        to the server port P3 to setup the NAT.  Each RTCP packet
>        indicates through a bit/field whether it source port will be
> used
>        for RTP or RTCP traffic by the client.  The client repeats this
>        step as deemed necessary to keep the NAT bindings alive.
> 
> but I don't see similar text in the server-generated cookie section.
> 
> 
> I agree there should be text discussing the RTP receiver needs to keep
> the
> NAPT mapping alive, most likely in the Implication of NATs section.
> 
> > And how does this
> > affect the server to which the port mapping messages are
> > addressed? Perhaps it makes sense to include additional
> > field(s) in the port mapping message, which allows a server
> > to distinguish between such "keep alive" port mapping
> > messages and "1st" port mapping message(s)?
> 
> Yeah, something like a 0-byte UDP packet could keep the
> NAPT mapping alive and be easily and quickly discarded
> by the RS -- or even in a device before the RS (e.g., a
> router or firewall).
> 
> > -a comment related to the section 4.2.2 (implications of NAT)
> > in the draft: the text stipulates when/whether a given RTP
> > receiver needs to engage in a new portmapping process  when
> > some of the port/address parameters change in the
> > unicast/multicast flows, depending on whether the RTP
> > receiver is behind a (specific) NAT device. We should have
> > text that imposes the most frequent portmapping process when
> > an RTP receiver does not know anything about this (presence of a)
> NAT.
> >
> > -how long does the (non-default) port mapping remain valid at
> > the Retransmission server? I guess the RS cannot remove a
> > cookie entry in its database when a bye message is received
> > (on the feedback target or on the RS), as it would require an
> > RTP receiver to do the port mapping whenever a new multicast
> > channel is joined. Is this based on a time-out  (i.e. no more
> > RTCP messages were received by the RTP receiver with this
> > cookie embedded)
> 
> Timeout seems best.  Can't rely on BYE (RTP receiver might crash,
> be unplugged, network failure, in-home power failure, ...).
> 
> The RTP receiver should send a keepalive to the RS to keep the
> RS's state active.  That keepalive is not, necessarily, the same
> keepalive the RTP receiver sends to keep its NAPT mapping alive.
> 
> -d
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Roni Even <[email-masked]>
Date: Wed, 10 Mar 2010 14:49:42 +0200

I also think it will be good to require port multiplexing on the client
side. Making the solution simple.

Roni Even
As individual

> Sent: Thursday, February 25, 2010 8:12 PM
> To: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; [email-masked]
> > Sent: Thursday, February 25, 2010 9:45 AM
> > Does the WG think mandating port muxing on the client side
> > will be useful?
> 
> It would reduce a lot of complexity.  The client already
> needs to do a lot of "new stuff", so requiring it support
> RTP and RTCP on the same port can be added to the list of
> "new stuff".
> 
> "KISS."
> 
> -d
> 
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 10 Mar 2010 14:42:56 +0100

> http://tools.ietf.org/html/draft-ietf-avt-app-rtp-keepalive-07 

Maybe, but that is not obvious due to the entities and the purpose of
the streams. I think it something for discussion. We should also not
forget about the discuss clearing discussion that needs to happen for
this draft.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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: David R Oran <[email-masked]>
Date: Wed, 10 Mar 2010 09:49:07 -0500

> side. Making the solution simple.
Agree. It sure makes things simpler as long as nobody objects.

---

From: Roni Even <[email-masked]>
Date: Wed, 10 Mar 2010 18:14:03 +0200

Hi,
I think that this will address the issue of sending a response to the RTP
port on the client discussed in a separate thread and will enable keeping
the binding open using RTCP messages.

It will be good to open a specific thread on this issue and see if there are
major objections.
I noticed a comment regarding ATSC mandating separate ports for RTP and
RTCP.

Roni Even
As individual

> David R Oran
> Sent: Wednesday, March 10, 2010 4:49 PM
> To: Roni Even
> Cc: 'VAN CAENEGEM Tom'; [email-masked]; 'Dan Wing'