[manet] Notes on draft-ietf-manet-smf-05
"Joseph Kopena" <tjkopena@cs.drexel.edu> Tue, 14 August 2007 02:53 UTC
Return-path: <manet-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKmXI-0003PQ-BJ; Mon, 13 Aug 2007 22:53:36 -0400
Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IKmXG-0003CO-71 for manet-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 22:53:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKmXF-0003CD-TJ for manet@ietf.org; Mon, 13 Aug 2007 22:53:33 -0400
Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKmXF-0001B6-DG for manet@ietf.org; Mon, 13 Aug 2007 22:53:33 -0400
Received: by rv-out-0910.google.com with SMTP id f1so1204314rvb for <manet@ietf.org>; Mon, 13 Aug 2007 19:53:32 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=LiFaQCg0gLaW8JfI+4UrwrasvdGYORmq2DvmHKsXy/dakPfGSIgrypBolO7P15LkoVy0ndhqI3KdXU+AnUi7WBvG+TdB87pMkYgKsvuVgkhXljzEtx+ETjwWNXSwkFCSwCbrPR/YGBuSuILq+/q2Zan1CrDaH2+KxzlBWQPDI9I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=NtOfN0D38UFAdFnuvGvHpdE6ir7p/RgtM3I7QjmGs8IdnC8k9a3Hn5MLhjlx33r/vCRPUGXFS+gExiWLGSOv6FkGaUg33kMXODGqDFVrrFCmdToUSmsHQooIM+htju5SD+c8qdb3YI3NHR7MXHZDdK0P/4wl/CgCZhxXGzEMDXI=
Received: by 10.140.141.15 with SMTP id o15mr2843349rvd.1187060012507; Mon, 13 Aug 2007 19:53:32 -0700 (PDT)
Received: by 10.141.53.2 with HTTP; Mon, 13 Aug 2007 19:53:32 -0700 (PDT)
Message-ID: <13786f330708131953l133ad9d0k5b8c743b544c371e@mail.gmail.com>
Date: Mon, 13 Aug 2007 22:53:32 -0400
From: Joseph Kopena <tjkopena@cs.drexel.edu>
To: manet@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Google-Sender-Auth: 677f0dbb09e7524a
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Subject: [manet] Notes on draft-ietf-manet-smf-05
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
Errors-To: manet-bounces@ietf.org
For what it's worth, some comments after a read-through of the current SMF document follow. Thx! ------- Notes on draft-ietf-manet-smf-05 [ Technical Notes ] fragmentation: While I understand reasons for not including fragmentation support, I think it is something that should be considered. It doesn't seem to be difficult or expensive to add, requiring just the inclusion of the fragment offset in the DPD (am I missing something?). Fragmented datagrams probably aren't the best idea, but I have been "given" several applications to run over a MANET that faced problems because of this. It might be nice, if it indeed doesn't cost much, if these programs would at least work in relatively benign settings, which they currently don't. However, my feelings aren't very strong about this. [ Document Notes ] general: The document is pretty clear, although perhaps not as much without some familiarity with MPR (i.e. papers in the literature). Just one line saying what these algorithms are trying to do (i.e. reduce forwarded traffic) might address that. For example, immediately after the sentence "The main goals of the SMF specification... and to adapt efficient reduced relay set designs in MANET environments." in the abstract, it could be noted that "SMF implementations and sites may use a number of such algorithms, each varying in factors such as retransmission traffic volume, processing complexity, control requirements, and delivery reliability." This is be a non-issue if it the document is not aimed toward people without some MANET/broadcast background info. appendix d: It would be nice if there was a 1-line summary or statement of what these algorithms attempt to accomplish, or the intuition behind them. Several of the are not discussed earlier in the draft, and just something quick would be useful. NS-MPR in particular stands out for this. pg 40: This section closes on "Further algorithm examples and details are covered in the Appendices," but we are already in the Appendices and there aren't many more details coming up. Perhaps change to note that pseudo-code is in Appendix D? pg 40: This seemed to be the first place the SMF_HELLO symbol was used. Although it's pretty clear what this is talking about, it is somewhat odd. I assume the text was taken from another source or any earlier version that included more details about the actual NHDP process/messages. [ Typographic Notes ] pg 19: "operate in concert" should be "operating in concert." pg 23: "Appendices.z" should be "Appendices." ------- -- - joe kopena right here and now _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet
- [manet] Notes on draft-ietf-manet-smf-05 Joseph Kopena