[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
Sorry for the delay, see my comments inline
Regards
Ingemar
> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: den 21 april 2009 20:28
> To: Ingemar Johansson S; avt at ietf.org
> Cc: Bill Ver Steeg (versteb)
> Subject: 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 neat thing is that during low load conditions Td can be made very low such that in practice only one user is served by each request. This can be implemented with either unicast or multicast bursts that only serve one STB. As he load increases Td increases and more users that send a requests will be served by one multicast channel. As Td is limited some requests will be too late but they can too be collected and served by additional multicast feeds. Then depending on the distribuion the tail may be handled with unicast bursts. This is more or less an optimization issue on the servers.
The idea is not that the unicast and multicast alternatives should compete with one another, rather they should complement each other, due to the highly dynamic nature of channel switching behavior in a population both alternatives are useful. I do believe that the multicast solution can help to reduce deplyment cost.
I have tried to look for statistics on channel switching behavior and of what I have seen sofar the "peak-to-average" ratio of channel swithing density can be more than 5. This is seen in a master thesis with the title "TPTV traffic measuring & modeling" by Geng Yu (have not found it published anywhere yet).
> 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.
Sounds reasonable.
>
> 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.
Not sure that I agree here, it all depends on how the signaling is standardized. For instance an STB likely needs to declare its unicast/multicast preference or capability in the RAMS-R as the SDP's are likely only declarative.
>
> > 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.
Hmm... Sorry, did not see it.
>
> > 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.
I would appreciate the comments from others here, my argument sofar is that the cost is quite small but I agree that there are ways to solve future issues like using a completely new FMT. Problem here is maybe that it is difficult to foresee the future need.
>
> > 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.
OK
>
> 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
> >
>