Re: WEBRC session description questions

Hi Rod, RMT folks,

 From my implementation experience of WEBRC (publicly available cf. 
[LIBMCC] below) all these parameters may be communicated out of band 
since the RFC defines that a receiver MUST acquire a session description 
communicated out of band (i.e. containing the multicast address of the 
base channel, the UDP port of the base channel, etc.). For example, in 
our implementation these parameters are sent by the application out of 
band via a unicast TCP connection before each receiver initiate the 
session: for our experiments we use a custom protocol dedicated to this 
session description, but you are free to use an email, a web page, a sdp 
file, etc.

Otherwise, the in-band computation/detection may take a time dependent 
of BCR_P. Here the details concerning your different questions:

1. LENP_B - the length of packets in bytes. Calculated from the first 
packet, indeed.

2. T - the total number of time slots in a cycle. Corresponds to the CN 
of the base channel and is known from the first packet received.

3. BCR_P - the transmission rate of the base channel at the beginning of 
a time slot in packets per second. Measured after joining. Since the 
rate of the base channel starts each new TSI at BCR_P and ends 10 
seconds later with a rate of ( BCR_P * P ), a receiver have to wait for 
the next TSI in order to determine the BCR_P value (min_time = 0 s, 
max_time = 10 s, mean_time = 5 s). Indeed, this rate may be computed by 
measuring the delay (in seconds) between the two first packets received 
during a TSI (let us name it "INTER_P_DELAY"): BRC_P = 1 / INTER_P_DELAY.

4. N - the duration in time slots for each wave can be computed directly 
with: N = T - Q. Please note that for the "constant rate" question 
below, N is also equivalent to the number of active groups including the 
base group : N = floor( log_P( BCR_P / SR_P ) ).

5. TSD, P, Q - may be communicated out of band if needed. From my point 
of view, these are likely to be fixed for practically all cases.

6. L - must be computed using:
L = ceil( BCR_P * TSD * (P-1) / log( P ) ).

I agree with the flag used to signal if the "constant aggregate rate" 
technique is used. As the rate SR_P can be computed by using BRC_P and 
N, there is no need to specify the constant aggregated rate used.

I not sure to understand the point of your question about CN 
semantic/labeling (some additional comments may be helpful), but CN 
numbering is fixed: i.e. a channel identified by a multicast group has 
always the same CN.

By the way, if you want to play with WEBRC an implementation is publicly 
available: cf. [LIBMCC] below. This library is experimental and has been 
used to evaluate WEBRC (which presents several weakness cf. [M2C]) and a 
solution called "Multicast Congestion Control (M2C)" protocol which as 
been designed to address WEBRC issues (notably in term of fairness).

Moreover, if RMT people are interesting in, a first draft version of the 
M2C specifications is available (cf. ref [M2C-DRAFT]).

- [LIBMCC] http://svnet.unistra.fr/mcc/
- [M2C] Fair Multicast Congestion Control (M2C)
     V. Lucas, J.-J. Pansiot, Dominique Grad, Benoit Hilt
     12th IEEE Global Internet Symposium 2009 (GI 2009)
     DOI: 10.1109/INFCOMW.2009.5072144
     http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5072144
- [M2C-DRAFT] http://lsiit-cnrs.unistra.fr/Publications/2010/LPGH10/

Regards,
Vincent Lucas

On 06/29/2010 10:21 AM, [email protected] wrote:
> Hi WEBRC folk
>
>  From this text from the WEBRC RFC3738...
>
> "Before joining a session the receiver MUST know the mapping between the
> CNs and the channels. Upon joining the session or shortly thereafter, it
> SHOULD have the values of LENP_B, BCR_P, TSD, P, N, L, Q and T. Some of
> these values may be computed or measured once the receiver has joined
> the session. For example, the receiver MAY obtain LENP_B and T from the
> first packet received from the base channel, and the receiver MAY
> measure BCR_P once it is joined to the base channel.  The values of P, Q
> and TSD MAY be fixed to default values built into the receiver that do
> not change from session to session, and the value of N MAY be computed
> as T-Q.  The receiver SHOULD know whether the sender is employing a
> technique to produce constant aggregate rate as described in [8]."
>
> Does anyone have a perspective on how trivial/complex and rapid/stalling the in-band detection or calculation would be for:
> 1. LENP_B - calculated from from first packet. That's minimal effort - right?
> 2. T - calculated from from first packet. That's minimal effort - right?
> 3. BCR_P - measured after joining. What kind of delay and processing is introduced?
> 4. N - simple calculation, no problem.
> 5. TSD, P, Q - must be communicated out of band. Are these likely to be fixed for practically all cases?
> 6. L - must be communicated out of band - right?
>
> We're thinking about a flag for "constant aggregate rate" - would the rate need communicating instead?
>
> Also, we're figuring out the CN semantics and whether ordering (and not explicit labelling) is sufficient.
>
> Cheers, Rod.
>
>
>
>
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rmt