Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 31 Mar 2009 14:45:56 -0400

One of the primary action items arising from the review of the Rapid
Acquisition of Multicast Streams  draft is to identify which fields are
mandatory (and thus fixed format) and which fields are optional (and
thus TLV format). Here is my take on the matter. Once we reach
consensus, I will update the draft.
 
I have also included a description of the requested "motivating text"
for the fields that do not already have such text in the document.
Please let me know if I am on the right track.
 
There is currently no version number in the messages. Ali and I do not
think that this is a problem because we can add new TLVs as needed. I
want to be sure we intentionally decide on this point rather than back
into it accidently. Any comments?
 
We have 3 messages - 
 
RAMS-Request
 Max Receive BitRate - mandatory
 Min Buffer Fill Requirement - optional ( Add wording - The receiver may
have knowledge of it's buffering requirements. These requirements may be
application or device specific. For instance, the receiver may need to
have a certain amount of data in it's application buffer to handle
interdependency within the data. If the RS knows the buffering ability
of the receiver, it may more precisely tailor the burst to the client.
The methods used by the receiver to determine this value is application
specific, and thus out of scope. This mechanism can be used by the
receiver to signal the sender, if the receiver has such knowledge )
 Max Buffer Fill Requirement - optional ( Add wording - The receiver may
have knowledge of it's buffering requirements. These requirements may be
application or device specific. For instance, one receiver may have more
physical memory than another receiver, and thus can buffer more data. If
the RS knows the buffering ability of the receiver, it may more
precisely tailor the burst to the client. The methods used by the
receiver to determine this value is application specific, and thus out
of scope. This mechanism can be used by the receiver to signal the
sender, if the receiver has such knowledge )
 
RAMS- Inform
 message Sequence Number - mandatory
 Response - mandatory, will include an enumerated list of response codes
- 0 is succeed, non zero is an error code. We will enumerate a list of
error codes, and note that additional error codes are possible using
vendor-specific TLV fields. The enumerated errors will include [No
server resources, No network resources, bad RMS-R request, WHAT
ELSE????] Note - we have removed the "join now semantic, as that is
captured in the "earliest join time" field. 
 Reserved - mandatory - must be all 0s
 Max Burst Bitrate - mandatory 
 Rapid Acquisition Duration - mandatory - 0 means "join now" (Add
wording to reflect that this is the server's current value, and can be
changed by subsequent RMS-I. Add wording to reflect that the RS can't
consume resources forever and needs to deterministically stop the flow.
The RS MUST terminate the flow at this time, even if does not get RMS-T
from the RR.  ) 
 Extended RTP Sequence Number of First Burst Packet - mandatory
 Earliest IGMP Join Time - optional (we should consider making this
mandatory in at least one RMS-I, as the client needs to eventually join)
 
Rams -Terminate - 
  Extended RTP seqnum of First Multicast packet - optional (intent is to
tell the RS the seqnum at which to stop the burst, but leave the session
open. If the field is not present, it means "stop now")

Bill VerSteeg

---

From: Tom Taylor <[email-masked]>
Date: Tue, 31 Mar 2009 15:08:16 -0400

A few comments marked with [PTT]

>  Max Receive BitRate - mandatory
[PTT] What units?

>  Min Buffer Fill Requirement - optional 
[PTT] Your added wording doesn't quite indicate what this means. How about 
adding at the beginning (if I have the right idea):

"The minimum number of octets (?) of content the receiver must have in its 
buffer in order to process the incoming burst."

( Add wording - The receiver may
> have knowledge of it's buffering requirements. These requirements may be
                     its

>  Max Buffer Fill Requirement - optional 
[PTT] Again not quite clear what this means. How about:
"The maximum number of octets (?) the receiver can buffer without losing 
incoming burst data due to buffer overflow."

( Add wording - The receiver may
> ELSE????] 
[PTT] If the RAMS-Inform can be sent autonomously rather than always as a 
response, you need an "Unspecified" Response value.

Note - we have removed the "join now semantic, as that is
>  Rapid Acquisition Duration - mandatory - 0 means "join now" 
Could you add a definition at the beginning, e.g.:
"Maximum duration of acquisition burst that the server is prepared to support 
(milliseconds ?)."

(Add
>  Earliest IGMP Join Time - optional 
[PTT] Again, a definition. I am too clueless to hazard a guess here, but the 
definition must include a time base (is this wallclock time, time measured from 
when the RMS-I is received, or what?) and time units. Also, what is the reason 
it would be non-zero, or what must happen before IGMP join is possible? Is there 
an indication of what the receiver has to do when this time elapses?

(we should consider making this
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt