Re: [AVT] the use of"mediasenderSSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

["VAN CAENEGEM Tom" <[e-mail]>]

Roni,

If an RTP receiver transmits a NACK, it will always use the right media
sender SSRC in this NACK, because it already receives the SSM with (the
right) media sender SSRC inside the RTP packet headers. 

If an RTP receiver transmits a RAMS-R with a "wrong" media sender SSRC
(this is the case where there is a 1-to-1 mapping between SSRC and RS/FT
transport address, and SSRCs of the RTP stream(s) in the SSM are not
signaled), the response is -in general- a burst of retransmission
packets which have a media sender SSRC that is different from the one
that is requested. But even if there are multiple RAMS-R requests
transmitted by the same RTP receiver, the response bursts will be
segregated based on the different media sender SSRCs. The difference
with RFC 4588, is that the RTP receiver receives first the
retransmission packets and then the original packets (in the SSM), and
the association between these RTP streams/packets (which original packet
stream matches with which received burst of retransmission packets) can
still be done as described in RFC4588, no? Where do you see loss of
compliance with RFC4588?

Tom

-----Original Message-----
From: Roni Even [mailto:[e-mail]] 
Sent: woensdag 16 december 2009 16:02
To: 'Bill Ver Steeg (versteb)'; VAN CAENEGEM Tom; 'Ali C. Begen
(abegen)'; 'Colin Perkins'; 'Qin Wu'
Cc: 'Rob Drisko (rdrisko)'; [e-mail]
Subject: RE: [AVT] the use
of"mediasenderSSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05

Hi,
The problem with this approach is that if RAMS is based on RFC4588 than
the RTP_Rx will expect to get a retransmission with the SSRC he
requested so you lose compliance to RFC4588 which was an assumption in
RAMS. 

One other question is that I think that sending a different SSRC from
the requested one will cause a problem on the receiver in the case where
he receives sent two different RAMS-R requests and get two streams with
new SSRCs, see section 5.3 of RFC 4588 

I can think of another solution by which the RS will send the original
payload (e.g. MP2T) and not a retransmission stream.

Roni Even

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> Bill Ver Steeg (versteb)
> Sent: Friday, December 11, 2009 4:42 PM
> To: VAN CAENEGEM Tom; Ali C. Begen (abegen); Colin Perkins; Qin Wu
> Cc: Rob Drisko (rdrisko); [e-mail]
> Subject: Re: [AVT] the use of "mediasenderSSRC"indraft-ietf-avt-rapid-
> acquisition-for-rtp-05
> 
> Tom, Ali-
> 
> There is broad agreement on the core points of this issue.
> 
> The remaining point is whether the RS silently ignores RAMS-R with an 
> invalid SSRC on a multiplexed port or if it returns an error message.
> We
> should consider the case in which this is a mis-configuration (in 
> which an error message is probably appropriate) or the case in which 
> this is some sort of malicious act (in which a silent drop is probably

> appropriate).
> 
> Perhaps a scheme in which an error message is sent for some number 
> (some percentage? Some threshold?) of such messages, but they are 
> silently ignored after that. This addresses the most obvious DOS 
> concerns. Are there other security concerns we should be considering?
> 
> It is difficult to capture all of the security concerns. If we agree 
> that there is some leeway in implementation on this point, the wording

> would be something along the lines of "When receiving a RAMS-R with an

> invalid SSRC on a port that is configured to handle more than one 
> SSRC, the RS MAY send an error message of format xxx, or it may 
> silently ignore such messages. The RS should make this decision based 
> on loading factors, the frequency of such events, and the overall 
> security profile of the system."
> 
> Bvs
> 
> 
> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:[e-mail]]
> Sent: Friday, December 11, 2009 5:48 AM
> To: Ali C. Begen (abegen); Colin Perkins; Qin Wu
> Cc: Rob Drisko (rdrisko); [e-mail]; Bill Ver Steeg (versteb)
> Subject: RE: [AVT] the use of
> "mediasenderSSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05
> 
> Hi Ali,
> 
> I can agree with your views:
> -if there is a one-to-one mapping between FT port address and RTP 
> stream (with a specific SSRC), there is NO requirement on signaling 
> the SSRC values to the RTP receivers and the RS must ignore in the 
> RAMS-R messages the media sender SSRC value.
> -if there is no one-to-one mapping, the SSRC values must be signaled 
> to the RTP receivers prior to RAMS-interactions and the RS must not 
> ignore the media sender SSRC values in the RAMS-R messages.
> 
> In this second latter case, when the RS receives a RAMS-R with 
> "invalid"
> media sender SSRC, it must respond with a RAMS-I error message (and no

> RTP burst). We should also have text then that the "media sender SSRC"
> and "packet sender SSRC" in this RAMS-I message should be ignored by 
> the RTP receiver for the reasoning I gave in my previous email. I 
> think it would be interesting to add "invalid SSRC" as error message. 
> You are right that a RS cannot resolve with 100% certitude in all 
> corner cases which is the RTP stream (identified by SSRC) the RTP 
> receiver wants to receive by means of RAMS, so a new TLV for in-band 
> SSRC signaling is not a solid solution in this case.
> 
> Tom
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> Ali C. Begen (abegen)
> Sent: maandag 7 december 2009 16:39
> To: VAN CAENEGEM Tom; Colin Perkins; Qin Wu
> Cc: Rob Drisko (rdrisko); [e-mail]; Bill Ver Steeg (versteb)
> Subject: Re: [AVT] the use of
> "mediasenderSSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05
> 
> Hi Tom,
> 
> > -----Original Message-----
> > From: VAN CAENEGEM Tom [mailto:[e-mail]]
> > Sent: Monday, December 07, 2009 6:46 AM
> > To: Ali C. Begen (abegen); Colin Perkins; Qin Wu
> > Cc: Rob Drisko (rdrisko); [e-mail]; Bill Ver Steeg (versteb)
> > Subject: RE: [AVT] the use of "mediasender
> > SSRC"indraft-ietf-avt-rapid-acquisition-for-
> > rtp-05
> >
> > Hi,
> >
> > My view is that out-of-band SSRC signaling should be recommended in 
> > the context of RAMS. However, in order to deal for example with the 
> > failure cases when SSRC's change in the SSM RTP streams generated by

> > media senders, a RS should be "prepared" to deal with incorrect 
> > media sender SSRC values in the RAMS-Request messages. Therefore , 
> > from the RR point of view, the RS response on a RAMS-R with 
> > "incorrect" media sender SSRC value, could be
> >
> > 1)an RTP burst with the proper  media sender SSRC. Following RFC
> 4588,
> 
> > this "proper" media sender SSRC is then transmitted by the RS in the

> > retransmission packet RTP header. This means that the RAMS-R was 
> > successfuly responded upon by the RS. The RS may only act in such a 
> > way if there is a 1-to-1 mapping between FT transport address and 
> > associated SSM RTP stream (..which is known to the RS, not to the 
> > RTP
> receiver).
> > This means that in this case the RS may even ignore in its normal 
> > operational mode the  value of the "media sender SSRC" field in the 
> > RAMS-R messages, as there is never any ambiguity. This is an 
> > implementation choice.
> 
> In scenarios where there is 1:1 mapping in FTAp's and source streams, 
> I believe the draft should define what RS has to do, which should be 
> IMO that it sends the media stream with the correct SSRC (as you said
> above)
> ignoring the SSRC specified in the RAMS-R message. We should not leave

> this behavior up to implementation.
> 
> Furthermore, the draft should also specify what RS should do when 
> there is no 1:1 mapping.
> 
> > 2)no RTP burst, but a RAMS-I message which indicates unsuccesful 
> > response.
> > The RAMS draft now has a defined a response code 400 with meaning 
> > "Invalid RAMS-R message syntax". It may be worthwile to consider a
> new
> 
> > dedicated response code 404 with meaning "Invalid media sender SSRC
> in
> 
> > RAMS-R". The RS must respond in this way when there is NOT a 1-to-1 
> > mapping between FT transport address and SSM RTP streams, each 
> > having a SSRC value which is different from the one received in the 
> > RAMS-R
> 
> So, you think RS should let the receiver know about this?
> 
> > message. This may also be the behaviour of a RS which does always 
> > inspect the media sender SSRC value in the RTCP FB messages, and 
> > only services the RTCP message (NACK or RAMS-R) when the SSRC is 
> > correct, irrespective whether there are disambiguities or not.  
> > Note, that in the case when there is NO 1-to-1 mapping between FT 
> > and SSM, there is an additional issue when the RS sends the RAMS-I 
> > RTCP message with error code. The RS sends the RAMS-I message in the

> > retransmission session and following RFC 4588, the media sender SSRC

> > in the retransmission session packets  must be the one used in the
> associated
> primary (original) SSM.
> > However, if there are at least two  SSRC values/SSMs possible, which

> > SSRC value must be used then in the "SSRC of packet sender" field 
> > and in the "SSRC of media sender" field of the RAMS-I message?
> > This also means that the RTP receiver cannot assume that the SSRC 
> > value inside the RTCP RAMS-I RTCP message header is the "proper" 
> > SSRC of the
> 
> Right, it cannot. So, this RAMS-I message only serves the purpose of 
> letting the receiver know that its SSRC request did not match to any 
> of the served SSRCs by this FTAp.
> 
> > SSM requested with the RAMS-R. It may be interesting to consider 
> > defining a new optional TLV element for signaling in the RAMS-I the 
> > "proper" SSRC value, which is hence an in-band delivery option for
> the
> > SSRC.   This in-band SSRC delivery provides a solution for the cases
> > described earlier in this email thread where a media sender changes 
> > SSRC (restart or redundant switch-over). The RS will  be the one 
> > noticing the SSRC change in the SSM RTP stream, and when there is an

> > incoming RAMS-R
> 
> Actually, all receivers that already subscribed to those specific SSM 
> sessions will also see the SSRC changes. But, other receivers will be 
> clueless until they are somehow told.
> 
> In deployments with 1:1 mapping, this is not an issue. In other 
> deployments, updated SDPs with the new SSRC information must be 
> distributed as soon as possible to minimize the errors.
> 
> > for the "old" SSRC, the "new" SSRC can be signaled with the new TLV 
> > element embedded in the RAMS-I message.  Note however that this
> should
> 
> Is it likely for the receiver to try another RAMS attempt with the new

> SSRC after receiving the correct SSRC? Maybe, it is. But, for the 
> server to tell the receiver the correct SSRC, it must remember which 
> SSRC has replaced which SSRC. And this info must be accurate.
> 
> What about the following case?
> 
> (An FTAp serving for two source streams)
> Time=0:
> Source 1: SSRC1, Source 2: SSRC2
> 
> Time=100:
> Source 1: SSRC2, Source 2: SSRC3
> 
> When a RAMS-R arrives asking for SSRC2, what does RS do? The receiver 
> could be asking for source 1 or source 2. How do we know?
> 
> Or, at time=200, it could be:
> Source 1: SSRC4, Source 2: SSRC5
> 
> Now, a request for SSRC2 arrives. We are stuck again.
> 
> IMO, we should not require the retransmission server to remember all 
> these possibilities and keep additional state.
> 
> > not be the default mechanism of signaling SSRC values in the context

> > of RAMS .. that is why "out-of-band" SSRC signaling must at least be

> > "recommended" for RAMS.
> 
> We need to be careful about the wording here. The requirement for the 
> out-of-band signaling is currently a "must" regardless of whether 
> FTAp's serve for a single or multiple source streams. This must be 
> revised.
> 
> IMO, we must separate the requirements and list them separately for 
> each of the two possible scenarios (according to whether a 1:1 mapping

> exists or not). The former case is simple. For the latter case, there 
> may exist a lot of nasty scenarios that the FTAp's may need to deal 
> with. I suggest that the draft merely mentions the problems and 
> requires the implementations to deal with them (rather than imposing 
> specific solutions).
> 
> > In the case 2, when the RTP receiver does not receive an RTP burst
> but
> 
> > only a RAMS-I with error response code 400 (or 404), the RTP 
> > receiver must NOT make any RAMS-R requests anymore to this FT when 
> > it does not know the right "SSRC" IMO. Only when the RTP receiver 
> > receives this new
> 
> Agree.
> 
> > TLV containing the proper SSRC, or when resolving the right SSRC in 
> > a different way (out-of-band, or by receiving directly the SSM RTP 
> > flow without RAMS), it MAY do so, by using this new SSRC value.
> 
> See above.
> 
> -acbegen
> 
> >
> > What do you think?
> >
> > Tom
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf 
> > Of Ali C. Begen (abegen)
> > Sent: vrijdag 4 december 2009 15:43
> > To: Colin Perkins; Qin Wu
> > Cc: Rob Drisko (rdrisko); [e-mail]; Bill Ver Steeg (versteb)
> > Subject: Re: [AVT] the use of "mediasender
> > SSRC"indraft-ietf-avt-rapid-acquisition-for-rtp-05
> >
> > > > The open question is what we set the media sender SSRC in the 
> > > > feedback messages we sent if we don't know what it is. One idea
> is
> 
> > > > to set it to something but also add a field that says the media 
> > > > sender SSRC in that field is unknown and should be ignored by 
> > > > the server.
> > > >
> > > > [Qin] It depends on how do you intepret value zero fo SSRC, it 
> > > > does not matter using value zero or value 0xFFFFFFFF or any 
> > > > other value to indicate client does not know media sender SSRC.
> > >
> > >
> > > All values in the range 0x00000000 - 0xffffffff are legal SSRC
> values.
> > > You cannot use them to signal that the client does not know the 
> > > media sender's SSRC.
> >
> > Indeed. IMO, if the SDP does not specify the media sender SSRC for a

> > specific multicast stream, then the feedback target responsible for 
> > that RTP stream should not be validating the media sender SSRC field

> > of the incoming feedback messages. In addition, we can still add a 
> > field to the feedback report to make this explicit. If anybody has a

> > better alternative, please speak up.
> >
> > -acbegen
> >
> >
> > > --
> > > Colin Perkins
> > > http://csperkins.org/
> > >
> > >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt