Re: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06

[<[e-mail]>]

Hi All

Perhaps the WEBRC mandating suggestion is not the right response on CC...
>> "For example the choice of congestion control algorithm. I think we only have one that we can really use to satisfy the intended usage of large scale sessions. Why isn't this a required to implement feature?"
> "If I understand the WG discussion correctly, we should mandate the support of WEBRC for Congestion Control."

I feel that this (paraphrased) answer is not ideal "Oh, we didn't see that mass of RFC text about CC needs for multicast from around the time RMT was first chartered, how foolish, let's mandate WEBRCC now." (Mark, I hope you've still got the sense of humor to take this poke with a smile from fortress QC? :)

So I humbly suggest some assimilated form of this as the answer..
"Most of the practitioners of ALC protocols have found the greatest use of ALC in unidirectional fully provisioned (as a lower layer) channels such as 3GPP-MBMS and DVB-H. In these fully provisioned cases where the ALC packets are not subsequently forwarded, unmodified, from receivers to the open internet, a layer 3 or 4 CC mechanism is both redundant and potentially expensive. It is highly unlikely that a mandated one would be adopted in DVB and 3GPP for these kinds of applications, so mandating that in the ALC RFC may well lead to the SDO fragmentation that was previously diligently avoided through the hard work of RMT contributors. To provide for this 'practical application to broadcast' and 'flexible use on the open internet' dual nature of ALC CC, FLUTE originally had text that explicatively stated that no CC block was required in the case described above, but a CC block was required otherwise - but didn't mandate any CC instance - at that time WEBRC was the only IETF published candidate. At that time, the lack of wide scale implementation, interoperability maturing and performance validation led us to actively choose not to mandate WEBRC, though we did originally reference it. Several years have passed since those decisions and the MBMS and DVB-H applications characteristics remain the same, in the mean time the validity of WEBRC has not been disproven. So perhaps spec text along the lines of the original FLUTE text would be ideal."

The only caveat I have on this is the state of WEBRC. When proposed is was a brilliant contribution, in the time since how many distinct works have validated implementability or other performance metrics? If there is a high level of WG confidence, making it mandatory in the "forward to open internet" case sounds sensible, otherwise not.

(And apologies if I just arrived at the conversation midway through and totally misjudged the context - my 6 monthly RMT email review just came up, so my flow with RMT is not ideal either :)

Cheers, Rod.


On 13/05/2009 03:19, "ext Watson, Mark" <[e-mail]> wrote:

> Hi,
>
> I have reviewed the ALC PI and have some comments.
>
> 1. If one compare this one with the experimental one they are very
> similar. At least my expectation would be that a bit more details are
> actually nailed down on how one should do them to achieve interoperable
> implementations. For example the choice of congestion control algorithm.
> I think we only have one that we can really use to satisfy the intended
> usage of large scale sessions. Why isn't this a required to implement
> feature?
>
> The same thing can be said about normative to implement security
> features. Yes, here there are choices, but still specify one required to
> implement should be possible. If you have observant the NORM PI got this
> comment from the SECdir reviewer. And I think he was right, we should be
> clear on these.
>
> A question is if we need to specify one mandatory to implement FEC
> encoding?
>
> In general I am not against the flexibility the protocol allows for.
> However, it should be clear what you do need to implement for a
> base-line implementation.
>

If I understand the WG discussion correctly, we should mandate the support
of WEBRC for Congestion Control. I propose to replace the first sentence of
section 2.2 (Multiple Rate Congestion Control Building Block) with

"At a minimum, implementations of ALC MUST support [RFC3738]."

And reword the following paragraphs appropriately.

For security, as with NORM, we have text defining 'Baseline secure ALC
operation'. Do you think we should mandate support for this ?