[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions(RAMS)" available
Hi Ingemar,
> Hi
>
> I have read through the updated draft and have a few comments
> and requests for your consideration.
Thanks for the review.
> In general (as I hinted before) I would like this draft to
> not just discuss the unicast version of RAMS, instead I would
> like it to also incorporate the multicast version into the framework.
While I see the common goal for these two methods, I believe the one you proposed is an additional enhancement on the unicast approach. Regarding whether they need to be combined or not, I have some comments below.
> I have looked into this and I would say that support for the
> multicast alternative as described in
> http://tools.ietf.org/id/draft-johansson-avt-mcast-based-rams-00.txt
> is fairly straightforward to add to the existing framework, I
> will describe in brief below the key additions that I see today.
I would not say it would be "fairly straighforward." To make the multicast bursting effective, many parameters need to be adjusted properly and optimized. Ow, it can easily degrade the performance even at the expense of additional complexity.
A concern I have which is not addressed in your document is that to make the proposal make sense, Td needs to be small enough. But, to ensure that all receivers join the burst mcast session before the burst starts, Td cannot be very small and RS should not admit last-minute RAMS requests for that multicast burst (they need to wait for the next batch). This is because if some receivers miss the first few packets of the burst, their acquisition will fail. Also, how many clients can the retransmission server aggregate in a single burst batch in a practical scenario? The eligible requests should be received within +/- a few hundereds of milliseconds. How practical is this, I wonder.
The selection of a common burst bitrate is also critical. If everybody supports a different burst bitrate and there is a large variation, multicast bursting will perform poorly for the well-connected clients. One solution could be to include the receivers with an available bw that is smaller than R1 and larger than R2 in the multicast pool. The very fast and very slow receivers should be still served via unicast.
My personal view is that the multicast bursting proposal will be a nice solution when the issues above (and possible others) are addressed, however, I think it should be a separate draft that normatively references the unicast draft. This way, we can keep the unicast draft more focused.
> The title of the draft would then become "Rapid Acquisition
> of Multicast RTP Sessions". I can offer to add the necessary
> parts in the document that describes the multicast based
> version of RAMS.
>
> Packet structure:
> In the draft, three FMT's are defined for the RAMS R,I and T
> messages. I wonder if it would be better to use one just one
> FMT for this "family" of messages and use a subtype to define
> R, I, T (or any other message). This was also brought up
> during the break-out session in SF.
This was indeed a good recommendation and we already took that into account, but we did not want to modify the packet formats too much to avoid any confusion in this version. If you look at the open items section, it is already there.
> Also I would consider a version field as well as there is a
> chance that things need to be changed in the future and TLV
> extensions may not solve all backwards compatibility issues
> in a satisfactory way (changing version number should not be
> too easy though, TLV elements should be the first choice).
In a later version, the meanings of the mandatory fields would not change and TLVs are optional anyway. So, why do you think new TLVs would not give you what you want? Not that I am against using a version field, but I would rather see a need for it.
> With this in mind the first 32 bits may look like:
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | ver |subtype| flags .... |reserved
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> In this example 3 bits are used for the version number and 5
> bits are used for the subtype but there may be a better
> distribution here. The number of bits for the flags and
> reserved field depends on the subtype
> The subtypes would be encoded as
> RAMS-R = 0
> RAMS-I = 1
> RAMS-T = 2
>
>
> Figure 2:
> A flow diagram that describes the multicast version to be added.
>
> Figure 3:
> A description that describes the multicast version to be added.
>
> Section 6.4: Failure cases
> An alternative to RAMS-T in the multicast version of RAMS is
> the use of IGMP-Leave (details about this are needed)
>
> Section 7.1 RAMS Request
> Here the 32 bit header is added (with subtype=0) and possibly
> the preference and or support of the multicast and the
> unicast version of RAMS can be defined in the flags field.
> The latter is likely needed as the SDP's are likely only declarative.
>
> Section 7.2 RAMS Information
> Here the 32 bit header is added (with subtype=1) and the
> MSN,S and Response field is put in the flags field.
> An additional TLV element is added that includes a multicast
> address and possibly other information such as expected delay
> until the multicast RAMS starts. This field is mandatory if
> the multicast address for RAMS is described in this way.
>
> Section 7.2 RAMS Termination
> Here the 32 bit header is added (with subtype=2)
> Note that RAMS-T may not be needed in the multicast version
> of RAMS (T.B.D)
These could be all addressed if/when we decide to combine the mcast bursting support.
Thanks again for the detail review.
BR,
-acbegen
> Comments to my comments are welcome
> Regards
> Ingemar
> *******************************************
> Ingemar Johansson
> Senior Research Engineer, IETF "nethead"
> EAB/TVP - Multimedia Technologies
> Ericsson Research Ericsson AB
> Box 920 S-971 28 Luleå, Sweden
> Tel: +46 (0)10 7143042
> ECN: 852-43042
> ECC: 852-19042
> Mobile: +46 (0)730 783289
> Visit http://labs.ericsson.com !
> *******************************************
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>