Subject: Re: [AVT] Open issues in the RAMS draft

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 11 Aug 2009 02:32:15 -0700

Not much discussion on the mailing list. But, here is the suggested plan for each of the open items. If you have suggestions, objections, please send them by next week.

See inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen
> (abegen)
> Sent: Monday, July 27, 2009 2:28 PM
> To: [email-masked]
> Subject: [AVT] Open issues in the RAMS draft
> 
> Hi everyone,
> 
> Aside from the port mapping, we have the following open issues in the RAMS draft and would
> like to get the WG feedback before the next revision.
> 
> 1- Removing the S bit from the RAMS-I message. The support for the updated
> request/response mechanism will be conveyed out of band. We will provide the SDP attribute
> for this in the draft.

We will remove the S bit and define an SDP attribute.

> 2- Extending the "Response" field in the RAMS-I message to 16 bits (swallowing the S bit
> and Rsvd. bits) to be able to indicate more detailed response codes (app/vendor/generic
> codes)

We will make the "Response" field 16 bits.

> 3- Using SIP/HTTP-like response codes (maintained by IANA)

I have received offline comments that favored this suggestion, so we will go with this one.

> 4- Recommendation on sending a Sender Report with RAMS-I message (to provide faster timing
> synchronization and a way to indicate the extended seqnums)

We will add this recommendation in Section 6.

> 5- Using extended seqnums in the RAMS messages (RAMS-I and RAMS-T as well as the MA-XR
> report). Or, should we stick with the regular seqnums?

We will stick with the extended seqnums keeping in mind that wrapping might be an issue at high bitrates. To be able to use extended seqnums, sending a Sender Report right at the beginning of the burst will be needed. So, the recommendation in item 4 will be a "requirement" for such cases. Sending a sender report has other benefits as well (rapid synchronization as well as the detection of lost burst packets).

> Please provide your input. We will take these into consideration and (try to) complete the
> missing sections before the next revision. We will be sending the proposed text to the
> list for comments before posting the draft. We will also make clarifications for the
> buffer req TLVs in the RAMS-R message.

Suggested text:

   o  Min RAMS Buffer Fill Requirement (32 bits):  Optional TLV element
      that denotes the minimum number of octets of content RR 
      desires to have in its buffer as a result of the unicast burst.

      RR may have knowledge of its buffering requirements.
      These requirements may be application or device specific.  For
      instance, RR may need to have a certain amount of data
      in its application buffer to handle interdependency within the
      data or be able to support error-control methods. If RS is told 
      the buffering ability of the receiver, it may
      tailor the burst more precisely.  The methods used by RR
      to determine this value are application specific, and thus, out of
      scope.

      If specified, the amount of backfill that will be provided by the
      unicast burst SHOULD NOT be smaller than the specified value since it will
      not be able to build up the desired level of buffer at RR and may
      cause buffer underruns.

Suggested text for the security cons. section:

12.  Security Considerations

   Applications that are using RAMS make heavy
   use of the unicast feedback mechanism described in
   [I-D.ietf-avt-rtcpssm] and the payload format defined in [RFC4588].
   Thus, these applications are subject to the general security
   considerations discussed in [I-D.ietf-avt-rtcpssm] and [RFC4588].  In
   this section, we give an overview of the guidelines and suggestions
   described in these specifications from a RAMS perspective.  We also
   discuss the security considerations that explicitly apply to RAMS
   applications.

   First of all, much of the session description information is
   available in the SDP descriptions that are distributed to the media
   sources, Retransmission Servers and RTP Receivers.  Adequate security
   measures are RECOMMENDED to ensure the integrity and authenticity of
   the SDP descriptions so that transport addresses of the media
   sources, Feedback Targets as well as other session-specific
   information can be authenticated.

   Compared to an RTCP NACK message that triggers one or more
   retransmissions, an RAMS Request (RAMS-R) message may trigger a new
   burst stream to be sent by the Retransmission Server.  Depending on
   the application-specific requirements and conditions existing at the
   time of the RAMS-R reception by the Retransmission Server, the
   resulting burst stream may contain potentially a large number of
   retransmission packets.  Since these packets are sent at a faster
   than the nominal rate of the multicast session, RAMS consumes more
   resources on the Retransmission Server, the RTP Receiver and the
   network.  This particularly makes denial-of-service attacks more
   intense, and hence, more harmful than attacks that target ordinary
   retransmission sessions.

   Following the suggestions given in [RFC4588], counter-measures SHOULD
   be taken to prevent tampered or spoofed RTCP packets.  Tampered
   RAMS-R messages may trigger inappropriate burst streams or alter the
   existing burst streams in an inappropriate way.  For example, if the
   Max Receive Bitrate field is altered by a tampered RAMS-R message,
   the updated burst may overflow the buffer on the receiver side, or
   oppositely, may slow down the burst to the point that it is useless.
   Tampered RAMS Termination (RAMS-T) messages may terminate valid burst
   streams pre-maturely resulting in gaps in the received RTP packets.
   RAMS Information (RAMS-I) messages contain fields that are critical
   for the success of the RAMS operation.  Any tampered information in
   the RAMS-I message may easily cause the RTP Receiver to make wrong
   decisions.  Consequently, the RAMS operation may fail.

   While most of the denial-of-service attacks can be prevented by the
   integrity and authenticity checks enabled by SRTP, an attack can
   still be started by legitimate endpoints that send several valid
   RAMS-R messages to a particular Feedback Target in a synchronized
   fashion and very short amount of time.  Since a RAMS operation may
   temporarily consume a large amount of resources, a series of the
   RAMS-R messages may temporarily overload the Retransmission Server.
   In these circumstances, the Retransmission Server will reject
   incoming RAMS requests until its resources become available again.
   One means to ameliorate to this threat is to apply a per-endpoint
   policing mechanism on the incoming RAMS requests.  A reasonable
   policing mechanism should consider application-specific requirements
   and minimize false negatives.

   In addition to the denial-of-service attacks, man-in-the-middle and
   replay attacks can also be harmful.  However, RAMS itself does not
   bring any new risks or threats other than the ones discussed in
   [I-D.ietf-avt-rtcpssm].

   [RFC4588] RECOMMENDS that the cryptography mechanisms are used for
   the retransmission payload format to provide protection against known
   plaintext attacks.  As discussed in [RFC4588], the retransmission
   payload format sets the timestamp field in the RTP header to the
   media timestamp of the original packet and this does not compromise
   the confidentiality.  Furthermore, if cryptography is used to provide
   security services on the original stream, then the same services,
   with equivalent cryptographic strength, MUST be provided on the
   retransmission stream per [RFC4588].

-acbegen

> Thanks.
> -acbegen
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Wed, 12 Aug 2009 18:20:06 +0200

Ali,

I am fine with all suggested changes.

Sime time ago, I proposed some changes to  section 6.2 for better
clarification, which was also triggered by roni's comments and
questions. Would you please consider to include these in the next
revision as well? I repeat the proposed changes here for your
convenience.... 

Please rewrite start of section 6.2  as follows:

> <START>
> 
> 6.2.  Message Flows
> 
>    Figure 2 shows the main entities involved in rapid acquisition:
> 
>    o  Multicast Source
> 
>    o  Feedback Target (FT)
> 
>    o  Burst/ Retransmission Source
> 
>    o  RTP Receiver (RR)
> 
> (fig 2)
> 
> 
> The feedback target (FT) is the entity as defined in [rtcpssm draft], 
> to which the RR sends its RTCP FB messages, indicating packet loss in 
> the ssm primary stream by means of a NACK or indicating the RR's 
> desire to have rapid acquisition of the ssm primary stream (by means 
> of an RTCP FB message as defined in this document). While the 
> burst/retransmission source is responsible for responding on these 
> messages and, in the case of rapid acquisition, further RTCP 
> interaction with the RR during this acquisition process, it is assumed

> in the remainder of the document that these two logical entities (FT 
> and burst/retransmission source) are combined in a single physical 
> entity and share state. In the remainder of the text, the term 
> retransmission server is used whenever appropriate, to refer to the 
> combined functionality of the FT and retransmission/burst source.
> However, it must be noted that only the FT is involved in the primary 
> ssm RTP session, whereas the burst/retransmission source transmits 
> unicast RTP burst and RTP retransmissions packets (both formatted  as 
> RTP retransmission packets
> [RFC4585]) in a single separate unicast RTP retransmission session to 
> each RR.
> 
> Note also that the same method (with the identical message flows) 
> would also apply in a scenario where rapid acquisition is performed by

> a feedback target co-located with the media source.
> 
> (...)

And further down, please make following clarifications for steps 2,8 and
4: 

Step 2: 

Add text: "Both the unicast burst and the RAMS-I message are transmitted
by the burst/retransmission source logical entity that is part of the
RS."

Step 8: 

Replace "Note that RR MUST send at least one RAMS-T message" by 

With

"Note that RR MUST send at least one RAMS-T message, and the RAMS-T
message MUST be addressed to the Burst source logical entity that is
part of the RS."  

Step 4 :

Replace  

"RR MAY send a new RAMS-R message with a different value for one or more
fields of an earlier RAMS-R message."  

with  

"RR MAY send a new RAMS-R message to the FT entity of the RS, with a
different value for one or more fields of an earlier RAMS-R  message."

I also noted now that in section 8.2, we now have:

 "A feedback target that receives an RAMS-R feedback message becomes
   aware that the prediction chain at the RTP receiver side has been
   broken or does not exist any more.  If the necessary conditions are
   satisfied (as outlined in Section 7 of [RFC4585]) and available
   resources exist, the feedback target MAY react to the RAMS-R message
   by sending any transport-layer and payload-specific feedback
   message(s) and starting the unicast burst."

We should have in line 5 : "the RS MAY react to the RAMS-R message
   by sending any transport-layer and payload-specific feedback
   message(s) and starting the unicast burst." (instead of the FT
MAY...)

Finally, in section 1 (Introduction) we mention several times FT and say
that FT actually sends the retransmission/burst packets, which is
conflicting with our definitions.. So these should be replaced with
retransmission server.

Thanks,
Tom

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: dinsdag 11 augustus 2009 11:32
To: [email-masked]
Cc: Bill Ver Steeg (versteb); Zeev Vax; VAN CAENEGEM Tom
Subject: RE: [AVT] Open issues in the RAMS draft

Not much discussion on the mailing list. But, here is the suggested plan
for each of the open items. If you have suggestions, objections, please
send them by next week.

See inline.

> Aside from the port mapping, we have the following open issues in the 
> RAMS draft and would like to get the WG feedback before the next
revision.
> 
> 1- Removing the S bit from the RAMS-I message. The support for the 
> updated request/response mechanism will be conveyed out of band. We 
> will provide the SDP attribute for this in the draft.

> 2- Extending the "Response" field in the RAMS-I message to 16 bits 
> (swallowing the S bit and Rsvd. bits) to be able to indicate more 
> detailed response codes (app/vendor/generic
> codes)

> 3- Using SIP/HTTP-like response codes (maintained by IANA)

I have received offline comments that favored this suggestion, so we
will go with this one.

> 4- Recommendation on sending a Sender Report with RAMS-I message (to 
> provide faster timing synchronization and a way to indicate the 
> extended seqnums)

> 5- Using extended seqnums in the RAMS messages (RAMS-I and RAMS-T as 
> well as the MA-XR report). Or, should we stick with the regular
seqnums?

We will stick with the extended seqnums keeping in mind that wrapping
might be an issue at high bitrates. To be able to use extended seqnums,
sending a Sender Report right at the beginning of the burst will be
needed. So, the recommendation in item 4 will be a "requirement" for
such cases. Sending a sender report has other benefits as well (rapid
synchronization as well as the detection of lost burst packets).

> Please provide your input. We will take these into consideration and 
> (try to) complete the missing sections before the next revision. We 
> will be sending the proposed text to the list for comments before 
> posting the draft. We will also make clarifications for the buffer req
TLVs in the RAMS-R message.

Suggested text:

      If specified, the amount of backfill that will be provided by the
      unicast burst SHOULD NOT be smaller than the specified value since
it will
      not be able to build up the desired level of buffer at RR and may
      cause buffer underruns.

-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 14 Aug 2009 15:17:02 +0300

Hi Ali,

I would like to suggest to change the semantics of the min buff req field as
follows.

   o  Min RAMS Buffer Fill Requirement (32 bits):  Optional TLV element
      that denotes the minimum number of octets of content RR 
      desires to have in its buffer before feeding data to the media decoder
for decoding.

      RR may have knowledge of its buffering requirements.
      These requirements may be application and/or device specific.  For
      instance, RR may need to have a certain amount of data 
      in its application buffer to handle transmission jitter and/or to be
able 
      to support error-control methods. If RS is told the minimum buffering 
      requirement of the receiver, it may tailor the burst more precisely,
e.g., 
      by choosing an appropriate starting point. The methods used by RR
      to determine this value are application specific, and thus, out of
      the scope of this document.

      If specified, the amount of backfill that will be provided by the
      unicast burst SHOULD NOT be smaller than the specified value since it 
      may not be able to build up the desired level of buffer at RR and may
      cause buffer underruns.
 
BR, YK

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Tuesday, August 11, 2009 12:32 PM
> To: [email-masked]
> Cc: VAN CAENEGEM Tom; Bill Ver Steeg (versteb)
> Subject: Re: [AVT] Open issues in the RAMS draft
> 
> Not much discussion on the mailing list. But, here is the 
> suggested plan for each of the open items. If you have 
> suggestions, objections, please send them by next week.
> 
> See inline.
> 
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > Ali C. Begen
> > (abegen)
> > RAMS draft and would like to get the WG feedback before the 
> next revision.
> > 
> > well as the MA-XR report). Or, should we stick with the 
> regular seqnums?
> 
> We will stick with the extended seqnums keeping in mind that 
> wrapping might be an issue at high bitrates. To be able to 
> use extended seqnums, sending a Sender Report right at the 
> beginning of the burst will be needed. So, the recommendation 
> in item 4 will be a "requirement" for such cases. Sending a 
> sender report has other benefits as well (rapid 
> > posting the draft. We will also make clarifications for the

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 14 Aug 2009 15:28:01 +0300

A quick comment.  

> "Note that RR MUST send at least one RAMS-T message, and the 
> RAMS-T message MUST be addressed to the Burst source logical 
> entity that is part of the RS."  
> 

I think both the old and new text have a problem. A sentence starting with
"Note" indiciates that the content is informative. Therefore, those
normative or binding words like "MUST" should not be used. If you do want
the normative or binding effect, the sentence should not start with "Note". 

BR, YK

> Behalf Of VAN CAENEGEM Tom
> Sent: Wednesday, August 12, 2009 7:20 PM
> To: Ali C. Begen (abegen); [email-masked]
> Cc: Bill Ver Steeg (versteb)
> Sime time ago, I proposed some changes to  section 6.2 for 
> better clarification, which was also triggered by roni's 
> comments and questions. Would you please consider to include 
> these in the next revision as well? I repeat the proposed 
> changes here for your convenience.... 
> 
> 
> Add text: "Both the unicast burst and the RAMS-I message are 
> transmitted by the burst/retransmission source logical entity 
> that is part of the RS."
> 
> 
> Step 8: 
> 
> "Note that RR MUST send at least one RAMS-T message, and the 
> RAMS-T message MUST be addressed to the Burst source logical 
> entity that is part of the RS."  
> 
> 
> Step 4 :
> 
> Replace  
> 
> "RR MAY send a new RAMS-R message with a different value for 
> one or more fields of an earlier RAMS-R message."  
> 
> with  
> 
> "RR MAY send a new RAMS-R message to the FT entity of the RS, 
> with a different value for one or more fields of an earlier 
> RAMS-R  message."
> 
> 
> Finally, in section 1 (Introduction) we mention several times 
> FT and say that FT actually sends the retransmission/burst 
> packets, which is conflicting with our definitions.. So these 
> should be replaced with retransmission server.
> 
> 
> Thanks,
> Tom
> 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 14 Aug 2009 06:09:02 -0700

This is (mostly) fine to me. I would rather prefer not to specifically refer to decoding/decoder in the first para. though.

Also, it was suggested that we used ms instead of bytes in the min/max buffer req fields. I believe it makes sense to do so.

-acbegen

> From: Ye-Kui Wang [mailto:[email-masked]]
> Sent: Friday, August 14, 2009 3:17 PM
> Cc: 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb)

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 14 Aug 2009 16:33:09 +0300

> Sent: Friday, August 14, 2009 4:09 PM
> To: Ye-Kui Wang; [email-masked]
> This is (mostly) fine to me. I would rather prefer not to 
> specifically refer to decoding/decoder in the first para. though.
> 

OK, then what lauguage would you use?

> Also, it was suggested that we used ms instead of bytes in 
> the min/max buffer req fields. I believe it makes sense to do so.
> 

That's fine. 

BR, YK

> > I would like to suggest to change the semantics of the min buff req 
> > field as follows.
> > 
> >       desires to have in its buffer before feeding data to 
> the media 
> > decoder for decoding.
> > 
> >       in its application buffer to handle transmission 
> jitter and/or 
> > to be able
> >       requirement of the receiver, it may tailor the burst more 
> > precisely, e.g.,
> > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > Of Ali C. Begen (abegen)
> suggested 
> > > plan for each of the open items. If you have suggestions, 
> > > objections, please send them by next week.
> > >
> > > See inline.
> > >
> > > > updated request/response mechanism will be conveyed out 
> of band. 
> > > > We will provide the SDP attribute for this in the draft.
> > >
> > > wrapping might be an issue at high bitrates. To be able to use 
> > > extended seqnums, sending a Sender Report right at the 
> beginning of 
> > > the burst will be needed. So, the recommendation in item 
> 4 will be a 
> > > "requirement" for such cases. Sending a sender report has other 
> > > benefits as well (rapid synchronization as well as the 
> detection of 
> > > lost burst packets).
> > >
> > >
> > > > (try to) complete the missing sections before the next 
> revision. 
> > > > We will be sending the proposed text to the list for comments 
> > > > before posting the draft. We will also make 
> clarifications for the
> > >       If specified, the amount of backfill that will be 
> provided by 
> > > the
> > >       unicast burst SHOULD NOT be smaller than the 
> specified value 
> > > since it will
> > >       not be able to build up the desired level of buffer 
> at RR and 
> > > may
> > >       cause buffer underruns.
> > >
> > >
> > >    considerations discussed in [I-D.ietf-avt-rtcpssm] and 
> [RFC4588].  
> > > In
> > >    measures are RECOMMENDED to ensure the integrity and 
> authenticity 
> > > of
> > >    the application-specific requirements and conditions 
> existing at 
> > > the
> > >    RAMS-R messages may trigger inappropriate burst 
> streams or alter 
> > > the
> > >    existing burst streams in an inappropriate way.  For 
> example, if 
> > > the
> > >    Tampered RAMS Termination (RAMS-T) messages may 
> terminate valid 
> > > burst
> > >    the retransmission payload format to provide 
> protection against 
> > > known
> > > > Audio/Video Transport Working Group [email-masked]

---

From: David R Oran <[email-masked]>
Date: Fri, 14 Aug 2009 09:34:53 -0400

> the normative or binding effect, the sentence should not start with  
I don't necessarily agree with the logic that "note" implies non- 
normative, but this is easy to change. I'm ok with simply:
s/Note that/The

>> provided by the
>> [RFC4588].  In
>> authenticity of
>> existing at the
>> example, if the

---

From: David R Oran <[email-masked]>
Date: Fri, 14 Aug 2009 09:38:11 -0400

> specifically refer to decoding/decoder in the first para. though.
Right. RAMS can be used for applications that don't involve decoding  
or rendering of content. How about:
"...minimum milliseconds of data the RR desires to have in its buffer  
before allowing the data to be consumed by the application".

> Also, it was suggested that we used ms instead of bytes in the min/ 
> max buffer req fields. I believe it makes sense to do so.
>
Right - my change above reflects that.

>> field as
>> precisely,

---

From: Ye-Kui Wang <[email-masked]>
Date: Fri, 14 Aug 2009 16:44:29 +0300

That's a very good language. 

BR, YK 

> From: David R Oran [mailto:[email-masked]] 
> Sent: Friday, August 14, 2009 4:38 PM
> To: Ali C. Begen (abegen)
> Cc: Ye-Kui Wang; [email-masked]; VAN CAENEGEM Tom; Bill Ver 
> Steeg (versteb)
> specifically 
> > refer to decoding/decoder in the first para. though.
> >
> Right. RAMS can be used for applications that don't involve 
> decoding or rendering of content. How about:
> "...minimum milliseconds of data the RR desires to have in 
> its buffer before allowing the data to be consumed by the 
> application".
> 
> >>      These requirements may be application and/or device 
> specific.   
> >> For
> >>      by choosing an appropriate starting point. The 
> methods used by 
> >> RR
> >>      to determine this value are application specific, and 
> thus, out 
> >> of
> of band. We 
> revision. We 
> >>>      to determine this value are application specific, 
> and thus, out 
> >>> of
> >>>      scope.
> >>>
> >>>   burst stream to be sent by the Retransmission Server.  
> Depending 
> >>> on
> >>>   RAMS-R messages may trigger inappropriate burst streams 
> or alter 
> >>> the
> >>>   for the success of the RAMS operation.  Any tampered 
> information 
> >>> in

---

From: Colin Perkins <[email-masked]>
Date: Tue, 18 Aug 2009 16:28:35 +0100

On 11 Aug 2009, at 10:32, Ali C. Begen (abegen) wrote:
> Not much discussion on the mailing list. But, here is the suggested  
..
>> 5- Using extended seqnums in the RAMS messages (RAMS-I and RAMS-T  
>> as well as the MA-XR report). Or, should we stick with the regular  
>> seqnums?
>
> extended seqnums, sending a Sender Report right at the beginning of  
> the burst will be needed. So, the recommendation in item 4 will be a  
> benefits as well (rapid synchronization as well as the detection of  
> lost burst packets).

I agree that sending an SR is a good thing, but I'm still not clear on  
the benefits of extended sequence numbers here.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 Aug 2009 11:39:37 -0700

> the benefits of extended sequence numbers here.

In applications using small packets and/or high bitrates, wrapping will be an issue in a matter of minutes if not seconds. 

-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 20 Aug 2009 11:02:11 +0300

All,

Here is another open issue not included in the original list from Ali.

During the presentation of draft-wang-avt-rtp-improved-rams-00 in Stockholm,
it was agreed to allow for simultaneously requesting a unicast burst and
joining the primary multicast session, and many of the discussions were on
whether the existing draft already allows for the behaviour and how
explicitly the behaviour should be specified. 

After carefully checking the draft, I believe that the RAMS draft does not
allow for the behaviour. Here are the identified places in the RAMS draft
that excludes the possiblity of simultaneously requesting a unicast burst
and joining the primary multicast session:

- The definition of Rapid Acquisition of Multicast Sessions (RAMS), copied
below from subsection 6.1, excludes the possibility of simultaneously
requesting the unicast burst and the joining the primary multicast session. 
   Using an accelerated rate (as compared to the rate of the primary
   multicast stream) for the unicast burst implies that at a certain
   point in time, the payload transmitted in the unicast burst is going
   to be the same as the payload multicast in the SSM session, i.e., the
   unicast burst will catch up with the primary multicast stream.  At
   this point, the RTP receiver no longer needs to receive the unicast
   burst and can join the primary multicast session.  This method is
   referred to as the Rapid Acquisition of Multicast Sessions (RAMS).

- The steps in subsection 6.2, which "describe rapid acquisition in detail",
exclude the possibility of simultaneously requesting a unicast burst and
joining the primary multicast session. 

- Subection 6.4 (Failure Cases) does not include any case of simultaneously
requesting a unicast burst and joining the primary multicast session.

Please let me know if my conclusion above is incorrect. I would like to get
confirmation before suggesting concrete text changes. 

BR, YK

> Sent: Tuesday, August 18, 2009 9:40 PM
> To: Colin Perkins
> Cc: VAN CAENEGEM Tom; [email-masked]; Bill Ver Steeg (versteb)
> In applications using small packets and/or high bitrates, 
> wrapping will be an issue in a matter of minutes if not seconds. 
> 
> -acbegen 
> 
>  
> > --
> > Colin Perkins
> > http://csperkins.org/
> > 
> > 
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 20 Aug 2009 02:46:03 -0700

YK,

> Sent: Thursday, August 20, 2009 11:02 AM
> To: Ali C. Begen (abegen); 'Colin Perkins'
> Cc: 'VAN CAENEGEM Tom'; [email-masked]; Bill Ver Steeg (versteb)

This was part of the discussion. Main concern was that the approach proposed in that draft requires >2x bandwidth, which we can never be sure to get in a non-managed network. Ow, I believe, everybody agreed that this would do more harm than benefit.

If 2x bandwidth is available, still RAMS might perform better. But, I won't get into the details.
 
>    referred to as the Rapid Acquisition of Multicast Sessions (RAMS).

I don't see any problem with this text.

> joining the primary multicast session.

We need to put the steps into an order and I believe the current ordering makes the most sense.

> requesting a unicast burst and joining the primary multicast session.

It is an overview of basic failure cases and what actions need to be taken. If the client is implementing some "alternative" methods, I think it is the one who needs to deal with them when something wrong happens.

> confirmation before suggesting concrete text changes.

As I mentioned earlier, the main issue in your draft is the high bandwidth requirement and its implications, not the integration with RAMS.

-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 20 Aug 2009 13:25:39 +0300

Ali,

> > During the presentation of draft-wang-avt-rtp-improved-rams-00 in 
> > Stockholm, it was agreed to allow for simultaneously requesting a 
> > unicast burst and joining the primary multicast session, 
> and many of 
> > the discussions were on whether the existing draft already 
> allows for 
> > the behaviour and how explicitly the behaviour should be specified.
> 
> This was part of the discussion. Main concern was that the 
> approach proposed in that draft requires >2x bandwidth, which 
> we can never be sure to get in a non-managed network. 

This comment is not fair. This concern was not mentioned during the meeting,
otherwise they would not be those discussions on whether it is already
supported and how explict the spec should be. But of course you can raise it
here. 

Both the draft
(http://tools.ietf.org/id/draft-wang-avt-rtp-improved-rams-00) and the
presentation (http://www3.ietf.org/proceedings/75/slides/avt-4.pdf) explain
why it is possible to have >= 2x bandwidth. 

In a non-managed network, you cannot even be sure to get 1x bandwidth. The
point is that it is possible to have more bandwidth. This is the
pre-condition of any form of RAMS.

> Ow, I 
> believe, everybody agreed that this would do more harm than benefit.
> 

This is the first time for me to see this argument. Could you please clarify
what is the harm and explain why the harm, if any, is more than the
benefits. 

> If 2x bandwidth is available, still RAMS might perform 
> better. But, I won't get into the details.

Both the draft the presentation explain why the proposed behaviour would
help, and no counter arguments were received during the presentation. But
again, you can explain now why and when RAMS would be worse. Without details
a statement like can never be convincing.

I am not responding to your other comments, as there is no meaning to debate
on those without agreement on whether to allow for simultaneously requesting
a unicast burst and joining the primary multicast session.

BR, YK 

> Sent: Thursday, August 20, 2009 12:46 PM
> To: Ye-Kui Wang; Colin Perkins
> > During the presentation of draft-wang-avt-rtp-improved-rams-00 in 
> > Stockholm, it was agreed to allow for simultaneously requesting a 
> > unicast burst and joining the primary multicast session, 
> and many of 
> > the discussions were on whether the existing draft already 
> allows for 
> > the behaviour and how explicitly the behaviour should be specified.
> 
> This was part of the discussion. Main concern was that the 
> approach proposed in that draft requires >2x bandwidth, which 
> we can never be sure to get in a non-managed network. Ow, I 
> believe, everybody agreed that this would do more harm than benefit.
> 
> If 2x bandwidth is available, still RAMS might perform 
> better. But, I won't get into the details.
>  
> > After carefully checking the draft, I believe that the RAMS 
> draft does 
> > not allow for the behaviour. Here are the identified places in the 
> > RAMS draft that excludes the possiblity of simultaneously 
> requesting a 
> > unicast burst and joining the primary multicast session:
> > 
> > - The definition of Rapid Acquisition of Multicast Sessions (RAMS), 
> > copied below from subsection 6.1, excludes the possibility of 
> > simultaneously requesting the unicast burst and the joining 
> the primary multicast session.
> > - The steps in subsection 6.2, which "describe rapid acquisition in 
> > detail", exclude the possibility of simultaneously requesting a 
> > unicast burst and joining the primary multicast session.
> 
> > - Subection 6.4 (Failure Cases) does not include any case of 
> > simultaneously requesting a unicast burst and joining the 
> primary multicast session.
> 
> It is an overview of basic failure cases and what actions 
> need to be taken. If the client is implementing some 
> "alternative" methods, I think it is the one who needs to 
> deal with them when something wrong happens.
> 
>  
> > Please let me know if my conclusion above is incorrect. I 
> would like 
> > to get confirmation before suggesting concrete text changes.
> 
> As I mentioned earlier, the main issue in your draft is the 
> high bandwidth requirement and its implications, not the 
> integration with RAMS.
> 
> -acbegen
> 
>  
> > BR, YK
> > 
> wrapping 
> > > will be an issue in a matter of minutes if not seconds.
> > >
> > > -acbegen
> > >
> > >
> > > > --
> > > > Colin Perkins
> > > > http://csperkins.org/
> > > >
> > > >
> > >

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 20 Aug 2009 12:43:32 +0200

Hi Ye-Kui,

I was unable to attend the IETF meeting, so perhaps the questions I
have,  may have been addressed there.  I have quoted your intro text
here below, with my questions embedded. My understanding now is that I
do not see any merits when RTP SSM and RAMS Burst streams are acquired
at the same time.
Regards, 
Tom

Nevertheless, RAMS has the following constraints:

   o  At some point, if the receiver directly joins the multicast
      group, the received multicast stream may start exactly at a
      random access point or at a point that is very close to the next
      random access point.  In this case, the use of the RAMS method
      actually increases the acquisition delay.  Unfortunately, the
      receiver has no means to know how far the next random access
      point in the multicast stream is before it joins the multicast
      group, otherwise it could choose to either use RAMS or directly
      join the multicast group, whichever is better.

<<TOM: why do you state above that "in this case RAMS actually increases
the acquisition delay"?>>

   o  The request for the unicast burst stream may be lost.  Even if
      the request is retransmitted and finally received, the
      acquisition delay gets increased.

<<TOM: same may be true for the IGMP request: chances of loss are the
same whether there is a RAMS-R transmitted or an IGMP join by the RR>>

   o  Part or all of the RI may be lost.  Again, the lost information
      could be retransmitted, which increases the acquisition delay.
      If the RI or part of it gets finally lost in any case, the
      received data in the unicast burst stream cannot be processed
      until the next random access point.  In this case, the
      acquisition delay would also be lower if the receiver had chosen
      to directly join the multicast group without trying to request
      the unicast burst stream.  Unfortunately, there is no way for
      the receiver to know what loss could happen before the
      occurrence of the loss. 

<<TOM:  RI may also be lost in the RTP multicast stream when forwarded
to the RR.  There can be packet loss protection techniques applied for
both RAMS burst packets and for SSM RTP flows -both impacting the
aquisition delay- but this is a separate discussion>>

-----Original Message-----
From: Ye-Kui Wang [mailto:[email-masked]] 
Sent: donderdag 20 augustus 2009 12:26
To: 'Ali C. Begen (abegen)'; 'Colin Perkins'
Cc: VAN CAENEGEM Tom; [email-masked]; 'Bill Ver Steeg (versteb)'
Subject: RE: [AVT] Open issues in the RAMS draft

Ali,

> This was part of the discussion. Main concern was that the approach 
> proposed in that draft requires >2x bandwidth, which we can never be 
> sure to get in a non-managed network.

This comment is not fair. This concern was not mentioned during the
meeting, otherwise they would not be those discussions on whether it is
already supported and how explict the spec should be. But of course you
can raise it here. 

Both the draft
(http://tools.ietf.org/id/draft-wang-avt-rtp-improved-rams-00) and the
presentation (http://www3.ietf.org/proceedings/75/slides/avt-4.pdf)
explain why it is possible to have >= 2x bandwidth. 

In a non-managed network, you cannot even be sure to get 1x bandwidth.
The point is that it is possible to have more bandwidth. This is the
pre-condition of any form of RAMS.

> believe, everybody agreed that this would do more harm than benefit.

This is the first time for me to see this argument. Could you please
clarify
what is the harm and explain why the harm, if any, is more than the
benefits. 

Both the draft the presentation explain why the proposed behaviour would
help, and no counter arguments were received during the presentation.
But
again, you can explain now why and when RAMS would be worse. Without
details
a statement like can never be convincing.

I am not responding to your other comments, as there is no meaning to
debate
on those without agreement on whether to allow for simultaneously
requesting
a unicast burst and joining the primary multicast session.

BR, YK

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 20 Aug 2009 03:49:42 -0700

YK,

> supported and how explict the spec should be. But of course you can raise it

Sorry if this was not clear but this was one of the comments I made. Before me, there were similar comments. But, I will only speak for myself here.

> pre-condition of any form of RAMS.

Sure, but the question is how we will use that bandwidth. It makes a "huge" difference whether I reserve my whole available bw to RAMS only or share it between RAMS + primary. 

The concern here is if RAMS traffic starts competing with primary stream and this causes collateral damage, we will not get anything useful. 
 
> what is the harm and explain why the harm, if any, is more than the

See above (and this is what I said in the meeting).

> a statement like can never be convincing.

I am not saying RAMS is worse, I am saying RAMS is better. Dedicating the resources to the unicast burst initially and then switching to multicast will perform faster acquisition. In theory, if the current point in multicast transmission is very close to a TSRAP point, server can ask the receiver to join the multicast right away (rather than starting a burst). This is, what I said, available in our draft. We can work out the math in the next meeting if you like.

One point worth to consider in practice is that in mpeg2-ts video, there won't be many "magical" tsrap points (from where you can start decoding immediately). Simply starting from an I frame does not cut it (as explained in our other draft). Many other components are required by the decoder, so, almost always starting a unicast burst will perform better since the unicast burst will provide exactly that information to the receiver in the shortest amount of time.

HTH,
-acbegen

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 20 Aug 2009 16:16:12 +0300

Ali, 

> Sure, but the question is how we will use that bandwidth. It 
> makes a "huge" difference whether I reserve my whole 
> available bw to RAMS only or share it between RAMS + primary. 
> 
> The concern here is if RAMS traffic starts competing with 
> primary stream and this causes collateral damage, we will not 
> get anything useful. 
>  

Sending both requests simultaneously does not necessarily mean that the two
streams will compete with each other. Note that the current RAMS draft
already allows coexistence of the burst stream and the primary multicast
stream during the process. Sending both requests simultaneously does not
necessarily mean that the co-existence duration of two streams will be
longer. 

> > clarify what is the harm and explain why the harm, if any, is more 
> > than the benefits.
> 

See above. 

> > Both the draft the presentation explain why the proposed behaviour 
> > would help, and no counter arguments were received during the 
> > presentation. But again, you can explain now why and when 
> RAMS would 
> > be worse. Without details a statement like can never be convincing.
> 
> I am not saying RAMS is worse, I am saying RAMS is better. 
> Dedicating the resources to the unicast burst initially and 
> then switching to multicast will perform faster acquisition. 
> In theory, if the current point in multicast transmission is 
> very close to a TSRAP point, server can ask the receiver to 
> join the multicast right away (rather than starting a burst). 
> This is, what I said, available in our draft. We can work out 
> the math in the next meeting if you like.
> 

I meant the other one (sorry for the confusion). Definitely we need to work
out the math, preferably before the next meeting. 

> One point worth to consider in practice is that in mpeg2-ts 
> video, there won't be many "magical" tsrap points (from where 
> you can start decoding immediately). Simply starting from an 
> I frame does not cut it (as explained in our other draft). 

For that part I will try to verify whether that is always the case from the
MPEG-2 TS spec.

> Many other components are required by the decoder, so, almost 
> always starting a unicast burst will perform better since the 
> unicast burst will provide exactly that information to the 
> receiver in the shortest amount of time.
> 

Let's try to work out the math before drawing a conclusion. Contrary to
yours, my feeling is that sometimes requesting both will be better. 

BR, YK

> Sent: Thursday, August 20, 2009 1:50 PM
> > meeting, otherwise they would not be those discussions on 
> whether it 
> > is already supported and how explict the spec should be. 
> But of course 
> > you can raise it here.
> 
> Sorry if this was not clear but this was one of the comments 
> I made. Before me, there were similar comments. But, I will 
> only speak for myself here.
> 
>  
> > Both the draft
> > 
> Sure, but the question is how we will use that bandwidth. It 
> makes a "huge" difference whether I reserve my whole 
> available bw to RAMS only or share it between RAMS + primary. 
> 
> The concern here is if RAMS traffic starts competing with 
> primary stream and this causes collateral damage, we will not 
> get anything useful. 
>  
> > > Ow, I
> > clarify what is the harm and explain why the harm, if any, is more 
> > than the benefits.
> 
> > Both the draft the presentation explain why the proposed behaviour 
> > would help, and no counter arguments were received during the 
> > presentation. But again, you can explain now why and when 
> RAMS would 
> > be worse. Without details a statement like can never be convincing.
> 
> I am not saying RAMS is worse, I am saying RAMS is better. 
> Dedicating the resources to the unicast burst initially and 
> then switching to multicast will perform faster acquisition. 
> In theory, if the current point in multicast transmission is 
> very close to a TSRAP point, server can ask the receiver to 
> join the multicast right away (rather than starting a burst). 
> This is, what I said, available in our draft. We can work out 
> the math in the next meeting if you like.
> 
> One point worth to consider in practice is that in mpeg2-ts 
> video, there won't be many "magical" tsrap points (from where 
> you can start decoding immediately). Simply starting from an 
> I frame does not cut it (as explained in our other draft). 
> Many other components are required by the decoder, so, almost 
> always starting a unicast burst will perform better since the 
> unicast burst will provide exactly that information to the 
> receiver in the shortest amount of time.
> 
> HTH,
> -acbegen
>  
> > debate on those without agreement on whether to allow for 
> > > sure to get in a non-managed network. Ow, I believe, everybody 
> > > agreed that this would do more harm than benefit.
> > >
> > > > - The definition of Rapid Acquisition of Multicast Sessions 
> > > > (RAMS), copied below from subsection 6.1, excludes the 
> possibility 
> > > > of simultaneously requesting the unicast burst and the joining
> > > > - The steps in subsection 6.2, which "describe rapid 
> acquisition 
> > > > in detail", exclude the possibility of simultaneously 
> requesting a 
> need to be 
> > > taken. If the client is implementing some "alternative" 
> methods, I 
> > > think it is the one who needs to deal with them when 
> something wrong 
> > > happens.
> > >
> > >
> > > As I mentioned earlier, the main issue in your draft is the high 
> > > bandwidth requirement and its implications, not the 
> integration with 
> > > RAMS.
> > >
> > > -acbegen
> > >
> > >
> > > > BR, YK
> > > >

---

From: Ye-Kui Wang <[email-masked]>
Date: Thu, 20 Aug 2009 16:54:42 +0300

Hi Tom,

See inline below, please.  

> From: VAN CAENEGEM Tom [mailto:[email-masked]] 
> Sent: Thursday, August 20, 2009 1:44 PM
> To: Ye-Kui Wang; Ali C. Begen (abegen); Colin Perkins
> Cc: [email-masked]; Bill Ver Steeg (versteb)
> I was unable to attend the IETF meeting, so perhaps the 
> questions I have,  may have been addressed there.  I have 
> quoted your intro text here below, with my questions 
> embedded. My understanding now is that I do not see any 
> merits when RTP SSM and RAMS Burst streams are acquired at 
> the same time.
> Regards,
> Tom
>  
> 

At a point as stated above, if the receiver directly joins the primary
multicast session, it does not need to wait for the Reference Information,
which is the root problem the RAMS scheme is trying to solve, to before
starting to process the received data. But you are right that at this moment
requesting a burst does not necessarily increase the acquisition delay.
However, it increases the inter-user playback delay, as described in
draft-yang-avt-rtp-synced-playback-00
(http://tools.ietf.org/id/draft-yang-avt-rtp-synced-playback-00).

> same whether there is a RAMS-R transmitted or an IGMP join by the RR>>

Correct. But if you send both requests, then the probability of losing both
is significantly reduced. 

> aquisition delay- but this is a separate discussion>>

Correct again. Similar as above, when receiving both streams under the
condition that the available bandwidth is >= 2x the media rate, the
probablity of losing RI in both streams will be significantly reduced.

BR,YK

> whether it is
> acquisition in

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 20 Aug 2009 15:41:17 -0700

> streams will compete with each other. Note that the current RAMS draft

If the burst starts flowing and RR starts receiving the multicast as well, the unicast burst and the primary multicast stream will be sharing the available bw. This means there will be less bw for the burst. The rate of the burst must be controlled so that it won't congest the link, causing drops on either of the streams.

Now, assuming that the primary multicast stream has delivered the reference information, RR can start consuming the data. In this case, you will naturally terminate the burst immediately since it won't be needed any more. This is all cool and I believe this is the use case you are targeting.

But the problem here IMO is that the chances for this to happen is pretty slim. In almost all other cases, the burst will be used by RR *earlier* than the multicast stream since the burst always starts from a "random access point" with the reference information. In such cases, the data received on the multicast will not be useful until a later time. What I am saying is that it would have been wiser to use the whole bw for the unicast burst rather than dividing it between the unicast and multicast.

> stream during the process. Sending both requests simultaneously does not

Sure, depending on the implementation an overlap may exist. The smaller it is, more efficient we are.

> necessarily mean that the co-existence duration of two streams will be

True, it does not necessarily mean that in theory. But, in practice, it will be longer especially for complex media such as mpeg2-ts.

-acbegen