Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard

[Brian Adamson <[e-mail]>]

Pekka,

I appreciate your comments here.  I plan to issue a new version of 
the draft that addresses these to the extent I can.  I have some 
questions about your concerns with comments in-line below:

At 11:01 AM +0300 4/7/08, Pekka Savola wrote:
>On Thu, 3 Apr 2008, The IESG wrote:
>>The IESG has received a request from the Reliable Multicast Transport WG
>>(rmt) to consider the following document:
>>
>>- 'Multicast Negative-Acknowledgment (NACK) Building Blocks '
>>   <draft-ietf-rmt-bb-norm-revised-04.txt> as a Proposed Standard
>>
>>The IESG plans to make a decision in the next few weeks, and solicits
>>final comments on this action.  Please send substantive comments to the
>>[e-mail] mailing lists by 2008-04-17. Exceptionally,
>>comments may be sent to [e-mail] instead. In either case, please
>>retain the beginning of the Subject line to allow automated sorting.
>
>Meta-level comments
>-------------------
>
>Looking at the document, my main question is, "is this ripe for standards
>track?".  Looking at it, my inclination would be to say "probably not, at
>least in parts *)".  As Section 6 says, there have not been 
>substantial changes
>since the preceding experimental RFC 3941 was published in 2004.  All the
>cited material (research etc.) predates RFC 3941.  So it seems that either
>1) there has not been significant experience since the Experimental document
>was published, 2) the experiences have been fully aligned with the earlier
>document ("the document was already good enough"), or 3) the lessons learned
>have not been reflected in this document revision.


I will see what updated references I can find.  As you mention later 
below, there are definitely updated references on SSM that would be 
better!

I think one aspect here is the fact that this is one of our RMT 
"Building Block" documents and the _general_ techiques that it 
describes with respect to NACK-based reliable multicast protocol 
design have stood the test of time including some that predates the 
Experimental (RFC 3941) specification.  There have been some long 
term deployment of these protocols, one of which I mention later 
below.  I think it is accepted within the RMT community that these 
are mature techniques.  I think your #2 above "the experiences have 
been fully aligned with the earlier document" is the case.  We 
actually had some considerable history with these types of protocols 
even prior to Experimental RFC publication.


>
>The one thing I'd have been interested in seeing is an applicability
>statement of reliable multicast and its different bits and pieces (beyond
>what's in Section 3.11) but that seems out of scope of this document.
>For example, it is not obvious to me which (if any) RMT mechanisms would be
>applicable in a context where I want to distribute video or voice where it
>isn't acceptable to buffer the stream too long to accommodate for data
>resends; it seems this NACK mechanism is geared towards bulk file transfer
>where this is not applicable.
>
>*) the parts I'm mostly concerned with are router assistance and 
>security (also touching the protocol/ops aspects when some receivers 
>are misconfigured or behind slow links).


The _focus_ of the current RMT protocols was purposefully scoped to 
address "bulk transfer".   I think this is described in the RFC3048 
(which this proposed document _should_ but fails to reference). 
While "bulk transfer" was the focus here, the Nack-Oriented Reliable 
Multicast (NORM) protocol (RFC 3941) does (RFC 3941 is a "Protocol 
Instantiation" that was derived from the earlier version of this 
"Building Block" document), in fact, provide for a _optional_ 
"stream" support that we have used for video and voice streams.  This 
feature was made "optional" so that one could have a compliant 
implementation that solely provided "bulk transfer" capability.


I agree that "router assistance" has not been followed through.  It 
was originally part of the RMT WG charter but we were unable to 
sustain activity in that area.

My _personal_ opinion is that since this is a "Building Block" 
document that it would not have been complete to fail to mention the 
_potential_ of intermediate system "assistance" (along the lines that 
was discussed in the working group at one point) to improve 
scalability and/or performance of NACK-based reliable multicast.  In 
fact, I have some work in progress in the context of wireless 
networks to re-examine what sort of "assistance" to end-to-end 
reliable flows that intermediate systems may be able to provide.  But 
this is certainly not a "fully-baked" area.  So this discussion 
_could_ be removed ... I suppose it will persist in the RFC 3941 for 
historical purposes until there is further interest in the area?

Similarly, since this is a "Building Block" document, it does not do 
an extremely deep dive on security solutions.  We have another 
document in development within the RMT WG that may serve to describe 
security vulnerabilities, etc for RMT protocols.  And, we (under the 
good guidance of our area director)  have strived in the revised 
"Protocol Instantiation" documents (which are detailed protocol 
specifications) to fully address security, providing a description of 
how to secure the protocols with IPsec, etc.


>
>Substantial
>-----------
>
>I was expecting to see some discussion of MTU and application framing issues
>with multicast.  Specifically, in a big multicast tree with dynamic
>membership, it could very well happen that when a new member joins, the
>lowest common denominator MTU decreases.  How is this scenario expected to
>be handled?   It may be that this issue has already been discussed somewhere
>else as it isn't specific to this document.

I think MTU discovery for multicast was not in the scope of the RMT 
working group.  In my personal opinion, I do think MTU discovery for 
multicast in general has not been well addressed, and there is more 
work that could be done here by someone.  Practical deployment tends 
to count on multicast apps to be properly preconfigured for MTU  (The 
RMT protocols do allow for configurable packet payload sizes to 
accommodate MTUs of different deployments).

It is _possible_ that the scalable feedback mechanisms described here 
_could_ be applied to find the lowest MTU (the techniques are used to 
get scalable feedback of group-wide minima/maxima for purposes of 
congestion control, NACK suppression, etc as mentioned in this 
document and some of the other RMT building blocks (e.g., TFMCC)).



>
>I doubt router/intermediate system assistance has seen very wide deployment
>and I don't think it is very feasible to expect to see that.  As this
>document is moving to Standards Track I would very much like to remove any
>recommendations for router assistance because I don't see those being
>implemented in any significant router implementation.  That means removing
>and rewording e.g. sections 2.7, 2.4, 3.10 and some others.


See my comments above on this.  This change could be made.


>
>    The sender's transmissions SHOULD make good utilization
>    of the available capacity (which may be limited by the application
>    and/or by congestion control).
>
>How do you figure out what is the available capacity?  Are you 
>referring to the capacity on sender's uplink or the collective 
>capacity of the receivers or both?  Do you adapt to the lowest 
>common denominator of all receivers (e.g., document previously 
>quoted 56Kbit/s modems..)?  Does this have security impact? (Similar 
>comment would apply to MTU/application framing aspects already 
>mentioned above.)

The TFMCC (congestion control) building block addresses automated 
rate adjustment.  We have made congestion control distinct from 
reliability.  It is a "single-rate" scheme and is subject to the 
lowest common denominator of all receivers.  If this is not 
sufficient or acceptable for an application, additional mechanisms to 
eject poor-performing receivers from the group may be needed.

The intent of the sentence above is that the protocol should strive 
to not have "dead-air" time to the extent possible.  In the past, 
some reliable multicast protocols (incl. NACK based) have had 
sender/receiver interaction conducted in distinct "rounds" (i.e. the 
sender sends some data and then waits for feedback before continuing 
or some variants of that) and has resulted in poor goodput.

I agree that some clarification of that statement above is needed to 
make this point clear.



>
>    In absence of a group size determination mechanism
>    a default group size value of 10,000 is RECOMMENDED for reasonable
>    management of feedback given the scalability of expected NACK-based
>    reliable multicast usage.
>
>What is the impact of this recommendation?  Is it safer to recommend 
>too small or big?  Given that this would likely be close to a world 
>record in production multicast group size, I'm not sure if this 
>recommendation is reasonable; if it is deemed reasonable, it would 
>be nice to have a citation justifying the number.  This is one area 
>where figures based on experimentation would have helped. However, 
>if recommending too big doesn't cause a problem even when the 
>typical default size would be 10, 50 or 100 receivers, then it would 
>be OK.


With the timer-based feedback suppression mechanism described, the 
"group size" estimate doesn't have to be very accurate to work and it 
is "safer" (with respect to impact on the network) to err on a larger 
group size.

In retrospect, the 10,000 value that was recommended was based on 
closer to the maximum group size that these protocols may be useful 
for.

In fact, the U.S. Postal Service has used a NACK-based protocol to 
deliver bulk data content to a group of 10,000 - 20,000 receivers in 
a single multicast group over a fairly limited IP-based VSAT delivery 
system.  This system was (and still is as far as I know) been used 
operationally on a daily basis for more than 5 years.

One of the references for this document is some work I did to assess 
(and to predict) the volume of feedback of these types of protocols 
with group sizes through this scale.

I can probably provide more clarification on the impact ... erring on 
the large size may add some extra latency to the NACK-based 
reliability process and require more buffering in the implementation 
to maintain state.


>
>    NACK-based reliable multicast is compatible with IP security (IPsec)
>    authentication mechanisms [RFC4301] that are RECOMMENDED for
>    protection against session intrusion and denial of service attacks.
>
>The details how one might apply IPsec to the unicast channel are absent.
>I'm not commenting on the multicast delivery part because that is somewhat
>covered though details are fuzzy.  Unicast has two major issues that I did
>not see clearly addressed:
>
>  1) malicious, misconfigured or under-performing (beyond small capacity
>     links etc.) receivers.  Is there even a way to differentiate between
>     these classes of receivers?  When these send a lot of NACK feedback,
>     progress of the stream is deterred.  How do you deal with this issue
>     (this is partly operations, protocol, and security problem)?


This is an issue.  I did try to point out that (but perhaps still too 
subtly) in the "Security Considerations" section.  The idea in the 
text there was to point out that SSM operation eliminates direct 
receiver<->receiver messaging, simplifying security such that only 
the sender need to authenticate/trust receiver operations.  For the 
case of IPsec, that means the sender implementation may have alot of 
Security Association state depending upon group size.  But I thought 
it beyond the scope of this "Building Block" document to go into the 
details of this.  It should more thoroughly addressed in any 
"Protocol Instantiations" that are made.


>
>  2) receiver authentication for the feedback back-channel; how could you
>     do it?  This seems unfeasible in practise if the expected default
>     group sizes (e.g. the recommended default of 10,000 receivers) would
>     be realized.

There indeed may be practical limitations on group size due to 
security.  I suppose it is comparable to a server that would need 
maintain alot of simultaneous secure TCP connections?  But again I am 
not sure it is in the scope of the NACK Building Block document to 
predict scalability limits of IPsec implementations?  But I suppose 
that some language could be added to point out these issues.  Would 
that address your concerns here?




>
>editorial
>---------
>
>The document header should have "Obsoletes: 3941" or similar; likewise in
>abstract/introduction.
>
>[McastModel] refers to a (good) SSM PhD dissertation, but I'd say reference
>to either RFC3569 or RFC4607 is probably more readily available and more
>appropriate in the IETF context.
>
>    1.  Multicast Sender Transmission
>
>    2.  NACK Repair Process
>
>    3.  Multicast Receiver Join Policies
>
>    1.  Node (member) Identification
>...
>
>In section 3, the building block numbering wraps around; there are two
>instances of building blocks 1-3.


I will fix _all_ of these.



-- 
Brian
__________________________________
Brian Adamson
<mailto:[e-mail]>
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf