Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness.

From: "Justin Dean" <[email-masked]>
Date: Thu, 1 Nov 2007 12:14:27 -0400

I would like to address one point of Charles' message with regards to mutual
exclusivity in TLVs as I think it's one of the major differences in
perception design between some and the packetbb authors.  I like to look at
TLVs as containers for variables which are then used by the protocol being
designed.  Variables inherently do not have more than one value.  A variable
could be a list of values in which case multiple TLVs or an explicit TLV
designed to carry multiple values for the whole range of values fits nicely.
Could some gains (I would argue very minor ones) be had by allowing multiple
values of the same TLV to be included in a packetbb format?  Yes, but again
very minor.  By forcing exclusivity it forces the protocol designer to
clearly and explicitly design their TLV types and spaces so as not to be
ambiguous.  I feel this is very important.

What I really have a hard time with myself is I haven't seen a compelling
example of something you couldn't do with the current TLV structure
including the restrictions.  There have been some examples, which have been
discussed on this list, which were slightly smaller in size in some cases
but which were much less clear in the content which was being conveyed.  I
am not saying saving bytes is not a worthwhile goal but with the current
setup there are already multiple ways to encode data and which is most
efficient depends on the data being encoded.

In the end it may just be that packetbb will never be as efficient as some
might wish it to be, a cost incurred by the added flexibility, and
extensibility.  That being said the testing I've seen done with OLSRv2 shows
packets which are smaller on average than OLSR for most networks.

Justin

Ps. Charlie I would be more than willing to go over, off list for now, any
specific examples you may have with regards to an encoding which seems to
need the no more than one TLV type per address restriction needed.

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Wednesday, October 31, 2007 12:15 PM
> To: ext Dearlove, Christopher (UK)
> Cc: Manet
> Subject: Re: [manet] Regarding packetbb constraints on 
> ordering and uniqueness.
> 
> 
> Hello Chris,
> 
> ext Dearlove, Christopher (UK) wrote:
> >
> >> I do think the solution as currently
> >> specified is a layer violation and relatively difficult to 
> put into 
> >> practice.
> >>     
> >
> > We do it in OLSRv1. It works, lots of people use it. 
> OLSRv2, and hence 
> > since we spun it out, packetbb, is using already proven technology. 
> > This is self-evidently therefore not difficult to put into practice.
> >   
> The issue is whether or not one has protocol packets of 
> dissimilar varieties to collect together into the bundle.  
> This is a matter of timing, or perhaps delaying some messages.
> 
> It is not a comment on the ability to write the code taking 
> the packets as input parameters.  I would be curious to read 
> about performance studies using realistic data traces, 
> comparing the bundling vs. non-bundling approach during 
> "normal" web traffic.  I note that the IPv6 working group 
> already rejected such an approach.  Perhaps you claim to know 
> better somehow.
> 
> I feel that your responses are, more than almost anyone 
> else's, quite dismissive of concerns that have been raised.
> > As for the rest of your points, I'm not going to go through it all 
> > again.
>  I do not find this surprising.  It takes a long time.  It 
> took me a long time to compose the message.  It would take 
> you a long time to present any realistic and engaging 
> response.  You have to decide whether it is worth the effort.
> 
> >  It has been pointed out many times how ordering permits 
> one-pass easy 
> > verification of non-duplication.
> >   
>  It has been pointed out many times that this feature is not 
> universally applicable, most likely not economical, and 
> certainly not inspired by current IETF practice.
> 
> Regards,
> Charlie P.
> 
> 
> 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/manet
> 

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 01 Nov 2007 12:15:49 -0700

Hello Justin,

I agree with you that the current TLV model in packetbb
is modeled after single-value variable assignment.

But there are ways to associate "valu-able" information
to addresses that do not fit this intuitive model so closely.
If some address is to be associated with multiple values
of type T, then the the current model needs to have some
tricks applied.  If addresses 10-20 need to be associated
with three values of type T, and addresses [15,25]
need to be associated with two more values of type T,
then we have a definite problem.

Perhaps, in my mind, the most amazing thing about
this discussion is just that it is so unnecessary.  The
type ordering and specific algorithms for sorting really
need to be on a per-protocol basis.  That would solve the
whole problem in my mind, and the only issue raised
against that has to do with an internal parser optimization
that is wholly outside the realm of typical protocol
discussions. 

In my mind, this is not about whether packetbb is
efficient, or about trying to save some more bytes.  It is
about placing unneeded constraints on associating
valu-able information to addresses.

Regarding:

> but which were much less clear in the content which was being conveyed.

If this is about SMURF, then:
(a) I showed a MAJOR decrease in packet size.  I'd have to go back and
       check, but I think that the packetbb formats would have _doubled_
       the packet size requirement.
(b) More to the point, the restrictions would nearly prohibit other works
       such as I have done, and the restrictions are supposed to be for ALL
       future protocols, not just the ones we can envision today.
(c) The protocol itself works great, so I am sorry for another reason that
       you do not find my examples compelling.

For myself, I think that the arguments _for_ the ordering restrictions are
_drastically_ less compelling, compared to arguments about packet
bloat and unnecessary restriction (and non-IETF-ness).  By the latter,
I am referring to the dearth of any examples in other working
groups where such ordering restrictions based on numeric type
have been imposed.  And that is for _any_ protocol, much less for an
entire class of all future protocols (!)  (I mean _really_!!!).  Nobody
yet explained either why manet protocols are so special to need this,
or why it is better to sort on the sending side for easier checking on the
receiving side, versus sorting and checking both on the receiving side.
That exposes the proper manner for protocol specification, in that the
type checking is done according to the needs of the type, not the
existing sort-by-fiat arrangement in the parser.

I have raised many other points and variations on these points.
I appreciate that you have taken the time to start to respond, and
hope we can go forward.

Regards,
Charlie P.

---

From: Russ White <[email-masked]>
Date: Fri, 02 Nov 2007 09:55:52 -0400

> that is wholly outside the realm of typical protocol

Agreed--putting in the packet ordering as something all protocols using
packetbb MUST use is unnecessary--it should be an optional, per
protocol/user thing.

:-)

Russ

---

From: "Joseph Kopena" <[email-masked]>
Date: Fri, 2 Nov 2007 17:09:43 -0400

> efficient depends on the data being encoded.

Hi Justin,

As I mentioned previously, I'm curious about the consensus encoding
for a graph or two-hop neighborhood that preserves fulltype
uniqueness.  This may have been covered in previous examples but I
haven't seen it.  If so, I apologize.  All I'm coming up with is
either cramming multiple values into a single value or using multiple
address or message blocks, so I'm curious how to represent this
information in PacketBB succinctly.

Thx!

-- 
- joe kopena
  shelter from the storm