[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