Subject: [manet] Comments about draft-ietf-manet-packetbb-04

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 10 May 2007 16:48:09 -0700

Hello folks,

Herewith, some comments on the PacketBB document.
I didn't go through the appendices yet, sigh...

================================================

Somewhere, the document should explain why the "bb".

 >   o  A message header format containing *all* necessary information to
 >      allow a node to make forwarding decisions without inspecting and
 >      processing the message body.  Message header information permits
 >      single- and multi-hop message diffusion.

Should clarify this only affects packets with TTL > 1.
The statement is also incorrect if it is interpreted to mean
that the node's present state cannot be used in the forwarding
decision.

 >   The specification has been explicitly designed with the following
 >   properties in mind:

One of the design goals ought to be compact header size,
in general -- not just for address representations.

 >   Parsing logic  - the regular expression specification facilitates
 >      generic, protocol independent, parsing logic.

If, by putting this first, it is elevated to prime importance,
then I think the design goals have the wrong priority.  It should
be a goal, but considerably less important than efficiency
of representation or actual processing.  Parsing is a smaller
part.

 >           ...           Full backward compatibility can be
 >      maintained.

Backward compatibility to what?

 >   Packet  - the top level entity in this specification.  Packets are
 >      transmitted over a single logical hop and are not forwarded.  A
 >      packet contains zero or more messages, and may contain a packet
 >      header.

When do we need to transmit a packet with zero messages?

 >   Address  - an address of the same length as the source IP address in
 >      the IP datagram carrying the packet.

I don't see the point of making the definition this way.
People reading the spec are likely to have encountered
IP addresses before, and would be familiar with the concept
of a network-layer address.  Plus, I can imagine mixed-mode
systems where IPv6 and IPv4 nodes share routing responsibilities,
even though we are not designing those systems today.

 >   The specification is designed specifically with IP (IPv4/IPv6) in
 >   mind.  All addresses within a control message are assumed to be of
 >   the same size, deduced from IP.  In the case of mixed IPv6 and IPv4
 >   addresses, IPv4 addresses are carried in IPv6 as specified in [2].

The first sentence I like.  The second restriction is chancy, as
I just mentioned.  The third restriction could lead to ambiguities,
I think...

 >   ........        transport mechanism (unicast, multicast)

I never heard these called "transport mechanisms" before.
Aren't they really different modes of network addressability?

 >         ..........     it will employ.

What is "it"?  The "protocol"?  Does it mean that the
document specifies features that may be prohibited for
use by some protocols designed according to the specification?

Just checking!

 >       <packet> = {<packet-header><pad-octet>*}?
 >                  {<message><pad-octet>*}*
 >
 >   where <message> is defined in Section 5.2, and <pad-octet> is defined
 >   in Section 5.4.  The packet is parsed until all octets are used.

The last sentence imposes an unnecessary restriction.
Some packets should be dropped before parsing is complete.
And, what if the packet is unparseable?

 >      bit 0 (pnoseqnum):  if cleared ('0'), then the packet header
 >         contains a <packet-seq-number>.  If set ('1'), then the packet
 >         header does not include a <packet-seq-number>.
 >
 >      bit 1 (ptlv):  if cleared ('0'), then the packet header does not
 >         include a TLV block.  If set ('1'), then the packet header
 >         includes a TLV block.

It is curious, and less than desireable, that the senses
of these two flags are inverted relative to each other.
However, it is not incorrect -- except insofar as it makes
people more likely to make mistakes from strained memory.

 >   <msg-type>  is an 8 bit field, specifying the type of message.  A
 >      type with all bits cleared ('0') MUST NOT be used.

You can just say that type 0 (zero) is RESERVED.

 >   <msg-size>  is a 16 bit field, specifying the size of the <message>,
 >      counted in octets.

This would be a possible use of another bit in the msg-semantics
field, which would say whether or not the msg-size were 8 or 16 bits.
It is to be hoped that most kinds packetbb messages would be usually
be less than 256 bytes long, so it would be nice if the specification
supported that case.

 >   <hop-limit>  is an 8 bit field, which contains the maximum number of
 >      logical hops a message should be further transmitted.
 >
 >   <hop-count>  is an 8 bit field, which contains the number of logical
 >      hops a message has traveled.

I can well imagine protocol messages which would not need
both of these fields.

 >   <address block> is defined by:
 >
 >       <address-block> = <num-addr>
 >                         <addr-semantics>
 >                         <head-length>?
 >                         <head>?
 >                         <tail-length>?
 >                         <tail>?
 >                         <mid>*

This construction assumes that most address information
will be transmitted in blocks of aggregated addresses.
As we have discussed many times in the past, the value
of the given scheme is questionable if most addresses
are really singletons from an effectively flat address
space.  This is the case for the overwhelming majority
of times in my experience.

One way around this would be to have two kinds of
<address block>s: one, as given above, and another
trivial one just consisting of the unadorned and
unpartitioned address.

I thought about developing a simple expression for
the overhead, depending on the expected number of
addresses that can be aggregated, but it is really
just an exercise.  However, for the case of unaggregated
IPv4 addresses, the overhead from the address block
mechanism as given, is 50%.  That can make a difference.
In many cases, the number of addresses in the message
(disregarding extensions) is fixed by the message
type, enabling a very compact representation overall.

How about if we put another bit into the <msg-semantics>
which would enable the simple <address block> variant?

Aside from this case which is the majority case in
my experience, I think the given format seems to
work well for addresses that can be aggregated.
However, it is to be noted that, for instance, AODV
handles address aggregation by another mechanism
entirely.

 >   mid-length  is a variable, which MUST be non-negative, defined by:

Is there some field here which is signed?
What does this mean?

 >   <tlv-length>  is a 16 bit field

I hope most <tlv>s will be shorter than 256 bytes, so this
could be considered overkill.  I am constantly reminded
that our results show over and over again that extra
bytes really correlate well with reduced protocol
performance, so I look for ways to make savings especially
in crucial systemic protocol elements such as this.
If there is a <tlv> where the fields add up to more
than 256 (wow!) wouldn't it be better to just define
a "continuation" <tlv> for that case?

Or, did I misinterpret, and <tlv-length> is intended
to include the length of <value>?

In that case, my comments still apply, but I would
prefer having a way to determine whether or not the
<tlv> was of the long or the short variety, perhaps
based on the type.

 >   Two or more TLVs of the same type associated with the same address
 >   block MUST NOT both cover any address.

I do not understand the reasoning behind this constraint.
What if TLVs specify link characteristics, and we want
to know more than one characteristic about some links
(i.e., some pairs of addresses)?

 >   Packet headers and messages can be padded to ensure 32 bit alignment

   Packet headers and messages MAY be padded to ensure 32 bit alignment

 >   Message type 0 MUST NOT be allocated because a zero-octet signifies a
 >   packet header and zero-octets are used for padding.  Message types 1
 >   to 4 are reserved because they are used by OLSR [4], which uses a
 >   compatible packet/message header format.

I don't think IANA cares what type 0 signifies.  Why not just
make it RESERVED?

It would be better to put into the OLSR document a part
of the IANA considerations to reserve the four message
types, and delete the discussion in the PacketBB document.

Why isn't Table 7 close to the paragraph about address blocks?

 >8.  Security Considerations
 >
 >   Messages are designed to be carriers of protocol information and MAY,

I don't think MAY is supposed to be used this way.

 >                     ...............                   Since <hop-
 >   count> and <hop-limit> are the only fields that may be modified when
 >   such a message is forwarded, this signature can be calculated based

Really?  What about current estimates of cost, stability, delay, ...?

Or, is this discussion only valid
    "If forwarded messages are unchanged by this protocol," ?

Furthermore, I reckon "end-to-end security MAY be implemented"
in many ways.  Again, this seems to be a wrong use of "MAY".
Also, "Hop-by-hop packet level security MAY be implemented"
could, presumably, be implemented using IPsec.  Or am I missing
something...?

================================================

Regards,
Charlie P.

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

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 15 May 2007 14:46:06 +0530

PacketBB authors,

A lot of Charlie's comments appear to be minor. I assume you'll
happily integrate them.

Regarding the "larger" changes Charlie has suggested, can you please
breakout the various items into separate threads? Then we can tackle
them one-by-one.

Ian