[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - Fixed and TLV fields
A few comments marked with [PTT]
Bill Ver Steeg (versteb) wrote:
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
[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
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
[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
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????]
[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
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"
Could you add a definition at the beginning, e.g.:
"Maximum duration of acquisition burst that the server is prepared to support
(milliseconds ?)."
(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
[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
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
------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt