Re: [Rmt] WG Last Call: draft-ietf-rmt-flute-sdp-01
Vincent Roca <vincent.roca@inria.fr> Fri, 25 November 2011 17:41 UTC
Return-Path: <vincent.roca@inria.fr>
X-Original-To: rmt@ietfa.amsl.com
Delivered-To: rmt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6200A21F8B12 for <rmt@ietfa.amsl.com>; Fri, 25 Nov 2011 09:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Level:
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XWcFb+um39z for <rmt@ietfa.amsl.com>; Fri, 25 Nov 2011 09:41:46 -0800 (PST)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3207221F8B00 for <rmt@ietf.org>; Fri, 25 Nov 2011 09:41:46 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.69,572,1315173600"; d="scan'208";a="120898976"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.10]) ([82.236.155.50]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 25 Nov 2011 18:41:44 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <13CEFB51-3E02-4DF6-9EE9-0725BEEB7FC6@inria.fr>
Date: Fri, 25 Nov 2011 18:41:44 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <3BD7BDC5-B50B-47B3-9E54-712F9DE8F13F@inria.fr>
References: <FF659CA0-AA82-4FAB-B52B-493C29DE6A6D@nrl.navy.mil> <13CEFB51-3E02-4DF6-9EE9-0725BEEB7FC6@inria.fr>
To: rmt@ietf.org, Brian Adamson <brian.adamson@nrl.navy.mil>
X-Mailer: Apple Mail (2.1084)
Cc: Vincent Roca <vincent.roca@inria.fr>
Subject: Re: [Rmt] WG Last Call: draft-ietf-rmt-flute-sdp-01
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Nov 2011 17:41:47 -0000
Hi, As promised, here are my comments. You can ignore my previous email, this one encompasses the comments I've made last week. Cheers, Vincent -- ** Section 3. "FLUTE Descriptors": This section mentions, as an optional parameter, the FEC OTI. I've been confused by the use of FEC Object Transmission Information which non ambiguously refers to what is described in RFC5052, namely the association of {Mandatory, Common and Scheme-Specific} information. And this FEC OTI is per object, whereas we are not, at SDP level, discussing objects but sessions. The note on out-of-band FEC OTI (just after the list) clarifies the point, as well as Section 3.7 "FEC Object Transmission Information". If I understand correctly, the goal is just to communicate which FEC scheme(s) may be used by the sender (and should be supported by a receiver). I suggest to use a different wording than FEC OTI throughout this I-D, since this is misleading. ** Section 3.2.1. Composite Session Semantics for FLUTE Sessions I find this section a bit confusing on what is mandatory or useful. Okay for the first paragraph, but the second paragraph says: "It is useful for describing more than one FLUTE session in an SDP instance and so its general use and support in SDP are OPTIONAL." No, this is not "useful". This is REQUIRED. And in that case the sender should be sure that all receiver do support this CS mechanism. What is OPTIONAL is the use of the CS mechanism. When there is a risk that at least one receiver may not support it, then the sender must refrain from using it and revert to multiple SDP instances. IMHO you should remove (or clarify) the above sentence. ** Section 3.4. Transport Session Identifier: It is said: "TSI reuse is NOT RECOMMENDED whenever possible (thus, making "large time" unbounded regarding TSI reuse)." Well, with a 16-bit TSI field (a possible field size), an active server will have no other choice than reusing this value, sooner or later. This recommendation does not seem realistic to me. Why not saying that: "TSI reuse SHOULD NOT (or probably MUST NOT, TBC) happen before 30 minutes, and it is RECOMMENDED not to reuse it before a much longer duration". ** Section 3.5. "Session Timing Parameters" Are there good reasons to require that SDP descriptions include a start and end time? I agree that having a "start time" is good practice. But I'm not sure the end time is always known at session start. Second paragraph, same section: "Note, implementers may assume reasonable clock synchronisation between ..." Is it a "may" or a "SHOULD"? Having on one hand a "required timing parameter" and on the other hand a weak requirement on time synchronization is strange! ** Section 3.6.1. "Number of Channels" There are two ways to determine the number of channels, and the I-D says that in some cases (e.g. automatic or manual editing) there may be a difference. However the document does not provide clear recommendations on how to address such situations. Should a receiver give up? Should a receiver trust the "flute-ch" attribute if present? Something else? ** Section 3.6.2. "Destination IP Address and Port Number for Channels" It is said: "When more than one channel is used in a multicast FLUTE session, it is RECOMMENDED that the channels are differentiated based on destination IP address, and channels are not differentiated based on destination port" The previous section mentions unique {dest IP addr; dest port number} pairs. Recommending that only the dest IP be considered raises the risk that a bad implementation considers only the destination IP to differentiate channels. It seems dangerous. I understand the rational (congestion control with multicast group join/leave operations) though. Later, in the same section: "In the case (always with a unicast session) where the same destination IP address is used for all the channels of the session..." This is wrong to say it is **always with a unicast session**, since using different destination IP is only RECOMMENDED, not REQUIRED. ** Section 3.7. "FEC Object Transmission Information" There is a paragraph dedicated to Congestion Control that says: "The identification and description of any congestion control (CC) instance related to layered media (multiple FLUTE channels) is orthogonal to the FEC declarations and other aspects of this document. Hence, CC descriptions are not in scope of this document." Two comments: - CC discussion should not be placed in a section dedicated to FEC OTI. - why is CC considered as totally out of scope whereas its use is considered as an option in flute-revised (see section 4. "Channels, congestion control and timing" of this I-D), and whereas it is RECOMMENDED to use in LCT (section 4.3 of RFC5651). ** Section 3.10. "Bandwidth Specification" Can you say a few things about Congestion Control (CC)? Having only the peak data rate is not sufficient for a receiver. Having the capability, because CC is used, to receive data from that FLUTE session at a much lower rate, thanks to CC, is an important piece of information. ** Section 5. "Security Considerations": should emphasize the importance of providing integrity and authentication guaranties to SDP instances. This is already addressed in flute-revised, so it's not a big deal. A sentence with an explicit reference to section 7.3.1. "Attacks against the Session Description" of flute-revised should be sufficient. Is there anything else (e.g. is a replay attack an issue)?
- [Rmt] WG Last Call: draft-ietf-rmt-flute-sdp-01 brian.adamson
- Re: [Rmt] WG Last Call: draft-ietf-rmt-flute-sdp-… Vincent Roca
- Re: [Rmt] WG Last Call: draft-ietf-rmt-flute-sdp-… Vincent Roca