Subject: Re: [AVT] New draft of "Rapid Acquisition of Multicast RTP Sessions (RAMS)" available

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 21 Apr 2009 14:55:03 +0200

Hi

I have read through the updated draft and have a few comments and requests for your consideration.

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. 
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.
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. 
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). 
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)

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 !
*******************************************

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 21 Apr 2009 11:28:23 -0700

Hi Ingemar, 

> 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.

> 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.

> 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
> 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.
>
> 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.
> 

These could be all addressed if/when we decide to combine the mcast bursting support.

Thanks again for the detail review.

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

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Sat, 25 Apr 2009 14:25:45 +0200

Hi

Sorry for the delay, see my comments inline

Regards
Ingemar 

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: den 21 april 2009 20:28
> To: Ingemar Johansson S; [email-masked]
> Cc: Bill Ver Steeg (versteb)
> Subject: RE: [AVT] New draft of "Rapid Acquisition of 
> Multicast RTP Sessions(RAMS)" available
> 
> Hi Ingemar, 
> 
> > Hi
> > 
> > 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 
> > 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.

> > 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: 
> > 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.
> > 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.
> > 
> > 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)
> 
OK

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 25 Apr 2009 13:50:33 -0700

> 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.

Agree.

> 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. 

It can. However, remember that in a highly-loaded environment, if RS cannot provide (unicast) acceleration, it can deny the request. For the sake of doing multicast bursting (to save bandwidth), if RRs experience a slower acquisition (due to a large Td, for example) compared to a simple join, that is not good.

> 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). 

I don't think I have that study, either. But, there is a recent study in IMC 2008. Here is the link.
http://portal.acm.org/ft_gateway.cfm?id=1452529&type=pdf&coll=portal&dl=ACM

The results are in general more or less similar to what we found in one of our own studies. The figure you will find interesting is Figure 14. 

For the most popular channel, the entire data set shows that on average 14 viewers tune into that channel per second (Figure 14a). Of course, there are occasions where a lot more viewers may tune at approximately the same time (within the same second), but this is for the top-ranked channel and the number 14 includes all viewers in the data set, which is about 250K (This is what I got from the text). If we consider only a subset of these viewers will be served by the same RS, the concurrency we will get in a single server will be far smaller, impying that multicast burst will not be needed most of the time.

Different studies may suggest different numbers based on the regional characteristics. So, I don't think we should read too much into this study. If there are other studies, please post them here. So, we can make a better judgment.

> 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. 

There can be a TLV in the request to do this, no? 

BR,
-acbegen

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 30 Apr 2009 15:41:33 +0200

Hi

Some more comments below

Regards
/Ingemar 

> Sent: den 25 april 2009 22:51
> > > 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.
> 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.
> > 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.
> 
> It can. However, remember that in a highly-loaded 
> environment, if RS cannot provide (unicast) acceleration, it 
> can deny the request. For the sake of doing multicast 
> bursting (to save bandwidth), if RRs experience a slower 
> acquisition (due to a large Td, for example) compared to a 
> simple join, that is not good.
My feeling here is that a multicast solution for RAMS would help to keep
the load on a lower level and thus will avoid that a RAMS request is
denied.

> 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).
> 
> I don't think I have that study, either. But, there is a 
> recent study in IMC 2008. Here is the link.
> The results are in general more or less similar to what we 
> found in one of our own studies. The figure you will find 
> interesting is Figure 14. 
> 
> For the most popular channel, the entire data set shows that 
> on average 14 viewers tune into that channel per second 
> (Figure 14a). Of course, there are occasions where a lot more 
> viewers may tune at approximately the same time (within the 
> same second), but this is for the top-ranked channel and the 
> number 14 includes all viewers in the data set, which is 
> about 250K (This is what I got from the text). If we consider 
> only a subset of these viewers will be served by the same RS, 
> the concurrency we will get in a single server will be far 
> smaller, impying that multicast burst will not be needed most 
> of the time.
> 
> Different studies may suggest different numbers based on the 
> regional characteristics. So, I don't think we should read 
> too much into this study. If there are other studies, please 
> post them here. So, we can make a better judgment.
I don't have any public links to the other reports (sorry) but I would
guess that the results are approximately similar. I see however one risk
in trying to compute median and mean from data that may have a very
large standard deviation like one can suspect in cases like this where
the the behavior is very bursty. 

> > > 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.
> > 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.
> 
Possible, need to investigate this option closer.