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

From: Thomas Clausen <[email-masked]>
Date: Thu, 14 Jun 2007 18:53:12 +0200

Dear Charlie, all

First of all, thank you for your careful review and for your  
comments. See below.

On 11May , 2007, at 1:48 AM, Charles E. Perkins wrote:

>
> 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".
>

You'll see that "bb" only appears in draft-ietf-manet-packetbb  and  
not elsewhere. When draft-ietf-manet-packetbb is replaced by RFCXXXX,  
then any mention of packetbb disappears automatically ;) Let's push  
for quickly getting to RFCXXX ... :D

> >   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.
>

I think I see what you mean here.

Let me first clarify that a packetbb packet may well be sent with IP- 
TTL=1, yet contain messages that are to be forwarded (i.e. with a  
message hop-limit>1). Your point is well taken that the text needs to  
be permissive (i.e. allow a node to not forward a packet based on  
present state or other criteria).

We will clarify this in the I-D.

> >   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.

These goals are actually listed in no particular order.

I will clarify this in the I-D.

> It should
> be a goal, but considerably less important than efficiency
> of representation or actual processing.  Parsing is a smaller
> part.

I respect your opinion on this matter, as you know, and I will not  
dispute it. An equally correct opinion has been voiced by other  
parties (at least during IETF meetings, if not on the list) that  
parsing simplicity is a prime goal, and that the algorithmic  
complexity of processing a packet/message should be minimized.

I am not taking a position (not in this email, at least) as to which  
goal is more important -- just pointing out that packetbb is designed  
in a space with many interested parties, and that requirements are,  
occasionally, seen with different importance by different parties.

> >           ...           Full backward compatibility can be
> >      maintained.
>
> Backward compatibility to what?
>

Good point, that can be somewhat obscure!

The idea is, that if you write DYMO code that is conformant with the  
DYMO specification and then -- later -- I want to add an additional  
bit of information (say, if a link tastes like strawberries or  
coffee), then I can add a "taste-TLV", which will not break your  
parsing of DYMO messages.

Yes, I chose an absurd example here, since I'd not want to discuss  
the merits of a specific protocol extension, but just point out the  
general idea.

I will clarify this in the I-D.

> >   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?

Assuming that you want to send just a packet TLV with, say, a packet  
sequence number to a neighbor node (a sort of "keep-alive-message"),  
then you'd want to do that without having to construct a message with  
a message header that you would not use.

Again, you have a good point in that this should (and will) be  
clarified in the I-D.

<SNIP - about IPv4/IPv6 addresses>

Will update reference & text to RFC4291 in next version of I-D.

> >         ..........     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!

It's more benign than that. For example, OLSRv2 will state "All  
OLSRv2 messages use full message headers" (seq. no, ttl, hopcount,  
org-addr).

> >       <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?
>

Good point, will update I-D text.

>
> >   <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.
>

My reading of RESERVED is "RESERVED for future use" -- which is not  
the case here. It might be that I am wrong in my reading of RESERVED,  
however since this field MUST ABSOLUTELY NEVER be all-zeros, I prefer  
to write the specification to people as dumb as myself (there might  
be one or two out there) and be very explicit on this.

> >   <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.

This is a balance on if saving one octet compensates for (i) slightly  
more complex parsing logic and (i) using a flag out of the limited  
number that we have available. I am inclined to, for the next version  
of the I-D, to keep it as it is, and then solicit more input on this  
from the list and in a seperate thread.

I hope that you're OK with this, knowing that your comment is not  
forgotten and will be discussed shortly?

> >   <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.

Upon reflecting on this for a while, I think that you are right.

Will be updated in next version of the I-D.

<SNIP>

> 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 will address this somewhat in another email, but just disagree in  
principle here: most ad hoc networks I have seen deployed, both for  
testing and otherwise, have had addresses assigned out of a common  
prefix, which lends itself to aggregation.

In my opinion, having yet-another-way of representing addresses will  
add complexity to the specification (and to implementations of the  
specification). Even in the case of un-aggregatable addresses, one  
could collect these into one address block. So, the case that you  
present, and which I think is not particularly common, is fully  
supported.

> 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%.

No, that would assume that you had one address-block per address,  
which would be inefficient. You could have simply one address block  
with no common head/tail and only mids (which would then be of the  
length of the address type). So you'd incur a fixed overhead  
regardless of how many addresses you add to that one address block.

> >   <tlv-length>  is a 16 bit field
>
> I hope most <tlv>s will be shorter than 256 bytes, so this
>

Ahm, ok, it's not the length of each tlv, but of the tlv-block.

I will clarify this in the I-D.

>  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.

This is probably dependent on what you have below your L3. My studies  
and results show, that on common L2's, sending a few extra octets  
does not a big change make, but making an extra transmission does. I  
am not sure that there are universal truths either way, though -- but  
it's an interesting (albeit not IETF-related) area to study.

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

Bingo, you're right, I'll update the I-D.

> >   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?
>

See discussion above. I am assuming that there might be one or two  
individuals out there as dumb as I ;) (Feel free to disagree with me,  
though ;) )

> 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.
>

Actually, these four types are those which are used in RFC3626, and  
since I can't update RFC3626 I think that this is the right place to  
put it.

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

Ok, I will look at if the tables in this section are close to the  
related text -- might be they are, or might be that I have moved text  
around without the associated tables in the course of editing.

> >8.  Security Considerations
>
> >                     ...............                   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," ?
>

Yes. What I mean to say is that "If the message content is immutable,  
only hop-count and hop-limit are changing and in that case one can...."

I will clarify this in the I-D.

<SNIP>

Thanks again for your review and your comments. We'll issue an  
updated version of the I-D shortly, updated as indicated above and  
resuming discussion on the issues also indicated above in a seperate/ 
new thread.

Looking forward to seeing you again in Chicago!

Thomas

-- 
Thomas Clausen
[email-masked]
http://www.thomasclausen.org

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

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 14 Jun 2007 18:53:12 +0200

Dear Charlie, all

<SNIP>

<SNIP>

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 15 Jun 2007 10:23:28 -0700

Hello Thomas,

> complexity of processing a packet/message should be minimized.

 Packet size matters a lot more for wireless devices than
for classical IETF devices.  It seems to me that one aspect
of the evolving IETF engineering discipline has been to
emphasize simplicity at the expense of packet size.  Thus,
I am not at all surprised that a large IETF constituency would
carry this design philosophy over into [manet].

But if there are going to be billions of power-constrained
devices, the design space changes.  If you elevate simplicity
to primary importance, then I think you should put a
sentence into an Applicability Section that says something
like:
    "This protocol is not intended for power-constrained devices"
I think it would be more accurate.

Otherwise, I think you should be willing to consider some
small suggestions for power savings.

> to write the specification to people as dumb as myself (there might be 
> one or two out there) and be very explicit on this

My feeling is that such restrictions belong in the IANA
considerations.

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

 I guess it means that I have to be on my toes to not miss the
discussion.  I've missed a lot of them over the last year, and
I still have to review NHDP, sigh...

> prefix, which lends itself to aggregation.

 Well, that is perfectly understandable.

> present, and which I think is not particularly common, is fully supported.

 I didn't say it was unsupported.  I meant to say it was extra
baggage when I want to be traveling light.

> which would be inefficient.
 It darned sure is.

> You could have simply one address block with no common head/tail and 
> only mids (which would then be of the length of the address type). So 
> you'd incur a fixed overhead regardless of how many addresses you add 
> to that one address block.

 But then you have to mangle the semantics of your message type
to induce substructure on the address block.  If you will make
the statement in your draft that address blocks are encouraged
to have substructure in order to satisfy any required semantics
depending on message type, then we'll be done :-).

> and results show, that on common L2's, sending a few extra octets does 
> not a big change make, but making an extra transmission does. I am not 
> sure that there are universal truths either way, though -- but it's an 
> interesting (albeit not IETF-related) area to study.

 I agree that extra messages are a lot worse than
extra octets in the message.

But, a few pounds on holidays, a few pounds at the
company picnic, a few pounds on vacation,
and pretty soon you are fat.

>> >   packet header and zero-octets are used for padding.  Message types 1
 You already know I don't think you are dumb at all.

> since I can't update RFC3626 I think that this is the right place to 

 I definitely do not think that there should be any
normative dependency on OLSR.  Since OLSRv2
will be published before any other document that
might conflict with the allocations of message types,
there would be no problem because OLSRv2 can
insure compatibility.  Certainly we can guarantee that
DYMO won't cause problems here...

Regards,
Charlie P.

---

From: "Krishna Sankar \(ksankar\)" <[email-masked]>
Date: Fri, 15 Jun 2007 19:48:14 -0700

Supporting Charles' POV, from my (very limited) experience in the sensor
world, one reason packet size matters is because trx & rcv takes most of
the power. I assume it is similar in the Wi-Fi and WiMax world.
Moreover, in many cases the trx-rcv function is done while the system is
in sleep mode (e.g. OLPC). Especially in the case of MANET, the packets
go thru multiple devices, thus making small packet size more efficient
(resource-wise) across the network. 

In short, while the algorithmic complexity of processing a
packet/message will only be incurred by one node, packet size will
affect multiple nodes. Assuming packet routing only requires minimal
classification and of course, the routing complexities which would
relatively be independent of packet size, both of which I think are fair
assumptions. 

But I do want to point out the difference between complexity of packet
_processing_ vs. complexity of packet _classification_ for routing. For
example if we make the packet classification more complex (say by
compression et al) then we do not gain much in terms of
resource-efficiency. 

Cheers
<k/>

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Friday, June 15, 2007 10:23 AM
> To: ext Thomas Clausen
> Cc: Manet
> Subject: [manet] Re: Comments about draft-ietf-manet-packetbb-04
> 
> 
> Hello Thomas,
> 
> >> be a goal, but considerably less important than efficiency of 
> >> representation or actual processing.  Parsing is a smaller part.
> >
>  Packet size matters a lot more for wireless devices than for 
> classical IETF devices.  It seems to me that one aspect of 
> the evolving IETF engineering discipline has been to 
> emphasize simplicity at the expense of packet size.  Thus, I 
> am not at all surprised that a large IETF constituency would 
> to primary importance, then I think you should put a sentence 
> into an Applicability Section that says something
> like:
>  I guess it means that I have to be on my toes to not miss 
> the discussion.  I've missed a lot of them over the last 
> year, and I still have to review NHDP, sigh...
> 
> >
> >
> >> 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 didn't say it was unsupported.  I meant to say it was 
> extra baggage when I want to be traveling light.
> 
> >
> >
> >> 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%.
> >
>  But then you have to mangle the semantics of your message 
> type to induce substructure on the address block.  If you 
> will make the statement in your draft that address blocks are 
> encouraged to have substructure in order to satisfy any 
> required semantics depending on message type, then we'll be done :-).
> 
> >
> >
> >>  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.
> >
>  I agree that extra messages are a lot worse than extra 
> octets in the message.
> 
> But, a few pounds on holidays, a few pounds at the company 
> picnic, a few pounds on vacation, and pretty soon you are fat.
> 
> >
> >
> >
> >> 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.
> >>
> >
>  I definitely do not think that there should be any normative 
> dependency on OLSR.  Since OLSRv2 will be published before 
> any other document that might conflict with the allocations 
> of message types, there would be no problem because OLSRv2 
> can insure compatibility.  Certainly we can guarantee that