[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Port mappings, NAT, and RAMS


On Jun 30, 2009, at 6:55 AM, Roni Even wrote:


Hi guys,
My view is that this is not a general NACK problem but only for the case of SSM and retransmission with similar box architecture to the RAMS solution. 
If you have another case please explain
I believe it is actually a MORE general problem than NACK or RAMS. I arises from mixing SSM sessions and unicast sessions for the same RTP- based application. That's because multicast enforces port symmetry among all the receivers while unicast needs per-receiver port selection.
So far we have two uses for mixing multicast and unicast: retransmission-based repair, and RAMS. I suspect more uses will arise in the future. I can think of a few off the top of my head: - customized per-user overlays (e.g. to be alpha-blended with the video) or object-level replacement 
- network-coded error recovery streams
- extra media info for re-integration when switching back from unicast to multicast in a fast-forward-to-realtime capability when doing "pause-live-content" style services - adaptive switching between multicast and unicast based on number of simultaneous receivers.
I have a strong intuition that doing a generic mechanism to atomically signal ports for unicast sessions using the RTCP feedback machinery of the SSM session would be highly advisable. 

So, I think:
a) we need to solve this problem
b) it exists even in the absence of NATs
c) we need a generic mechanism
d) it should be documented in a separate draft, and not part of RAMs or AVPF.
If we can agree to these points, then we can have a more detailed discussion of the appropriate machinery. I have opinions on that subject too. 

DaveO.




Roni


-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
Ali C. Begen (abegen)
Sent: Tuesday, June 30, 2009 10:19 AM
To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
avt at ietf.org
Subject: Re: [AVT] Port mappings, NAT, and RAMS

Hi Tom,
Let's get the input from the WG on these points. I believe going for a more general solution that will be applicable to both RAMS and NACK is 
more desirable.

BR,
-acbegen




-----Original Message-----
From: VAN CAENEGEM Tom [mailto:Tom.Van_Caenegem at alcatel-lucent.be]
Sent: Monday, June 29, 2009 9:17 AM
To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; Roni

Even; avt at ietf.org

Subject: RE: Port mappings, NAT, and RAMS


Ali,

See some comments below (TOM).

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
Sent: vrijdag 26 juni 2009 17:41
To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
avt at ietf.org
Subject: RE: Port mappings, NAT, and RAMS

Hi Tom,

[snip]

The reason why we need pubports is that it indicates "explicitly"

the

port the client wants to use to receive the burst is the port it

used

to send the RAMS-R/pubports message. I believe we need this

explicit

indication, ow, we will be making an implicit assumption. Note that
the rams-r/pubports is in the primary session and burst/ret packets
are in the retransmission session, which is different than the

primary.


As far as I can see, not everybody agrees on this point, but we

need

to make a decision here before we mandate anything.

TOM: I agree with your last line, but I do not completely agree

when

you mention "implicit" assumption, especially for option 3, where
RAMS-R (or
NACK) and the Pub-port message are in the same compound message. If

we



"define" that if no pub-report message is sent by the RR, the
information towards the Retransmission server is exactly the same

as

when an RTP receiver sends an RTCP compound message made up of an

RTCP



NACK/RAMS-R together with a pub-port message where the ports are

"zero"

We "may" be able to say it from RAMS-R but not for NACK since we are

not
defining it, we will be overloading its meaning, IMO. And as you/ Bill pointed out in other emails, I also believe that this is more general 
problem than just RAMS. We need something like pubports for NACKs as
well.


TOM: indeed, that is why IMO we should define this problem and

solution

in a separate draft which applies to any system architecture where a
unicast session from a FT is coupled to a ssm session with that same

FT.




-as currently proposed in the RAMS draft now.  I agree that this is
not true for option 4, where pub-port and RAMS-R or NACK are

separate

messages, but I do not favour the solution of option 4 for the same
reason you mention in your reply (a new failure mode). So, if

option 4



is -for that reason- no longer considered, I do not see a problem

with



defining this rule/clause as expressed above. In other words, there

is



no need for a pub-report message in this scenario and this results

NOT



in an "assumption" what-so-ever.



supports RTP/RTCP muxing itself, and if it knows the RS supports
RTP/RTCP muxing too (as indicated in the declarative sdp received

by



the
RR)

-Don't we also allow that for option 3, the port P2 actually

equals

port P4? This is a kind of hybrid of session and SSRC

multiplexing

of the primary multicast RTP stream and the
retransmission/acceleration session
:  on the unidirectional RTP layer, the primary MC packets and

the

unicast retransmission packets are clearly session muxed, but the
RTCP



"return" channel for both streams have exactly the same transport
addresses, but are distinguished by means of a different SSRC.

In

that


How? Since SSM and retransmission sessions are session muxed, they
have the same SSRC. When a client is sending a receiver report, how

do



we identify which session it belongs to? So, I believe P2 should be
different than P4.

TOM: you are right. But notice this: RFC 4588 mandates that when
session muxing is used for retransmission, than the SSRC should be

the

same.

However the RFC 4588 does not give arguments why it needs to be

like

that. So I ask you: what would or can happen if there is a

different

SSRC used?  If there are no convincing arguments why we must stick

to


Good question. If we don't use the same SSRC in session-muxed RTP
sessions, it will introduce correlation problems. Receiver/XR reports 
coming from a larger number of receivers will be difficult to

identify

and match at the server side. There will be SSRC collisions, which

will

complicate things further.

TOM: the big difference with when the RFC 4588 was being discussed

and

developed, is that now we are capable of advertising in SDP the SSRC

of
the media server, that is in this case the retransmission server SSRC 
used in the retransmission session. In fact for RAMS, we need to

define

the SSRC of the ssm RTP session, so we can as well do it for the
retransmission session. Perhaps we should consider this different

SSRC

possibility (hence violating RFC 4588) as part of a new draft, the

one I

mentioned above.



the same SSRC, then, if we have a good use case to depart from that
"rule" -and the use case we are discussing here is IMO indeed a

valid

use case- I do not see why we should be limited by such a "rule".

The

"valid" use case is here that RAMS and Retransmission for SSM

sessions



operates fine through any NAPT and without any dedicated RTCP

message.


-acbegen

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt

Attachment: PGP.sig
Description: PGP signature