Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC

From: "Justin Dean" <[email-masked]>
Date: Thu, 8 Nov 2007 12:07:58 -0500

Comments inline

> -----Original Message-----
> From: Russ White [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2007 6:57 PM
> To: Justin Dean
> Cc: 'Manet'
> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > I would again like to reiterate that I honestly think there
> is A LOT
> > of confusion on what the restrictions actually restrict. I
> would like
> > to ask for solid examples of protocol behaviors which
> people feel are
> > not possible using the packetbb format.  I feel a few good
> examples of
> > what can be done with the current format, will go a long way in 
> > illustrating what the TLV restrictions are actually doing
> and what they are not doing.
> > 
> > The restriction of TLV order only restricts
> encoding/decoding and not
> > protocol processing which can happen in any order.
> 
> 1. You cannot hold items in a structure, and encode them in the 
> structure order. You must always maintain your internal structure in 
> the same order as the information in the packet is allowed to appear.
> 
Well yes and no but I think this comment comes at the heart of what might be
confusing.  You can't hold items in an arbitrary structure order and encode
them in that order directly.  I agree with that.  But to say that you must
maintain the internal structure order in the same order in which packets
will be encoding seems wrong to me.  Its quite easy to encoded in any random
order regardless of the structure order.  Transformation of the information
needs to take place to build the TLV in any case so even it were in order a
straight mapping of a data structure into a TLV would not really be
practical unless it were in a single value field and in which case its
perfectly okay to do so.

Packet.AddTlv(mystruct.a);
Packet.AddTlv(mystruct.b);
Packet.AddTlv(mystruct.c);
Is no harder than.
Packet.AddTlv(mystruct.c);
Packet.AddTlv(mystruct.b);
Packet.AddTlv(mystruct.a);

> 2. It's a bit disingenuous to say you can process things in any order, 
> you just have to encode them and decode them in this order.
This I partly agree with although the encoding part should be trivial.
Decoding I will talk abut more.

> If you must put them in the packet in a specific order, then you must 
> process them in that order when building the packet. Since these are 
> TLVs, and you cannot know where one TLV starts until you reach the end 
> of the current TLV, you also cannot efficiently process the 
> information in the packet, unless you process it in the order it's 
> carried in the packet.

It really depends on the data being transmitted.  With MOST of the proposed
TLV definitions the order in which they are processed does not matter either
the entire packet needs to be processed or there is no harm in processing
the data which has so far arrived. There are a few which should come before
others in terms of processing on the receiving end we the space was split up
to accommodate this type of behavior.  

> > The single TLV type value per address does not restrict
> TLVs to carry
> > only one 'value' in the value field.  TLV's can be defined
> to carry an
> > arbitrary list of values in one value field which can be
> used however
> > the protocol wishes.
> 
> This means you cannot insert multiple copies of the same data (IE, 
> multiple next hops, or multiples of anything) without creating a TLV 
> with subTLVs for the pertinent information.
> 
This is a misconception.  You can insert multiple copies of similar data (I
use "similar" instead of same as I think its was meant, multiples of the
same data would be better represented by a single value and a number) using
a single TLV without using the subTLV area.  One just has to define their
TLV's value field to carry the list of information instead of a single
value.  Packetbb allows this list to be defined in a variable length
fashion.  The advantage of this is that a protocol can use the information
in whatever way makes sense and even lowers the TLV overhead from including
multiples of the same TLV.

> Let me put it another way. If a protocol would like to process 
> information in a specific order, there's nothing stopping it from 
> specifying, in a standard that explains how to apply packetbb to the 
> protocol, that the TLVs must be carried in a specific order. There is 
> no reason to restrict all protocols to a specific order simply because 
> it happens to make some protocols more efficient. Standards should not 
> be unnecessarily restrictive, especially when they can apply to a wide 
> range of protocols.

This I think hits very close to the difference of opinion.  Packetbb and the
TLV structure was designed in such a way in that the information contained
within the packet (other than the address block) does not rely on ordering.

> 
> Finally, forcing the order assumes that no possible optimization are 
> ever possible beyond the ones that have been invented to this point, 
> and covered in this specific draft.
> This is an unacceptable assumption on the part of the draft authors. 
> There's more than just what we know today to consider.
> 
> I understand that you don't think any of the examples or problems are 
> problems--it makes one or two protocols more efficient, it doesn't 
> appear to make the others less efficient, so we should go forth and 
> conquer. When you show me in your crystal ball that it will never 
> impact the performance of any possible protocol, and when you show me 
> why the protocols that do benefit from this restriction cannot include 
> this restriction in a separate draft, then I'll agree.
> 
I guess this is kind of the point.  We can't predict the future but we do
have some real examples which have gains.  I have repeatedly asked for
specific examples using packetbb on what one would like to do but can't
because of the restrictions and am still looking forward to seeing some.  I
haven't ever argued that there is no tradeoff, indeed there will be some
efficiently loses for certain types of wanted behaviors but as they are as
of yet unspecified. Going with what is best for the current specified
protocols seems to me to be the correct course of action.

> Since my crystal ball broke last week, and since no-one can seem to 
> offer a reason why these protocol specific restrictions couldn't be 
> placed in a protocol specific draft, I don't see any reason to move 
> forward with this draft.
> 
I somewhat agree with Thomas that this gives in many cases the worst of both
worlds and reduces the gains of each.  However this or some other similar
compromise may be the only way forward although to me it greatly reduces the
benefits. 

> The packet ordering requirements in the packetbb draft aren't a good 
> idea.
> 
I will try to remain open minded to be convinced of this. I have also not
given up trying to convince everyone otherwise.

Justin
> Russ
> 
> - --
> [email-masked] CCIE <>< Grace Alone
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHMlDcER27sUhU9OQRAmIKAJ91M7gZbH9FLD8R6fD5tlOH4v2e1QCg8U3/
> vrPpaNnL5UYmlCtTL5QHflk=
> =3gAX
> -----END PGP SIGNATURE-----
> 

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Nov 2007 09:18:37 -0800

Hello Justin,

I have made some examples to show useful
constructions that are disallowed by packetBB.
Here is one.

Assume there are address ranges R1:=[A1,A3]
and R2 := [A2,A4], where A1 < A2 < A3 < A4.
Suppose that for address in range R1, we want
to ascribe characteristic X1 [e.g., a service, or a
multicast address, or any one of an un-knowable
number of values of some type].  And then for
addresses in range R2, we want to assign from
the same type, characteristic X2.

As I understand it, this is not possible.

The type value might even be a structure, of
length hundreds of bytes (e.g., a certificate).
This would be wrong to duplicate just because
of the unwanted packetBB constraints.

Regards,
Charlie P.

---

From: "Justin Dean" <[email-masked]>
Date: Thu, 8 Nov 2007 13:18:47 -0500

Great!  I think you beat me to my one reply which now makes it look silly
well done!
Good example by the way.  First I would like to separate the issue into two
different problems as I am not sure what information is meant to be
conveyed.  
Does the sender want the "second" TLV to override the first or be part of a
list?
Which are correct?
A1 = [X1], A2 = [X2],    A3 = [X2],    A4 = [X2]
Or 
A1 = [X1], A2 = [X1,X2], A3 = [X1,X2], A4 = [X2] 

The first situation where the information (X2) is meant to override the
first type (X2) of information could be encoded in various ways here are a
few:

1) Use a multivalue TLV, mTLV1 for the entire range R 
mTLV1 R = [X1,X2,X2,X2].  
Overhead grows with size of the set however. But for this example there is
only one TLV overhead cost.

2) Use a combination of a single TLV, TLV1, for the first entry and a single
multivalue TLV, mTLV1 with one value for the range R2. 
TLV1  A1 = [X1]
mTLV1 R2 = [X2] (note the difference between this multivalue, one value, and
the previous, value for each entry, both are allowed)
This has the overhead of 2 different TLVs but does not encode multiple X2
values.  The growth is slower because of this as well as long as X2 remains
the value for the addresses in that order.

Both of the above examples use only one TLV type of which does not need to
use the full type.

3) Another way which would use more than one TLV type but would more closely
resemble what you are doing would be to define two TLVs.
The first TLV would be defined the same, it ascribes characteristic X to an
address A or range R.  The second one TLV2 would be similar but different in
meaning, it would convey the "no X is really this" TLV which by definition
overrides the first defined TLV
One could then use
mTLV1 R1 = [X1]
mTLV2 R2 = [X2]
The drawback with this is that a TLV type for each really in the "no REALLY
REALLY" would have to be defined.  Sub types would work well in this case
although if only one was needed (and I honestly don't see more than 2
actually being useful) then 2 separate TLVs types could be assigned.  This
last example would work exactly the same as with no restrictions except that
you would define two TLVs for use.  And in fact the order within the packet
does not change the meaning of the information, being conveyed.

These are just 3 examples and there are many more ways of encoding this type
of information.

The second situation is similar but very different in meaning.  Here are a
few examples of how one could encode the information using packetbb.
1) One could simply use single TLVs with the values to be associated with
the addresses.
TLV1 A1 = [X1]
TLV1 A2 = [X1,X2]
TLV1 A3 = [X1,X2]
TLV1 A4 = [X2]
There is a TLV overhead for each address which has a value when using this
method but its simple and straight forward.

2) Use 2 single TLVs and one multivalue TLVs defined such that
TLV1 A1  = [X1]
mTLV1 R3 = [X1,X2]  (this TLV would be defined in such a way that there is
only a single value to be mapped to each address in R3, R3:=[A2,A3]
TLV A4   = [X2]
There is less overhead in this example rather than the first in that there
is one less TLV and the shared information is only included once.

3) Again similar to the last example I gave further up a second TLV could be
defined (TLV3 so as not to conflict with TLV2 above) which conveys the
meaning "these values as well" or even "not really these values" to subtract
entries.  For this example "these values as well" TLV3 is used.
mTLV1 R1 = [X1]
mTLV3 R2 = [X2]
Notice how the layout is the same as in the last example for the first
situation and indeed Charlie's initial example as well, but the definition
of the TLV2 and TLV3 explicitly state what the meaning of the information
is.  There is a draw back when adding in multiple passes require more TLVs
but again I see diminishing returns on having more than 1 level of addition.

I feel these are good examples of what can be done but are by no means
exhaustive.  I hope that it helps illustrate what behaviors are allowed and
furthermore demonstrates the explicitness of the information being conveyed,
even without protocol knowledge, by conforming to the restrictions allows.
More complicated examples can lead to more complicated solutions for
certain.  I am sure there is enough flexibility within the current draft,
that papers can be written on how to best optimize encoding of information
within packetbb.  I would like to thank you Charlie for giving me this
example to work with.

Justin

> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Thursday, November 08, 2007 12:19 PM
> To: ext Justin Dean
> Cc: 'Manet'
> I have made some examples to show useful constructions that 
> are disallowed by packetBB.
> Here is one.
> 
> Assume there are address ranges R1:=[A1,A3] and R2 := 
> [A2,A4], where A1 < A2 < A3 < A4.
> Suppose that for address in range R1, we want to ascribe 
> characteristic X1 [e.g., a service, or a multicast address, 
> or any one of an un-knowable number of values of some type].  
> And then for addresses in range R2, we want to assign from 
> The type value might even be a structure, of length hundreds 
> of bytes (e.g., a certificate).
> This would be wrong to duplicate just because of the unwanted 
> packetBB constraints.
> 
> Regards,
> Charlie P.
> 
> 
> 
> ext Justin Dean wrote:
> >  Comments inline
> >
> >   
> > Well yes and no but I think this comment comes at the heart of what 
> > might be confusing.  You can't hold items in an arbitrary structure 
> > order and encode them in that order directly.  I agree with 
> that.  But 
> > to say that you must maintain the internal structure order 
> in the same 
> > order in which packets will be encoding seems wrong to me.  
> Its quite 
> > easy to encoded in any random order regardless of the 
> structure order.  
> > Transformation of the information needs to take place to 
> build the TLV 
> > in any case so even it were in order a straight mapping of a data 
> > structure into a TLV would not really be practical unless 
> it were in a 
> > single value field and in which case its perfectly okay to do so.
> >
> >> 2. It's a bit disingenuous to say you can process things in any 
> >> order, you just have to encode them and decode them in this order.
> >>     
> >> TLVs, and you cannot know where one TLV starts until you reach the 
> >> end of the current TLV, you also cannot efficiently process the 
> > It really depends on the data being transmitted.  With MOST of the 
> > proposed TLV definitions the order in which they are processed does 
> > not matter either the entire packet needs to be processed 
> or there is 
> > no harm in processing the data which has so far arrived. 
> There are a 
> > few which should come before others in terms of processing on the 
> > receiving end we the space was split up to accommodate this 
> type of behavior.
> >
> >
> >   
> > This is a misconception.  You can insert multiple copies of similar 
> > data (I use "similar" instead of same as I think its was meant, 
> > multiples of the same data would be better represented by a single 
> > value and a number) using a single TLV without using the 
> subTLV area.  
> > One just has to define their TLV's value field to carry the list of 
> > information instead of a single value.  Packetbb allows 
> this list to 
> > be defined in a variable length fashion.  The advantage of this is 
> > that a protocol can use the information in whatever way makes sense 
> > and even lowers the TLV overhead from including multiples 
> of the same TLV.
> >
> >   
> >> no reason to restrict all protocols to a specific order simply 
> >> because it happens to make some protocols more efficient. 
> Standards 
> >> should not be unnecessarily restrictive, especially when they can 
> >> apply to a wide range of protocols.
> >>     
> >
> > This I think hits very close to the difference of opinion.  
> Packetbb 
> > and the TLV structure was designed in such a way in that the 
> > information contained within the packet (other than the 
> address block) does not rely on ordering.
> >
> >
> >   
> >> why the protocols that do benefit from this restriction cannot 
> >> include this restriction in a separate draft, then I'll agree.
> >>
> >>     
> > I guess this is kind of the point.  We can't predict the 
> future but we 
> > do have some real examples which have gains.  I have 
> repeatedly asked 
> > for specific examples using packetbb on what one would like 
> to do but 
> > can't because of the restrictions and am still looking forward to 
> > seeing some.  I haven't ever argued that there is no 
> tradeoff, indeed 
> > there will be some efficiently loses for certain types of wanted 
> > behaviors but as they are as of yet unspecified. Going with what is 
> > best for the current specified protocols seems to me to be 
> the correct course of action.
> >
> >
> >   
> > I somewhat agree with Thomas that this gives in many cases 
> the worst 
> > of both worlds and reduces the gains of each.  However this or some 
> > other similar compromise may be the only way forward 
> although to me it 
> > greatly reduces the benefits.
> >
> >   
> > I will try to remain open minded to be convinced of this. I 
> have also 
> > not given up trying to convince everyone otherwise.
> >
> > Justin
> >   
> >> Russ
> >>
> >> - --

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Nov 2007 14:43:23 -0800

Hello Justin,

My example was meant to associate both values,
not to over-ride the first value with the second value.
Also, my ranges were supposed to be intervals of
perhaps many addresses, so that for instance
[A1,A3] might contain thousands of addresses.

With this understanding, I can still apply your examples.
It seems to me that several of your variations do
serve to exemplify the additional complications which
are introduced by the constraints.  Having to define
such a "not really" type is, I think, unprecedented
in the IETF world of TLVs.  At least I have never
heard of it, and honestly I'd be afraid to get up to
a mike and propose such a thing in public.  There
are, of course, some removal TLVs, but they are
designed to be sent a lot _later_, not at the same
time(!).

Since I have your attention, can you explain again
why in the heck these constraints cannot be mandated
per protocol?  The last attempt by Thomas really rated
quite low on my scale of believability.

> method but its simple and straight forward.
the nasty thing is that you are repeating the data.
As I mentioned, this may introduce unwanted
kilobytes of overhead in the representation.

> entries.  For this example "these values as well" TLV3 is used.
I am still scratching my head and puzzling over this, but anyway
the two alternatives you suggest in this example are not at all
like each other.  Or it could be that this is where my interval
ranges are not compatible in interpretation with your interpretation
as ordered pairs.

As a general comment, though, given a common understanding
that one wants to assign perhaps several values to addresses in
overlapping ranges of addresses, I think the solution that I am
requesting is dramatically simpler than the alternatives suggested.

Please let me know whether viewing [A1,A3] and [A2,A4] as
intervals instead of ordered pairs makes a difference in your
suggested alternatives.

Lastly, regarding [1..googolplex].... The point was to show that
just because one can reformulate a solution in order to conform
to the packetBB constraints, does not make it a good idea to
have to make the reformulation.  And, as your alternatives below
are showing, in order to reformulate, one can be required to do
various "non-IETF-ful" things.

Regards,
Charlie P.

ext Justin Dean wrote:
>>>> structure order. You must always maintain your internal 
>>>>         
>> structure in 
>>     
>>>> the same order as the information in the packet is allowed 
>>>>         
>> to appear.
>>     
>>>>     
>>>>         
>>> This I partly agree with although the encoding part should 
>>>       
>> be trivial.
>>     
>>>> If you must put them in the packet in a specific order, 
>>>>         
>> then you must 
>>     
>>>> process them in that order when building the packet. Since 
>>>>         
>> these are 
>>     
>>>> multiple next hops, or multiples of anything) without 
>>>>         
>> creating a TLV 
>>     
>>>> specifying, in a standard that explains how to apply 
>>>>         
>> packetbb to the 
>>     
>>>> protocol, that the TLVs must be carried in a specific 
>>>>         
>> order. There is 
>>     
>>>> Finally, forcing the order assumes that no possible 
>>>>         
>> optimization are 
>>     
>>>> ever possible beyond the ones that have been invented to 
>>>>         
>> this point, 
>>     
>>>> This is an unacceptable assumption on the part of the 
>>>>         
>> draft authors. 
>>     
>>>> I understand that you don't think any of the examples or 
>>>>         
>> problems are 
>>     
>>>> appear to make the others less efficient, so we should go 
>>>>         
>> forth and 
>>     
>>>> impact the performance of any possible protocol, and when 
>>>>         
>> you show me 
>>     
>>>> Since my crystal ball broke last week, and since no-one 
>>>>         
>> can seem to 
>>     
>>>> offer a reason why these protocol specific restrictions 
>>>>         
>> couldn't be 
>>     
>>>> placed in a protocol specific draft, I don't see any 
>>>>         
>> reason to move 
>>     
>>>> forward with this draft.
>>>>
>>>>     
>>>>         
>>>> The packet ordering requirements in the packetbb draft 
>>>>         
>> aren't a good 
>>     
>>>> idea.
>>>>
>>>>     
>>>>

---

From: Russ White <[email-masked]>
Date: Thu, 08 Nov 2007 19:54:41 -0500

>> You can't hold items in an arbitrary structure order and encode
>> them in that order directly.  I agree with that.  

I must be confused by something here.... The line of argument I'm
hearing is:

1. It's important to keep the TLVs in order to make encoding more
efficient for some protocols.
2. Those protocols who don't want to process their TLVs in order can
simply ignore the order in the packet, and process them any way they
want to.

Doesn't this line of reasoning also suggest that any implementation that
wants to process the TLVs in a specific order may also ignore the
ordering in the packet, and simply process them in order? Doesn't the
argument work in both directions?

If the ordering of the TLVs in the packet is so easy to "get around,"
then why does the ordering of the TLVs in the packet matter at all?

As I said at the beginning of this thread--IMHO, there are a lot of
creative ways around this ordering problem. I listed a few of them in
that original email. I don't understand why some system that allows
either encoding. What I'm hearing is--I want this organized so it
optimizes my protocol. Other protocols can work around what I need
(because I don't think it's so hard for them to work around what I
want!). IMHO, this is a bad way to build a standard specifically
designed to support many competing protocols.

:-)

Russ

- --

---

From: "Justin Dean" <[email-masked]>
Date: Fri, 9 Nov 2007 10:52:09 -0500

I would like to point out that the examples I have given are really only
applicable if there is no difference in the information at all.  This is
often not the case although they may be similar and sometimes it actually is
the case.  

An example of similar information might define a TLV "link type" in which
link types may overlap.  Separation the overlapping data into separate TLVs
where possible (such as "link status" as symmetric, asymmetric, lost and
"link attribute" mpr, dead-end) removes having to use the examples I have
given below as the information now being conveyed is internally exclusive.

This may not always be possible or desired in which case the examples I have
given below, I feel are good alternatives which allow for a wide range of
encodings.

A few comments inline.

> Sent: Thursday, November 08, 2007 5:43 PM
> To: ext Justin Dean
> Cc: 'Manet'
> My example was meant to associate both values, not to 
> over-ride the first value with the second value.
> Also, my ranges were supposed to be intervals of perhaps many 
> addresses, so that for instance [A1,A3] might contain 
> thousands of addresses.
> 

Glad you found them as such.  Some working much better than others at
certain intervals with added exceptions.

> It seems to me that several of your variations do serve to 
> exemplify the additional complications which are introduced 
> by the constraints.  Having to define such a "not really" 
> type is, I think, unprecedented in the IETF world of TLVs.  
> At least I have never heard of it, and honestly I'd be afraid 
> to get up to a mike and propose such a thing in public.  
> There are, of course, some removal TLVs, but they are 
> designed to be sent a lot _later_, not at the same time(!).
> 
Having to define the "not really" or "in addition to" TLVs come directly
from using "tricks" to compress the packet overhead they are not needed if
one is willing to live with the larger overhead of not having them.  I am
actually quite happy that packetbb can encode, relatively natively,
information in this compact a form.  I would argue that most protocols do
not allow for this rich of an encoding mechanism so more complicated
behaviors are really not needed.

> Since I have your attention, can you explain again why in the 
> heck these constraints cannot be mandated per protocol?  The 
> last attempt by Thomas really rated quite low on my scale of 
> believability.

To me the one TLV per address constraint is to help lead to coherent packets
in which information is not ambiguous at the packet level.  In all of my
examples a parser could take in a packet and present the information in
terms of individual address and TLV values specifically associated with
those addresses; a class representation would be the same in all cases,
without needed any protocol knowledge.  I think my confusion on what was
exactly being conveyed with the original example clearly represents what I
am trying to say here.  Furthermore different orderings of TLVs could change
the meaning of the data being represented.  

To me this added "complication" in defining TLVs is worth the explicitness
it forces.  I also think that the example here discussed will not be the
normal mode of TLV operation but the exception, but that when it does happen
it can be supported.

Justin

> 
> For this case:
> > 1) One could simply use single TLVs with the values to be 
> associated 
> > with the addresses.
> > TLV1 A1 = [X1]
> > TLV1 A2 = [X1,X2]
> > TLV1 A3 = [X1,X2]
> > TLV1 A4 = [X2]
> > There is a TLV overhead for each address which has a value 
> when using 
> > this method but its simple and straight forward.
> As I mentioned, this may introduce unwanted kilobytes of 
> overhead in the representation.
> 
> > 3) Again similar to the last example I gave further up a second TLV 
> > could be defined (TLV3 so as not to conflict with TLV2 above) which 
> > conveys the meaning "these values as well" or even "not 
> really these 
> > values" to subtract entries.  For this example "these 
> values as well" TLV3 is used.
> > mTLV1 R1 = [X1]
> > mTLV3 R2 = [X2]
> I am still scratching my head and puzzling over this, but 
> anyway the two alternatives you suggest in this example are 
> not at all like each other.  Or it could be that this is 
> where my interval ranges are not compatible in interpretation 
> with your interpretation as ordered pairs.
> 
> that one wants to assign perhaps several values to addresses 
> in overlapping ranges of addresses, I think the solution that 
> I am requesting is dramatically simpler than the alternatives 
> suggested.
> 
> Lastly, regarding [1..googolplex].... The point was to show 
> that just because one can reformulate a solution in order to 
> conform to the packetBB constraints, does not make it a good 
> idea to have to make the reformulation.  And, as your 
> alternatives below are showing, in order to reformulate, one 
> can be required to do various "non-IETF-ful" things.
> 
> Regards,
> Charlie P.
> 
> 
> 
> ext Justin Dean wrote:
> > Great!  I think you beat me to my one reply which now makes it look 
> > silly well done!
> > Good example by the way.  First I would like to separate the issue 
> > into two different problems as I am not sure what 
> information is meant 
> > to be conveyed.
> > Does the sender want the "second" TLV to override the first 
> or be part 
> > of a list?
> > Which are correct?
> > The first situation where the information (X2) is meant to override 
> > the first type (X2) of information could be encoded in various ways 
> > here are a
> > few:
> >
> > Overhead grows with size of the set however. But for this example 
> > there is only one TLV overhead cost.
> >
> > 2) Use a combination of a single TLV, TLV1, for the first 
> entry and a 
> > single multivalue TLV, mTLV1 with one value for the range R2.
> > TLV1  A1 = [X1]
> > mTLV1 R2 = [X2] (note the difference between this multivalue, one 
> > value, and the previous, value for each entry, both are 
> allowed) This 
> > has the overhead of 2 different TLVs but does not encode 
> multiple X2 
> > values.  The growth is slower because of this as well as long as X2 
> > remains the value for the addresses in that order.
> >
> > Both of the above examples use only one TLV type of which does not 
> > need to use the full type.
> >
> > 3) Another way which would use more than one TLV type but 
> would more 
> > closely resemble what you are doing would be to define two TLVs.
> > The first TLV would be defined the same, it ascribes 
> characteristic X 
> > to an address A or range R.  The second one TLV2 would be 
> similar but 
> > different in meaning, it would convey the "no X is really this" TLV 
> > which by definition overrides the first defined TLV One 
> could then use
> > mTLV1 R1 = [X1]
> > mTLV2 R2 = [X2]
> > The drawback with this is that a TLV type for each really 
> in the "no 
> > REALLY REALLY" would have to be defined.  Sub types would 
> work well in 
> > this case although if only one was needed (and I honestly don't see 
> > more than 2 actually being useful) then 2 separate TLVs 
> types could be 
> > assigned.  This last example would work exactly the same as with no 
> > restrictions except that you would define two TLVs for use.  And in 
> > fact the order within the packet does not change the 
> meaning of the information, being conveyed.
> >
> > These are just 3 examples and there are many more ways of encoding 
> > this type of information.
> >
> > The second situation is similar but very different in 
> meaning.  Here 
> > are a few examples of how one could encode the information 
> using packetbb.
> > 1) One could simply use single TLVs with the values to be 
> associated 
> > with the addresses.
> > TLV1 A1 = [X1]
> > TLV1 A2 = [X1,X2]
> > TLV1 A3 = [X1,X2]
> > TLV1 A4 = [X2]
> > There is a TLV overhead for each address which has a value 
> when using 
> > this method but its simple and straight forward.
> >
> > mTLV1 R3 = [X1,X2]  (this TLV would be defined in such a way that 
> > there is only a single value to be mapped to each address 
> in R3, R3:=[A2,A3]
> > TLV A4   = [X2]
> > There is less overhead in this example rather than the 
> first in that 
> > there is one less TLV and the shared information is only 
> included once.
> >
> > 3) Again similar to the last example I gave further up a second TLV 
> > could be defined (TLV3 so as not to conflict with TLV2 above) which 
> > conveys the meaning "these values as well" or even "not 
> really these 
> > values" to subtract entries.  For this example "these 
> values as well" TLV3 is used.
> > mTLV1 R1 = [X1]
> > mTLV3 R2 = [X2]
> > situation and indeed Charlie's initial example as well, but the 
> > definition of the TLV2 and TLV3 explicitly state what the 
> meaning of 
> > the information is.  There is a draw back when adding in multiple 
> > passes require more TLVs but again I see diminishing 
> returns on having more than 1 level of addition.
> >
> >
> > exhaustive.  I hope that it helps illustrate what behaviors are 
> > allowed and furthermore demonstrates the explicitness of the 
> > information being conveyed, even without protocol 
> knowledge, by conforming to the restrictions allows.
> > certain.  I am sure there is enough flexibility within the current 
> > draft, that papers can be written on how to best optimize 
> encoding of 
> > information within packetbb.  I would like to thank you Charlie for 
> > giving me this example to work with.
> >
> > Justin
> >
> >
> >   
> >> I have made some examples to show useful constructions that are 
> >> disallowed by packetBB.
> >> Here is one.
> >>
> >> characteristic X1 [e.g., a service, or a multicast address, or any 
> >> one of an un-knowable number of values of some type].
> >> The type value might even be a structure, of length 
> hundreds of bytes 
> >> (e.g., a certificate).

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Nov 2007 08:35:53 -0800

Hello Justin,

> given below as the information now being conveyed is internally exclusive.
 You are basically reiterating the single assignment model for variables,
which is not always the right model.  It is not helpful to reiterate 
that one
can reformulate other designs to fit this model, as I tried to 
illustrate using
my [1..googolplex] example.
> given below, I feel are good alternatives which allow for a wide range of
 No doubt they allow for a wide range.  That might make them applicable
for many protocols.  But packetBB is, I thought, supposed to support future
protocols, and I think many people are in agreement that this 
single-assignment
model is not sufficient.

And it certainly is not necessary to mandate!
> from using "tricks"to compress the packet overhead
 They aren't really tricks.  They are good techniques.  They have been used
before.

>  they are not needed if
> one is willing to live with the larger overhead of not having them.
 The overhead is already quite considerable, and is debatably already
too large.  Making it worse would kill it dead in the water.

>   I am
> information in this compact a form.
 Nobody is saying that packetBB should avoid specifying this way
of compressing address ranges.  So I think this line of discussion is
distracting from the point.
>   I would argue that most protocols do
 Do you mean to say that no other protocols deal with
address ranges?

> in which information is not ambiguous at the packet level. 
 Do you mean that the examples I presented are not coherent?

>  In all of my
> those addresses;
It could do equally well this if the constraints were type dependent.
>  a class representation would be the same in all cases,
> without needed any protocol knowledge.
 Why is this a good thing?  Why not enforce that all classes have
exactly 38 bytes of data storage?  Why not have two kinds of
classes?   Isn't this well-known technology?

>   I think my confusion on what was
> am trying to say here.
 It was not a very confusing example, and anyone reading
a protocol specification would not make the mistake.
If you like, we could try to get a reading from other members
of the working group whether they were confused by my
example.  I did, after all, explicitly use the word "range" to
describe the address range objects.

>   Furthermore different orderings of TLVs could change
 Not in my example.
> normal mode of TLV operation but the exception, but that when it does happen
 I think that this explicitness can be specified per protocol.
So I did not find anything in your discussion to support the
mandate.  And, for protocol designers who find the constraint
worthwhile, it can easily be specified to have them.  They are
going to make normative refereneces to packetBB anyway.

A lot of discussions about packetBB have gone this way.

I asked "Why mandate for all protocols?"

The answer is that "packetBB has good features".
But this is not at issue.  So, not helpful to the discussion!

Sometimes the answer seems to be "our parser likes
it better to avoid a test on protocol type".

But I reckon the likely way for constructing such
a parser should be able to do this without much
problem, with several different kinds of solutions
available.

One time it was claimed that there would result
a "quick abort" feature.  Then that was characterized
as a minor benefit, and I presented discussion that
pointed out that it was often likely to be a performance
loss.

It was suggested to be a mechanism to deter DoS
attacks.  That suggestion did not last very long.

I have provided examples on several occasions,
showing the danger of exorbitant packet bloat, but
the next round of discussion claims that no examples
were given.

At root, I think the problem is of fixation on the
following characterization:
> in which information is not ambiguous at the packet level.
So to do anything other than single-value assignment
to variables is (?) characterized as incoherent?  I seem
to remember also that it was deemed inelegant and
perhaps even "crappy".  Well, it's _NOT_ incoherent
or crappy, when needed.

If you find that the single assignment model is appropriate
for your protocol designs, then that's great!  But it does not
mean that other protocol designs are unworthy of support
within the packetBB metaspecification.

Furthermore, I reiterate that the constraints were inserted
into the specification without discussion on the mailing list,
or at least without significant discussion that registered on
my mind and I typically read every message not including
spams.

Regards,
Charlie P.

---

From: Russ White <[email-masked]>
Date: Fri, 09 Nov 2007 13:57:08 -0500

>> one is willing to live with the larger overhead of not having them.

I would suggest that all sorts of situations exist in the real
world--there is a sliding scale between packet efficiency on the wire,
and CPU efficiency. To assume that all protocols will fall in precisely
the same place on this sliding scale is a rather large assumption, IMHO.

>> behaviors are really not needed.

I would completely disagree with this idea. Have you examined the BGP
packet encoding? Or perhaps the ROAs being put on the standard track for
BGP? These are rather complex packet encodings, probably more so that
what's being proposed here, and yet--they don't require ordering in the
sense that this proposal requires it.

There is a tradeoff in this space, between ordering to imply
application, and explicitly signaling the application (meaning how to
apply the information in the packet). IMHO, packetbb, as it stands right
now, is an extreme example on one end of the scale.

All anyone is asking is that the options exist to allow packetbb to be
used at various points along that scale, rather than only in one place.

> describe the address range objects.

I certainly understood the example, and believed it was a good, specific
example, of an encoding mechanism that would be problematic as packetbb
currently stands.

> And it certainly is not necessary to mandate!

IMHO, this is the root of the problem. There are a lot of creative
solutions which allow protocols which want to encode in this way to
actually encode in this way, and allows protocols which don't not to.

:-)

Russ

- --

---

From: "Justin Dean" <[email-masked]>
Date: Fri, 9 Nov 2007 14:36:55 -0500

> Sent: Friday, November 09, 2007 1:57 PM
> To: Charles E. Perkins
> Cc: ext Justin Dean; 'Manet'
> >> Having to define the "not really" or "in addition to" TLVs come 
> >> directly from using "tricks"to compress the packet overhead
> 
> > They aren't really tricks.  They are good techniques.  They 
> have been 
> > used before.
> > 
> >>  they are not needed if
> I would suggest that all sorts of situations exist in the 
> real world--there is a sliding scale between packet 
> efficiency on the wire, and CPU efficiency. To assume that 
> all protocols will fall in precisely the same place on this 
> sliding scale is a rather large assumption, IMHO.

No one is making this assumption and in fact packetbb allows for this range.
If its worth reducing overhead of using these good techniques for the type
of data to be transmitted then they can be used. If not they don't need to
be was all I was saying.

> 
> >>   I would argue that most protocols do not allow for this 
> rich of an 
> >> encoding mechanism so more complicated behaviors are really not 
> >> needed.
> 
> I would completely disagree with this idea. Have you examined 
> the BGP packet encoding? Or perhaps the ROAs being put on the 
> standard track for BGP? These are rather complex packet 
> encodings, probably more so that what's being proposed here, 
> and yet--they don't require ordering in the sense that this 
> proposal requires it.
> 
I knew this line was going to come back to get me.  I was speaking to the
address block compression along with the flexible multivalue TLV structure
and not the ordering.  I will certainly go over those documents and retract
this statement.

> application, and explicitly signaling the application 
> (meaning how to apply the information in the packet). IMHO, 
> packetbb, as it stands right now, is an extreme example on 
> one end of the scale.
> 
> All anyone is asking is that the options exist to allow 
> packetbb to be used at various points along that scale, 
> rather than only in one place.
> 
> > It was not a very confusing example, and anyone reading a protocol 
> > specification would not make the mistake.
> > If you like, we could try to get a reading from other 
> members of the 
> > working group whether they were confused by my example.  I 
> did, after 
> > all, explicitly use the word "range" to describe the address range 
> > objects.
> 
> I certainly understood the example, and believed it was a 
> good, specific example, of an encoding mechanism that would 
> be problematic as packetbb currently stands.
> 

I too thought the example was good.  What I thought was confusing was the
meaning implied by [X1,X2].  
Possible meanings could be
X1 and X2 (almost default the second example I gave)
X1 or X2 
X2 not X1  (the first example I gave)
X1 then X2

I thought I clearly demonstrated how it was not really problematic to encode
almost exactly as Charlie wished. (change of TLV definition and additional
TLV type)  The size of encoding was the same only the value of the type
field was different.  

> IMHO, this is the root of the problem. There are a lot of 
> creative solutions which allow protocols which want to encode 
> in this way to actually encode in this way, and allows 
> protocols which don't not to.
> 
It does allow them to.

Justin

Ps I am glad that we are discussing merits and draw backs at this point. 

> iD4DBQFHNK2EER27sUhU9OQRAt17AKCkorMV3Xhaw36RCw66x7RCU221uQCYux4h
> 8G+N3tUJjSS2mE5TIXWLdQ==
> =z33W

---

From: Russ White <[email-masked]>
Date: Fri, 09 Nov 2007 14:35:45 -0500

>> TLV type)  The size of encoding was the same only the value of the type

The problem is your additional TLV is counterintuitive.... And something
that's not done. "Oh, this part I just said applies, it doesn't really
apply to this specific piece of information, so just take that back out
of your structures."

> protocols which don't not to.

Hmmm.... Not according to what I read in the draft, and not according to
what I see on list. The packet formatting is very strictly ordered, and
the general response has been: "If you don't like the ordering, just
hold the entire packet in memory, and process it in some other order."

>> Ps I am glad that we are discussing merits and draw backs at this point. 

I would prefer to be discussing a mechanism which would allow protocols
to use require ordering, while others don't. It would be a much more
productive discussion.

:-)

Russ

- --

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 19 Nov 2007 21:28:31 +0530

This note announces the WG Last Call for comments on
draft-ietf-manet-timetlv, "Representing multi-value time in MANETs".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-04.txt

The document is intended to be submitted for publication as a proposed
standard document.

Please review the document carefully and send your comments to the
MANET list and document authors.

This last call will end Wed Nov 30th AOE.

Thanks,
Ian Chakeres