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

[Roni Even <[e-mail]>]

Hi,
>From the receivers point of view there is no association between the
original stream (this is the SSRC he sent) and the retransmission stream.
This is not in line with the association rules of RFC 4588 for session
multiplexing (section 5.3)
Roni Even as Individual

> -----Original Message-----
> From: VAN CAENEGEM Tom [mailto:[e-mail]]
> Sent: Wednesday, December 16, 2009 6:03 PM
> To: Roni Even; Bill Ver Steeg (versteb); 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
> 
> 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