Subject: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVs of the same type

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 14 Aug 2007 17:53:03 +0530

I'd like to focus the discussion around allowing multiple TLVs of the
same type to be associated with the one entity in packetbb.

If you have a good use case, please provide it and describe why it is useful.

Ian Chakeres

Note: I would like to quickly finish any remaining PacketBB discussion
and move this document forward.

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

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 14 Aug 2007 13:56:43 +0100

I've attached both of Ian's messages, this is really
a reply to both.

I don't regard these as separate, they are linked.
If you have multiple TLVs then useful ordering is
difficult with indexes. (Packet/message TLVs can still
be ordered.) Ordering however is what allows non-multiple
TLVs to be efficiently recognised.

That makes the non-unique case the critical one. And
I regard having a use case as necessary, but not
sufficient to consider a change, given the real, rather
than hypothetical, gains that are currently available.

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 14 August 2007 13:23
To: manet
Subject: [manet] PacketBB Recent Discussion #1 - Allowing multiple TLVs
ofthe same type

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

If you have a good use case, please provide it and describe why it is
useful.

Ian Chakeres

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

I'd like to focus the discussion around ordering of TLV types within TLV
blocks.

If you have a good reason why we should not consistently order TLVs
within a TLV block, please email it to the list. Please provide a
clear use case that shows why ordering the TLVs is bad.

Thanks.
Ian Chakeres

********************************************************************
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: "Stan Ratliff \(sratliff\)" <[email-masked]>
Date: Tue, 14 Aug 2007 11:02:46 -0400

Ian, 

I think that Justin provided a use case in his email: 

--------------------Included email----------------------
With 3 this was introduced to avoid confusion on which value should be
used.
I personally would be ok with wording this closer to 2 in mandating that
the
tlv definitions explicitly disallow or allow.  There are issues with
allowing this but there may also be an advantages.  A hypothetical
example;
10 addresses each of which is either bright or dark and blue or red
1 bright red
2 bright blue
3 bright red
4 bright red
5 bright red
6 dark red
7 dark blue
8 dark red
9 dark red
10 dark red

Under the current constraints it would require 1 indexed tlv for bright
1
indexed tlv for dark, then either a m-tlv for all the addressed or a
mixture
of m-tlvs and indexed tlvs for the color.  If constraint of more than
one
was lifted for the color tlv a m-tlv for all nodes being red and then 2
single tlvs for the 2 blue nodes may reduce overhead. 
-------------------End of inclusion----------------------

Regards,
Stan

>Sent: Tuesday, August 14, 2007 8:23 AM
>To: manet
>Subject: [manet] PacketBB Recent Discussion #1 - Allowing 
>multiple TLVs ofthe same type
>

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 14 Aug 2007 16:25:50 +0100

I wouldn't regard that as a real use case - when was the last
time you actually wanted to declare a node as bright red?

In addition I don't actually think it is a good example. What
is the relationship between bright and red?

- If bright red is a colour, why not simply encode bright red,
  bright blue, dark red etc. as separate colours in a single
  value space? What's the advantage of separating them but also
  regarding them as the same TLV - one with values including
  red, blue, bright and dark, a definite apples and oranges
  sort of value list?

- If bright is something quite separate from red, we have two
  TLVs, and putting them in a single value space makes no sense
  at all.

- If you consider bright to be a modifier of colour, then a
  natural encoding is to use TLV subtypes, one for colour,
  one for brightness. Note that you can have two TLVs of the
  same type but different subtypes (i.e different full types)
  associated with the same information.

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 14 August 2007 16:03
To: Ian Chakeres; manet
Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing multiple
TLVsofthe same type

               *** WARNING ***

Ian, 

-------------------End of inclusion----------------------

Regards,
Stan

---

From: "Justin Dean" <[email-masked]>
Date: Tue, 14 Aug 2007 12:21:41 -0400

Well those were just two attributes which came to mind when writing the
example.  Having say link type of symmetric/asymmetric as one type and then
another orthogonal attribute lets say willingness where most nodes have
willingness of default and 2 are never illustrates this with a more
reasonable way.  They are separate disjoint attributes apples to oranges yes
and they should be.  There is, however, value in having them associated with
the same address block and there is no clear way to order the addresses to
allow for aggregation of both sets of information within the same address
block.

Having said that though the gains given in this example are minimal. In the
current case the two fixed size tlvs can advertise all of the first
attributes.  The second tlv most likely would use a single m-tlv to assign
the mixed up attributes to all of the nodes. Relaxing this restraint would
allow for some gains in terms of the size of representation of the second
attribute in some cases (not all dependant on how jumbled the values were).

Size of current restrained packetbb = tlvoverhead*3+#addresses. (worst case)
Optional size of unrestrained packetbb =
tlvoverhead*3+tlvoverhead*#ofdisjointattirbutes. 

There are many different ways to represent different attributes with the
current draft already.  And it isn't always clear on what the best encoding
scheme is for any given case as it is.  Relaxing this restriction would
allow another option to try and further reduce overhead but only in the case
where the second attribute is mostly the same with small number of different
values.  I don't often think this will be the case.

Please correct me if I am wrong but I don't see a big issue with allow
derived protocols to decide on this behavior.  It doesn't seem like it would
break any further protocols by not having it in packetbb.  So my question to
you guys is, what are the tradeoffs with changing the wording to more
closely reflect the issues with regard to multiple message/packet
tlvfulltypes?

The ordering restriction I am still very strongly in favor of keeping.

Justin

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:[email-masked]] 
Sent: Tuesday, August 14, 2007 11:26 AM
To: Stan Ratliff (sratliff); Ian Chakeres; manet
Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing
multipleTLVsofthe same type

I wouldn't regard that as a real use case - when was the last time you
actually wanted to declare a node as bright red?

In addition I don't actually think it is a good example. What is the
relationship between bright and red?

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]]
Sent: 14 August 2007 16:03
To: Ian Chakeres; manet
Subject: RE: [manet] PacketBB Recent Discussion #1 - Allowing multiple
TLVsofthe same type

               *** WARNING ***

Ian, 

-------------------End of inclusion----------------------

Regards,
Stan

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 09:45:57 +0100

> derived protocols to decide on this behavior.

I'm afraid I do, for reasons already stated, particularly
the complex inter-relation of the protocols using packetbb,
and the appropriateness of generic packetbb parsing code.

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 21 Aug 2007 20:45:10 +0530

I believe that there has been sufficient discussion on this issue, and
that there is a good reason to keep the existing restriction to
disallow having multiple TLVs of the same type associated with the
same entity in PacketBB.

If you have additional use cases, please provide them quickly.
Otherwise, I will consider this issue closed.

Ian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Aug 2007 12:45:05 -0700

Hello Ian,

I think it is quite likely that one will want to associate
multiple values to the same range of addresses. 
Suppose some nodes within the range need to be
described by two different characteristics from the
range of values for some specific type TLV.
Then this restriction would be harmful.

Am I missing something?  Why isn't this clear?

I can see that OLSRv2 does not need this now, but
we are discussing a packet template for future [manet]
protocols and I really think it would be a mistake to
try to mandate this restriction for the indefinite future.
Plus, I don't even think it buys us very much now!

Furthermore, there are certainly cases where we
would want to have the same "type" TLV appear
more than once.  I am not sure that this fits within the
general "case" where multiple TLVs of the same type
associated with the same "entity" in PacketBB,
because I am not sure what is an "entity" and what
is not an "entity".  For one example, though, I would
like to have a more economical way of describing
neighborhoods, as I have mentioned recently, and
it would be nice to _allow_ including multiple
instances of the same such TLV.

Regards,
Charlie P.

---

From: "Justin Dean" <[email-masked]>
Date: Tue, 21 Aug 2007 16:53:42 -0400

> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Tuesday, August 21, 2007 3:45 PM
> To: ext Ian Chakeres
> Cc: manet
> Subject: Re: [manet] Re: PacketBB Recent Discussion #1 - 
> Allowing multipleTLVs of the same type
> 
> 
> Hello Ian,
> 
> Suppose some nodes within the range need to be described by 
> two different characteristics from the range of values for 
> some specific type TLV.
You can do this.  You can include as many different tlv types (different
characteristics) per address as you wish.
This restriction is to disallow assigning different values of the same
characteristic to the same address, NOT to restrict how many characteristics
may be described.  Different characteristics should be described with a
different tlv type.  That being said let me give yet another example:

Say the characteristic for a given tlv is link type.  Links can be described
as symmetric, asymmetric, lost, heard, mpr, or something else entirely.  The
issue I think is tripping people up is that these particular characteristics
are not exclusive; A link can be both symmetric, heard and mpr or asymmetric
and heard.  There are a few ways to convey this information using the
current packetbb with restrictions.  

Break up the link types into two tlvs who's properties are exclusive within
each tlv.  So one tlv denoting asymmetric, symmetric, and lost.  And another
tlv which denotes lost, or mpr.  

Use a TLV for each trait.  This can be useful for large blocks of addresses
which have the same information.  With the inclusion of tlv subtypes there
is a much richer tlv type space to use.

Define your value space within the TLV to be exclusive.  The first two bits
denote symmetric, asymmetric, and lost and the following bits denote heard,
or mpr.  In this way only one tlv needs to be used to give the data about
the trait you are trying to use.

Attempting to use one TLV to describe two different attributes is confusing.
That being said one could define an "everything" tlv which includes large
value fields defining everything about an address.

> I can see that OLSRv2 does not need this now, but we are 
> discussing a packet template for future [manet] protocols and 
> I really think it would be a mistake to try to mandate this 
> restriction for the indefinite future.
> Furthermore, there are certainly cases where we would want to 
> have the same "type" TLV appear more than once.  I am not 
> sure that this fits within the general "case" where multiple 
> TLVs of the same type associated with the same "entity" in 
> PacketBB, because I am not sure what is an "entity" and what 
> is not an "entity".  For one example, though, I would like to 
> have a more economical way of describing neighborhoods, as I 
> have mentioned recently, and it would be nice to _allow_ 
> including multiple instances of the same such TLV.

One of my above examples for solving this within the current packetbb should
be sufficient for what you are trying to do with the restrictions still in
place.

Justin
> >> Note: I would like to quickly finish any remaining PacketBB 
> >> discussion and move this document forward.
> >>
> >>     
> >
> >

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 21 Aug 2007 15:23:55 -0700

Hello Justin,

Your example shows how to segregate type values so that
they fall into neat, mutually exclusive bins.  But that is not
always possible.  For instance, I don't see how it applies
to my example of the reduced-size neighborhood descriptor
TLV; I showed a candidate proposal last week.  It should
be possible to insert multiple such TLVs of the same type,
but with different value fields.  The value fields may have
substructure, and not be a simple array of slots for scalars.
Clearly, in this case it makes very little sense to require
the redundant definition of multiple types, just so one
could supply different value structures.

If I can have multiple such TLVs of the same type,
I will be happy on this point.  I think, however, this is a
good case in point about how restrictions are being
made based on a very limited experience with how
they fit into the current design of our existing protocols.

I think your example also shows that placing this restriction
carries with it perhaps unintended consequences -- in
this case, that _only_ value ranges with some sort of
"Pauli exclusion principle" can be supported under packetbb.
I'm pretty sure there are lots of other kinds of value fields
that may be needed in the future.

Regards,
Charlie P.

ext Justin Dean wrote:
>>> I believe that there has been sufficient discussion on this 
>>>       
>> issue, and 
>>     
>>>> I'd like to focus the discussion around allowing multiple 
>>>>         
>> TLVs of the 
>>     
>>>> If you have a good use case, please provide it and 
>>>>         
>> describe why it is useful.
>>     
>>>> Ian Chakeres
>>>>