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

From: <[email-masked]>
Date: Mon, 1 Jun 2009 11:47:02 +0200

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" <[email-masked]> 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 ?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 01 Jun 2009 12:00:51 +0200

[email-masked] skrev:
>>> “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? :)
> 
> “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: [email-masked]
----------------------------------------------------------------------

---

From: "Watson, Mark" <[email-masked]>
Date: Mon, 1 Jun 2009 09:04:07 -0700

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" <[email-masked]> wrote:

[email-masked] skrev:
>>> "For example the choice of congestion control algorithm. I think we
> 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
> 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
> "Most of the practitioners of ALC protocols have found the greatest use
> To provide for this 'practical application to broadcast' and 'flexible
> use on the open internet' dual nature of ALC CC, FLUTE originally had
> 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
> lines of the original FLUTE text would be ideal."
>
> is a high level of WG confidence, making it mandatory in the "forward to
> open internet" case sounds sensible, otherwise not.
>
> totally misjudged the context - my 6 monthly RMT email review just came

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 02 Jun 2009 13:16:36 +0200

Watson, Mark skrev:
> 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.

No, I don't think so. Because the variations are different for different
protocols. Sure, congestion control comes up pretty often. However, it
is generaly need also for none Internet usage. It is only when you both
reserve resources and ensure that the traffic provided over that
resource matches the reservation that you can be pretty certain that you
don't need congestion control. Even in these cases you commonly need to
deal with failure modes.

So, no even if reoccurring what goes into this often has variations and
special considerations.

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

Yes, for an SDO like DVB can clearly specify that you don't need to
implement congestion control because the traffic will always be ingress
filtered and shaped before being broadcasted. Thus congestion isn't a
real issue. However, I know that some IETFers do not like when other
SDOs profile our standards. There is a risk in profiling both from
interoperability and correct function.

Cheers

Magnus

---

From: "Watson, Mark" <[email-masked]>
Date: Tue, 2 Jun 2009 09:45:49 -0700

Magnus,

What I was suggesting as a standard RFC section a bit like "Security Considerations" in which the "Other domains" requirements should be collected, with guidelines as to what kind of thing should go in there. Then the rest of the document is unambiguously applicable to the Internet domain. Obviously the content of this section would be very dependent on the protocol being defined.

In a sense, this section would be the IETF doing the necessarily profiling for other standards groups itself (hopefully avoiding the risks you cite below). This happens anyway, but I'm suggesting we make it more explicit so that we do not keep repeating the argument about whether Internet domain requirements are MUST or SHOULD for protocols which have other domains of applications.

...Mark

On 6/2/09 4:16 AM, "Magnus Westerlund" <[email-masked]> wrote:

Watson, Mark skrev:
> 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

>
> It is not clear to me why the domain-specific standards bodies can't

Cheers

Magnus
_______________________________________________
Rmt mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rmt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Jun 2009 10:50:30 +0200

Watson, Mark skrev:
> Magnus,
> 
> What I was suggesting as a standard RFC section a bit like “Security
> Considerations” in which the “Other domains” requirements should be
> collected, with guidelines as to what kind of thing should go in there.
> Then the rest of the document is unambiguously applicable to the
> Internet domain. Obviously the content of this section would be very
> dependent on the protocol being defined.
> 
> In a sense, this section would be the IETF doing the necessarily
> profiling for other standards groups itself (hopefully avoiding the
> risks you cite below). This happens anyway, but I’m suggesting we make
> it more explicit so that we do not keep repeating the argument about
> whether Internet domain requirements are MUST or SHOULD for protocols
> which have other domains of applications.

Sorry Mark, I don't understand how I am going to be able to write such a
section without knowing which domain it is for. Only when you know your
domain and what features it has can you determine what you may not
require in terms of security protocol or congestion control, or
configuration support.

Maybe, I am misunderstanding you?

Cheers

Magnus Westerlund

---

From: Brian Adamson <[email-masked]>
Date: Wed, 3 Jun 2009 09:00:33 -0400

As Magnus says, I don't think you could write the section ahead of  
time without knowing the domain.

But, perhaps something that could be done in such a similar section  
would be to identify the specific aspects / requirements on the  
protocol that are due to "Internet Considerations" as opposed to the  
aspects/requirements of the protocol for its general operation.  Then,  
this section would provide a focal point for profiling for other (non- 
Internet) domains ... i.e, the profiling could address any deviations  
from the "Internet Considerations".  For example, mandated congestion  
control would be identified in that "Internet Considerations" section  
and other profiles could then specify their own qualifications and/or  
deviations from considerations such as congestion control, security,  
etc that might not be germain to the protocol's operation in those  
other domains ...

Just some thoughts on what Mark suggested.  Probably some IESG thought  
would be in order here?

Brian Adamson
[email-masked]

---

From: "Watson, Mark" <[email-masked]>
Date: Wed, 3 Jun 2009 10:19:14 -0700

Hi Magnus,

I think you have overestimated the scope of my proposal (or I have overstated it). I am thinking something almost editorial in nature. I'm not suggesting that anyone try to write text which is generic across multiple protocols or multiple arbitrary domains.

What I'm suggesting is that if you have requirements for a specific protocol which are applicable to a *specific non-Internet domain*, then these should be collected into a "Requirements for non-Internet domains" section, rather than spread throughout the rest of the document. (Equally there could be requirements for non-Internet domains with specific well-defined properties - such as the text suggested by Rod for ALC which refers to "unidirectional fully provisioned (at a lower layer) channels".)

The advantages are

 *   if this section is deleted, you then have a complete protocol specification that meets the requirements for Internet usage and this would be a very clear and unambiguous policy.
 *   other SDOs have an clear place into which to propose their domain-specific requirements, without the usual confusion about whether those requirements mess things up for Internet usage.

It just seems to me that there is a process discussion about non-Internet requirements which we repeat every time, and perhaps with guidance from the IESG that repetition could be avoided.

...Mark

On 6/3/09 1:50 AM, "Magnus Westerlund" <[email-masked]> wrote:

Watson, Mark skrev:
> Magnus,
>
> What I was suggesting as a standard RFC section a bit like "Security
> Considerations" in which the "Other domains" requirements should be
> risks you cite below). This happens anyway, but I'm suggesting we make

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Jun 2009 17:32:46 +0200

Watson, Mark skrev:
> Hi Magnus,
> 
> I think you have overestimated the scope of my proposal (or I have
> overstated it). I am thinking something almost editorial in nature. I’m
> not suggesting that anyone try to write text which is generic across
> multiple protocols or multiple arbitrary domains.
> 
> What I’m suggesting is that if you have requirements for a *specific
> protocol* which are applicable to a *specific non-Internet domain*, then
> these should be collected into a “Requirements for non-Internet domains”
> section, rather than spread throughout the rest of the document.
> (Equally there could be requirements for non-Internet domains with
> specific well-defined properties – such as the text suggested by Rod for
> ALC which refers to “unidirectional fully provisioned (at a lower layer)
> channels”.)
> 
> The advantages are
> 
>     * if this section is deleted, you then have a complete protocol
>       specification that meets the requirements for Internet usage and
>       this would be a very clear and unambiguous policy.
>     * other SDOs have an clear place into which to propose their
>       domain-specific requirements, without the usual confusion about
>       whether those requirements mess things up for Internet usage.
> 
> 
> It just seems to me that there is a process discussion about
> non-Internet requirements which we repeat every time, and perhaps with
> guidance from the IESG that repetition could be avoided.
> 

Mark,

Okay, I understand your proposal better.

I think this is hard to do in a generic fashion as each specific domain
requires its considerations both technical and politically. In cases it
makes sense I can see writing up such recommendations for a specific
other domain.

However, what are you suggesting in regards to this document?

Cheers

Magnus Westerlund