[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

We seem to repeat a variant of this discussion quite often. I wonder if the IESG could recommend a standard pattern for addressing ‘non-Internet domains of application’ ?. For example there could be a standard RFC section “Other domains of application” in which you can specify deltas to the requirements of the rest of the RFC for specific non-Internet application domains or domains with specific properties. This would make it possible for the body of the RFC to be clear about the requirements for the Internet, without needing different smallprint for every case.

It is not clear to me why the domain-specific standards bodies can’t specify the deltas themselves, but generally they do prefer to be able to use a straightforward reference (i.e. For the IETF to have done their domain-specific thinking for them).

...Mark

On 6/1/09 3:00 AM, "Magnus Westerlund" <magnus.westerlund at ericsson.com> wrote:

Rod.Walsh at nokia.com skrev:
> 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 :)
>

Rod, I am fully aware that many of the usages of ALC are in environments
that has dedicated resources, like DVB and 3GPP MBMS. But for general
usage where you don't have dedicated and controlled resources I see
congestion control being a requirement you can't skip.

So is WEBRC broken, so far I haven't seen anything indicating that.
However, we clearly don't have the data to show that it is mature and
interoperable and everything to bring it to proposed standard. This is
an issue. Something for everyone in this WG to think about. Are you
confident that WEBRC works well enough to both prevent a congestion
collapse and provide reasonable service behavior?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------