Subject: Re: [Smf-discussion] FW: next prerev

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 30 Jun 2005 23:11:02 -0700

Hello Joe,

Here are some comments about the draft.

- You can't design anything to use IPsec, because IPsec depends
   on unicast IP addresses and isn't specified for use with multicast,
   at least as far as I know.  It was very hectic using IPsec even for
   something as natural as Mobile IP with unicast addresses.

   This affects three or four paragraphs of the text.

- I would think the draft isn't ready for publication until something
  more definite can be said about the ways of insuring uniqueness.

- I would like to know which methods of hashing were tried and
   discovered to be too computationally intensive.  How about RCx?
   The function of protecting against accidental collision should not
   require any heavy duty encryption.  In fact, perhaps even just
   the IP checksum function would be probably sufficient with just
   a little bit of embellishment.

- Why is it prohibited to use link-local multicast for SMF?  It might
   be a useful tool for some layer 2 media types...

- The case of TTL == 1 is the most interesting case for the routing
   protocols, according to my understanding of network layer hop
   count, and SMF should be oriented towards that case.  What is
   stated in the draft about forwarding TTL = 1 has to be interpreted
   purely as a statement about network-layer forwarding, and DYMO
   for instance will need to touch the payload and retransmit even
   while requiring TTL == 1.  These same considerations were
   mentioned in the "bcast" draft I updated recently.

- If we can specify a source-independent CDS algorithm that works
  well, I think the advantages are great enough that we don't have to
  design towards the source-dependent cases.

- On page 10, there is a discussion about how some operating systems
  don't handle the sequence number as well as we would like.  I think
  that we should _specify_ the handling for the fields we need, and if
  a node wants to claim SMF compliance, then it has to comply.  It's
  not that hard to fix the code, and I reckon the code for SMF cannot
  fail to touch the network layer code in a node anyway.

- Here are some grammatical suggestions, and I noticed some typos:
  = pg. 1: "pragmatica" is wrong
  = pg. 5: "theoretical" level is better
  = pg. 6: insert "both" before "generated locally"
  = pg  6: third bullet has to cross reference the appropriate section
  = pg. 6: fifth bullet should be two sentences.
  = pg. 7: replace "IP Multicast" by "IP multicast"
  = pg. 9: replace "some different" by "various"
  = pg. 11: "agin" is misspelled.
  = pg. 11: "preventthe" needs a space

Regards,
Charlie P.

Joe Macker wrote:

>This body part will be downloaded on demand.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Smf-discussion mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/smf-discussion
>

_______________________________________________
Smf-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/smf-discussion

---

From: Brian Adamson <[email-masked]>
Date: Fri, 1 Jul 2005 08:05:17 -0400

Charlie,

Joe is out on vacation so I am answering on his behalf.  It's good to 
get some more conversation rolling on this stuff so your comments are 
terrific.  Of course, I have some comments on your comments to 
continue the thread ...

>   This affects three or four paragraphs of the text.

The idea here was that _if_ IPSec is used for multicast (which it has 
not been much, although the specification does allow for it via 
pre-placed keys, etc and we had an implementation at NRL some number 
of years ago), to leverage the IPSec identifier since IPSec could 
prevent us from adding the options header needed for IPv6 since it 
does not have the "id" field of IPv4...

>   a little bit of embellishment.

The computational complexity of hashing was one aspect (We have our 
SMF implementation running on WinCE platforms and to perform 
forwarding for multicast VoIP or video streaming by itself is taxing 
enough), ...

But another problem in our experience was that hashing sometimes 
mis-identifies a packet as a duplicate of a previous packet (the IP 
checksum would do the same) ...  So unless you cached previously 
received/forwarded packets for additional checking, the hash approach 
caused packets to be incorrectly dropped, sometimes at unacceptably 
high rates (several percent) depending on the nature of the source 
data ... I do think further investigation is merited here, but we 
have demonstrated the sequence-based approach on several platforms

Also the addition of something like an SMF options header (needed for 
IPv6 and perhaps a good idea for IPv4 too) allows the possibility for 
intermediate systems (perhaps gateways to/from MANET areas to 
properly handle the case where packets enter a MANET area, possibly 
exit and have an opportunity to re-enter) to appropriately label 
(since the default sequencing of  the "id" field packets by some 
operating systems may be insufficient) originated from non-SMF aware 
nodes

>   mentioned in the "bcast" draft I updated recently.

These two issues are related and are a result of the "service model" 
we assumed in writing the draft.  Our intent here was treating SMF as 
a simple layer 3 forwarding service.  I agree that protocols (like 
routing protocols) may wish to use the same forwarding methodology 
(whether MPR, E-CDS, etc) that are really need hop-by-hop relay 
messaging across a distributed tree... But, as you indicate, those 
cases will be touching the payload and essentially creating new 
packets hop by hop ... Our current SMF implementation "tag-teams" 
with our routing protocol (i.e., "nrlsmf" gets neighbor & selector 
lists (MPR flooding) or relay status (E-CDS) from the routing 
protocol), but the routing protocol still does its own message 
relaying ... So there is one instance of the "2 hop neighborhood 
discovery and determination of MPR sets (or CDS relay status) shared 
by the routing protocol and the separate layer 3 SMF forwarding 
engine ...

So, perhaps this assumption was too specific?  But I would guess that 
protocols doing hop-by-hop message relaying (like routing control 
messages) would have the luxury of specifying message formats that 
ease the duplicate detection issue (so the "id" field hack or hashing 
could be avoided ... Our philosophy was to keep the hop-by-hop 
routing control messages separate from the general layer 3 forwarding 
capability we are trying to provide via SMF ... There might some neat 
things that can be done with respect to auto configuration, service 
discovery, etc using SMF and TTL scoping, etc ...

I think the algorithm for selecting MPR sets or CDS relay status 
could be separate from the SMF document ? and that could be a common 
"building block" that could be referenced by SMF or other protocols 
as needed?

>  design towards the source-dependent cases.

Yep ... we are still running some simulations to compare the sort of 
"shared tree" that the source-independent CDS algorithm we are using 
creates to the "source trees" that the source dependent MPR algorithm 
of OLSR creates ...  We aren't completely sure how they stack up with 
with respect to "one-to-many" versus "many-to-many" data flow trends 
or the impact with respect to wireless MAC layer issues ... e.g., a 
shared tree has less link diversity but perhaps reduces contention 
issues .... There are alot of subtleties :-)

>  fail to touch the network layer code in a node anyway.

Agreed!  We currently intercept and resequence packets when we can, 
and, as mentioned above, the use of options headers may allow 
gateways to properly format packets for SMF distribution while 
maintaining the ability of non-SMF aware nodes (edge nodes) to 
receive without any additional software ...

-- 
Brian

Brian Adamson
<[email-masked]>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 01 Jul 2005 14:39:00 -0700

Hello Brian,

Here are a few small comments.  It appears that we are
pretty much in agreement.  Have you taken a look at
the draft I recently submitted?  If so, do you think there
is enough commonality to make a merge?

More below...

Brian Adamson wrote:

> data ... I do think further investigation is merited here, but we have 
> demonstrated the sequence-based approach on several platforms

Do you mean sequenced by the IP_id field?

This would be O.K. with me.

For cases when gateways have to encapsulate (because they noticed
that the field did not guarantee uniqueness), that could be done
as needed.  This doesn't mean do it all the time.

For IPv6, a similar approach can be applied.  I have text about
this in the "bcast" draft.

> packets hop by hop ... Our current SMF implementation "tag-teams" with 
> our routing protocol (i.e., "nrlsmf" gets neighbor & selector lists 
> (MPR flooding) or relay status (E-CDS) from the routing protocol), but 
> the routing protocol still does its own message relaying ... So there 
> is one instance of the "2 hop neighborhood discovery and determination 
> of MPR sets (or CDS relay status) shared by the routing protocol and 
> the separate layer 3 SMF forwarding engine ...
>
> could be avoided ... Our philosophy was to keep the hop-by-hop routing 
> control messages separate from the general layer 3 forwarding 

This is where our contribution ought to be.  We might specify how it is
that uniqueness is guaranteed, which can be potentially used to relieve
applications of the need to deal with this issue.

>
> I think the algorithm for selecting MPR sets or CDS relay status could 
> be separate from the SMF document ? and that could be a common 
> "building block" that could be referenced by SMF or other protocols as 
> needed?

Yes, similarly, I am very much in favor of creating the necessary
interfaces to the CDS building block unit, in such a way that DYMO
can make use of it -- and, presumably newgen OLSR.

> issues .... There are alot of subtleties :-)

There sure are!  Thus, the value of a [manet] protocol that allows
future algorithms to be plugged in.  As long as we capture the
data needed by the algorithms, then we can probably do this.
I'm betting on two-hop neighborhoods for the foreseeable
future, which only requires advertisement of one-hop nbhds.

Regards,
Charlie P.

---

From: Brian Adamson <[email-masked]>
Date: Wed, 6 Jul 2005 13:10:47 -0400

>is enough commonality to make a merge?

Can I get a copy of this from you.  I thought I had it, but I can't find it.

>>received/forwarded packets for additional checking, the hash 
>>approach caused packets to be incorrectly dropped, sometimes at 
>>unacceptably high rates (several percent) depending on the nature 
>>of the source data ... I do think further investigation is merited 
>>here, but we have demonstrated the sequence-based approach on 
>>several platforms
>

Yes that's what we mean ... and we have been able to add an options 
header for IPv6 to serve the equivalent purpose.  End systems are 
able to receive the packet with options header without any 
decapsulation required (at least on some systems we have tested)

>>These two issues are related and are a result of the "service 
>>model" we assumed in writing the draft.  Our intent here was 
>>treating SMF as a simple layer 3 forwarding service.  I agree that 
>>protocols (like routing protocols) may wish to use the same 
>>forwarding methodology (whether MPR, E-CDS, etc) that are really 
>>need hop-by-hop relay messaging across a distributed tree... But, 
>>as you indicate, those cases will be touching the payload and 
>>essentially creating new packets hop by hop ... Our current SMF 
>>implementation "tag-teams" with our routing protocol (i.e., 
>>"nrlsmf" gets neighbor & selector lists (MPR flooding) or relay 
>>status (E-CDS) from the routing protocol), but the routing protocol 
>>still does its own message relaying ... So there is one instance of 
>>the "2 hop neighborhood discovery and determination of MPR sets (or 
>>CDS relay status) shared by the routing protocol and the separate 
>>layer 3 SMF forwarding engine ...
>>
>>So, perhaps this assumption was too specific?  But I would guess 
>>that protocols doing hop-by-hop message relaying (like routing 
>>control messages) would have the luxury of specifying message 
>>formats that ease the duplicate detection issue (so the "id" field 
>>hack or hashing could be avoided ... Our philosophy was to keep the 
>>hop-by-hop routing control messages separate from the general layer 
>>3 forwarding capability we are trying to provide via SMF ... There 
>>might some neat things that can be done with respect to auto 
>>configuration, service discovery, etc using SMF and TTL scoping, 
>>etc ...
>
>>could be separate from the SMF document ? and that could be a 
>>common "building block" that could be referenced by SMF or other 
>>protocols as needed?
>

I guess the questions I have with respect to this are:

What is the set of and the relationship of some different "building 
blocks" here?

We _could_ create a stand-alone "n-hop neighborhood discovery 
protocol" and then define "relay set algorithm documents" that can be 
used by routing protocols and SMF (or even for other to be determined 
purposes).  But the specific information that the "neighborhood 
discovery protocol" would need to collect might vary depending upon 
the routing protocol and/or the relay set algorithm (MPR vs. CDS, 
etc).  To me it seems hard to separate these cleanly.

Also, for efficiency it probably makes sense to bundle control 
messages with neighborhood discovery probes, etc to reduce contention 
on wireless (or at least realize the benefits of fewer channel 
accesses) ... And the current path that we are heading down with 
respect to the next generation of MANET protocol specifications seems 
sufficiently far along that we wouldn't want to re-engineer those 
approaches.

This has led us to define the "SMF" service as this sort of 
independent capability that can be controlled by some relay set 
algorithm that gets its metrics from information collected by a 
routing protocol (or neighborhood discovery protocol if the routing 
isn't there or doesn't do that)

This does beg the question of should we define a baseline 
neighborhood discovery protocol (or leveraging other existing 
(citable) protocols?) to support this for the case of a routing 
protocol not doing it?

In any case, the "SMF" module needs to clearly define the information 
it needs to perform properly.  For the E-CDS type of approach (source 
independent) this can somewhat simple, a binary "forward" or "don't 
forward" indication ... For other approaches (e.g., source-specific 
MPRs) more information and details (neighbor lists, selector lists, 
previous hop identification for incoming packets/frames)  are 
required to get proper behavior  ...   How much of these details do 
we put in the SMF document? In its present draft form, we've 
mentioned some of these issues but have not yet provided all of the 
details.

I'm working on clarifying the stuff in the document based on your comments ...

-- 
Brian
__________________________________
Brian Adamson
<mailto:[email-masked]>

---

From: Brian Adamson <[email-masked]>
Date: Wed, 6 Jul 2005 17:34:18 -0400

Attached are TEXT and HTML versions of the Joe's SMF draft updated to 
reflect some of Charlie Perkins comments and to hopefully clarify a 
few things.  There's still more to do, but hey, it's a draft ...

cheers,