Subject: [manet] Comments on PacketBB Draft

From: "Joseph Kopena" <[email-masked]>
Date: Tue, 11 Sep 2007 12:28:08 -0400

Hi all,

The following are a few comments on Packet BB.  These are from draft
8, but looking at a diff against version 9, none of these comments
were effected by the changes.

I preface by saying that I have read much of the ongoing discussions
on ordering & bit saving but have not necessarily seen all of the
arguments.

Thx

-------
[ Content ]

These comments all refer to page 16, Constraints.

It's not clear what the value is in some of the constraints given
here, at least just from reading this document.

The only value I can see from the ordering constraint is that a
receiver can easily pull all the TLVs into an array and provide
efficient random access to it.  But for a hash or other map
implementation, that doesn't matter.  You also still need to sort on
the sending end, as well as check on the receiving end.

Relying on the numeric values of the TLVs sounds like something that
will be regretted sooner or later.  It attaches too much meaning to a
number that should just be a unique identifier.  It seems reasonable
that some protocols will want to impose an ordering over their
elements, but that should be up to the protocol and doesn't require
this to do so.

Specifically allowing child protocols to allow or disallow duplicate
TLVs is a good thing.

I don't see the value in requiring a given TLV type to be associated
with an address exactly once.  For possible implementations that I'm
thinking of, it sounds like (slightly) more of a hassle to check that
if it's already been associated than to just go ahead and mark the
address.  Ditto requiring redundant TLVs to be index sorted.

My personal plan for a PacketBB API provides more of a declarative or
relational view than I think these constraints imply.  I'm thinking of
the main access mechanisms as being a query for all TLVs associated
with an address, for all addresses associated with a TLV, or direct
access access to the received packet structure (i.e.  to loop over
each message, address blocks in a message, etc).  None of these
requires the constraints imposed here, and they sound like more of a
hindrance because now care has to be chosen in picking identifiers,
data has to be asserted in order or sorted, etc.

[ Typographical Notes ]

pg 15: "For an address block... block, where the first address has
position zero." should perhaps be clarified a bit: "For an address
block... block, where the first address in the block is position
zero."
-------

-- 
- joe kopena
  shelter from the storm

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

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 11 Sep 2007 17:32:36 +0100

Please see previous discussion in this group in
which the value of these constraints has been
summarised extensively.

-----Original Message-----
From: Joseph Kopena [mailto:[email-masked]] 
Sent: 11 September 2007 17:28
To: [email-masked]
Subject: [manet] Comments on PacketBB Draft

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Hi all,

Thx

-------
[ Content ]

[ Typographical Notes ]

-- 
- joe kopena
  shelter from the storm

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Joseph Kopena" <[email-masked]>
Date: Tue, 11 Sep 2007 12:36:07 -0400

> which the value of these constraints has been

Yes, as noted, I am aware of those discussions.  As far as I could
tell from reading through the recent archives, there does not seem to
have been a conclusive, concensus decision on whether or not there
actually is value to those constraints.  It seems like the discussion
has just stalled out of late, rather than there being a clear
decision.  Therefore, it would seem like there is some value in input
from the remainder of the group/list, especially those not entrenched
on either side of the debate.  I apologize if that's not the case.

Thx

-- 
- joe kopena
  stay on target

---

From: "Joseph Kopena" <[email-masked]>
Date: Tue, 11 Sep 2007 12:40:02 -0400

> actually is value to those constraints.  It seems like the discussion

As a side note I forgot in the comments: If the group has/does decide
that these constraints do make sense, then there should be more
elaboration on their justification than what is currently present; a
concise form of the arguments given on this list should be mentioned
in the spec.  Otherwise the issue will just keep coming up again &
again and/or be ignored by implementations.

Thx

-- 
- joe kopena
  stay on target

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 11 Sep 2007 12:08:57 -0700

Hello Chris,

I have submitted comments that, I thought, conclusively
demonstrated the harm in specifying the constraints as
they currently exist in packetBB.  As I remember, and
I _did_ go back and check, the only people defending
the constraints are the authors of the specification...
...unless one counts an explanatory note by Ian,
which I counted as neutral.

I reiterate that I think the constraints are harmful, and
especially because they condemn future protocol
designers to treat performance improvements as
error conditions.

There is no reason to have these constraints a priori.
I don't even think they are required for OLSR,
much less for protocols that have nonscalar data objects.

Please remove sections 5.3.2.  Once that is done,
section 5.3.3 starts to lose applicability -- but you may
wish to identify other ways in which packets could be
"malformed".

Regards,
Charlie P.

---

From: "Justin Dean" <[email-masked]>
Date: Tue, 11 Sep 2007 17:07:54 -0400

I would like to re-address the ordering constraint in this email.  

A few things said in today's emails.

> The only value I can see from the ordering constraint is that 
> a receiver can easily pull all the TLVs into an array and 
> provide efficient random access to it.  But for a hash or 
> other map implementation, that doesn't matter.  You also 
> still need to sort on the sending end, as well as check on 
> the receiving end.

And 

> especially because they condemn future protocol designers 
> to treat performance improvements as error conditions.

Now with regards to the ordering constraint it only refers to the packet
being sent out.  It does in no way say anything about the processing end of
things.  One may process the packet however they wish in whatever order
makes the most sense.  A drawback as Joseph mentioned is that it sorting
needs to take place on the sending end.  Checking ordering on the receiving
end is trivial.  Processing the TLVs out of order, on in-order tlvs,
defaults to processing any tlv block which has no order, everything has to
read in then processed.  I really don't see what having no ordering gains,
other than possibly faster packet building.  Ordering even when not the
"correct" order for processing should still provide improvement on the
processing end of things.  There should be more receivers than senders.  

> Relying on the numeric values of the TLVs sounds like 
> something that will be regretted sooner or later.  It 
> attaches too much meaning to a number that should just be a 
> unique identifier.  It seems reasonable that some protocols 
> will want to impose an ordering over their elements, but that 
> should be up to the protocol and doesn't require this to do so.

I would like to reiterate that ordering of tlvs within a tlv block says
nothing about how protocols/implementations MUST or SHOULD processes the
tlvs, nor should it.  If there is an ordering, it CAN be taken advantage of.
Protocols can process the tlvs in any order they wish no matter the order
within the packet.  The ordering may not be perfect for every protocol but
it will be at least known to all.  

Justin

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 09:23:42 +0100

> designers to treat performance improvements as

And I reiterate that there are sound reasons for them,
and no use case beyond vague "we might want this some
day" for removing them.

> section 5.3.3 starts to lose applicability

Putting aside our disagreement on 5.3.2 - which was
not removed in -09, and not by accident, 5.3.3
explicitly points out that it covers more than 5.3.2.
For example you may have invalid semantics octets,
or a message that says it's longer than the number
of octets left, or an address prefix length that is
longer than an address, or many other ways that a
packet can be malformed.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 09:28:47 +0100

> A drawback as Joseph mentioned is that it sorting
> needs to take place on the sending end. 

Insertion is more relevant, as you create a TLV, insert
it in the right place.

(Of course you could view this as an insertion sort. But
with the small number of TLVs you expect, that's not a
bad method either.)

I agree with all of Justin's other points.

---

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Wed, 12 Sep 2007 10:46:22 -0400

>From: Dearlove, Christopher (UK) 
>[mailto:[email-masked]] 
>Sent: Wednesday, September 12, 2007 4:29 AM
>To: Justin Dean; [email-masked]
>Subject: RE: [manet] Comments on PacketBB Draft
>
>

Which is easy given today's list of  TLV's, and the reasons
you'd want to add them. However, it doesn't provide for 
easy expansion (future development), IMO. 

>with the small number of TLVs you expect, that's not a

But the performance impact and code complexity of a sort on 
the sending side will far outweigh any performance impact
on the receiving side -- there were earlier emails on this thread
pointing out that the additional processing on the receive side
is trivial. 

Regards,
Stan

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 12 Sep 2007 15:55:39 +0100

> easy expansion (future development), IMO.

Yes, it does, trivially, numerically, as specified.

> on the receiving side

This is not so. Having implemented such code (have you?) I
can tell you this is not the case. The complexity on the
receiving side - to ensure that TLVs are uniquely specified,
and not ambiguous, is significantly greater. This is particularly
as if you implement as sub-optimal "first matching TLV" approach
because of that a TLV covers multiple indices, you end up using
parts of some TLVs, while other parts of the same TLV are over-
ridden by earlier matching TLVs. And if you want to ensure
logical correctness it's even worse.

> there were earlier emails on this thread

And they were wrong.

---

From: "Joseph Kopena" <[email-masked]>
Date: Wed, 12 Sep 2007 11:24:02 -0400

> processing end of things.  There should be more receivers than senders.

More comments:

I'm not hugely concerned about the processing required in sorting,
given an expected small number of elements.  I'm more concerned about:

- Having to implement something (the sort) which is not clearly
gaining me anything.  Granted, it'll take only a couple minutes to
implement that constraint, but I don't see the value.

- Having to take care in choosing TLV identifiers if I do care about
ordering in my protocol.

- Managing the TLV identifier space so that there is always room to
insert elements.

Long story short, I believe most users won't care about the order, and
will instead use some random access query interface to fetch the
information.

However, it doesn't seem unreasonable to me to mandate that an
implementation must provide a mechanism to construct packet in a given
structure (order), preserve that structure on transmit, and provide a
mechanism to fetch the received structure or process it in order (e.g.
for a "parse delay" TLV as discussed earlier).

This allows protocols using PacketBB to specify a (partial, i.e. to be
mixed w/ extensions or protocols) ordering over the data if it cares
to do so, while unburdening the implementation from necessarily
sorting the elements and removing the administrative hassle of having
to very carefully choose identifiers.

This does perhaps make it non-trivial to check for unique identifiers,
though I don't think it's difficult.  That's also a false premise from
which to argue for ordering, as the ongoing argument about the
entirety of section 5.3.2 implies it's not clear there's value in that
constraint either.

Thx

-- 
- joe kopena
  right here and now

---

From: "Joseph Kopena" <[email-masked]>
Date: Wed, 12 Sep 2007 11:24:02 -0400

More comments:

Thx

-- 
- joe kopena
  right here and now

---

From: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Wed, 12 Sep 2007 11:33:24 -0400

>Sent: Wednesday, September 12, 2007 10:56 AM
>To: Stan Ratliff (sratliff); Justin Dean; [email-masked]

Yes, I've implemented such code on many occasions. I'm speaking
from practice, not from theory. Sort/move ordering code is much 
more of a performance impact.

>> pointing out that the additional processing on the receive side
No, they weren't. And here we go again...sigh...

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 12 Sep 2007 11:01:48 -0700

Hello Chris,

> and no use case beyond vague "we might want this some

 I was much more concrete than that.  In fact, I would like
to have some elements of SMURF incorporated into NHDP,
and the ordering constraints of packetBB work against that.
You may disagree about whether the SMURF features are
better or worse than NHDP, but it remains a good example
about why the ordering constraints are harmful -- insofar as
they tend to exclude reasonable designs from consideration.

> not removed in -09, and not by accident,
 
 :-(  Perhaps you meant "... but left in by mistake" ...

> 5.3.3 explicitly points out that it covers more than
> 5.3.2.  For example you may have invalid semantics octets,

 There are many ways that fields can be invalid.  I think it
is better to leave this sort of specification to the individual
protocol documents.  Even packets with wrong length fields
can be made useful for some protocols (e.g., UDP-lite).

By the way,  "syntatical" is a mispelled werd.

Regards,
Charlie P.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 13 Sep 2007 10:03:14 +0100

> can be made useful for some protocols (e.g., UDP-lite).

And that is why that is exactly what the specification does,
it leaves it up to the protocol. It just makes it explicit.
In other words it does exactly what you're asking for. The
only thing it disallows is a protocol ignoring the issue.
This section was added by request from (as I recall) two
people, and it's a good idea.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 13 Sep 2007 08:01:55 -0700

Hello Chris,

> people, and it's a good idea.

 O.K.  This way of understanding the section sounds right to me.  Perhaps
if I read it again I can find wording to emphasize this interpretation.

Regards,
Charlie P.