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
> ietf@xxxxxxxx mailing lists by 2008-04-17. Exceptionally,
> comments may be sent to iesg@xxxxxxxx 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.
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).
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 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.
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.)
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.
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)?
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.
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.
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf