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

Pekka Savola <pekkas@netcore.fi> Mon, 07 April 2008 08:01 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D4D3A6A4F; Mon, 7 Apr 2008 01:01:19 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB0E3A69AE; Mon, 7 Apr 2008 01:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP7LlQc62+Vq; Mon, 7 Apr 2008 01:01:14 -0700 (PDT)
Received: from netcore.fi (eunet-gw.ipv6.netcore.fi [IPv6:2001:670:86:3001::1]) by core3.amsl.com (Postfix) with ESMTP id B5A183A6A4F; Mon, 7 Apr 2008 01:01:13 -0700 (PDT)
Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id m3781IU7024053; Mon, 7 Apr 2008 11:01:18 +0300
Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id m3781F9G024050; Mon, 7 Apr 2008 11:01:15 +0300
Date: Mon, 7 Apr 2008 11:01:15 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: ietf@ietf.org
Subject: Re: Last Call: draft-ietf-rmt-bb-norm-revised (Multicast Negative-Acknowledgment (NACK) Building Blocks) to Proposed Standard
In-Reply-To: <20080403140021.9211F28C5C9@core3.amsl.com>
Message-ID: <alpine.LRH.1.10.0804071058380.23953@netcore.fi>
References: <20080403140021.9211F28C5C9@core3.amsl.com>
User-Agent: Alpine 1.10 (LRH 962 2008-03-14)
MIME-Version: 1.0
X-Virus-Scanned: ClamAV 0.92.1/6635/Sun Apr 6 19:29:31 2008 on otso.netcore.fi
X-Virus-Status: Clean
Cc: rmt@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

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