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

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 7 Nov 2007 23:19:07 +0530

This note announces the WG Last Call for comments on
draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message
Format".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.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.

Given the relatively minor recent changes (added version. added packet
size. added special IANA alloc for TLV types 0 to 7.), this last call
will end Wed Nov 14th AOE.

Thanks,
Ian Chakeres

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 07 Nov 2007 11:16:17 -0800

Hello Ian,

I think that the document is not ready for publication until the
mandates for uniqueness and ordering of address TLVs are
softened to MAY.  Text should be added to indicate that
individual protocols that conform to packetBB can mandate
the use need for this feature if so desired.

Regards,
Charlie P.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 7 Nov 2007 14:25:57 -0500

Ian, 

I agree with Charlie's recommendation. 

Regards,
Stan

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Wednesday, November 07, 2007 2:16 PM
>To: ext Ian Chakeres
>Cc: manet
>Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC
>
>
>Hello Ian,
>

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 7 Nov 2007 20:41:27 +0100

Ian,

I suggest that the arguments presented for changing the mandates from  
MUST to MAY have been insufficient, and that the consequences of  
doing so have not been fully considered by the proponents of this  
change.

I furthermore note that the current mandates in packetbb in no way is  
limiting the applicability within the intended problem domain of  
MANET protocols, and that therefore -- given the benefits which have  
been presented elsewhere -- it is timely to move forward with this I- 
D towards publication.

Regards,

Thomas

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

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 7 Nov 2007 20:57:17 +0100

Can we come up with a proposal that is acceptable for all of us?
We could spend a <msg-semantics> bit and declare the restrictions active
when set (or cleared, using negative logic).
This will allow two modes in a single packet, but not two modes in a single
message.
And protocols can use the restrictions when needed or when CPU cycles are
saved.
What do you think?
Teco

> -----Oorspronkelijk bericht-----
> Van: Thomas Clausen [mailto:[email-masked]]
> Verzonden: woensdag 7 november 2007 20:41
> Aan: Stan Ratliff (sratliff)
> CC: manet
> Onderwerp: Re: [manet] draft-ietf-manet-packetbb - WGLC
> 
> Ian,
>

---

From: Russ White <[email-masked]>
Date: Wed, 07 Nov 2007 16:04:56 -0500

> MUST to MAY have been insufficient, and that the consequences of doing
> so have not been fully considered by the proponents of this change.
> 
> limiting the applicability within the intended problem domain of MANET
> protocols, and that therefore -- given the benefits which have been
> presented elsewhere -- it is timely to move forward with this I-D
> towards publication.

I would suggest that if the packet ordering constraints are left as they
are, many protocols will find them to be so restrictive, and so
unuseful, as to make packetbb unuseful. That would defeat the entire
purpose of creating a standard in this area, IMHO.

Alternate suggestions have been aired on the list, and roundly ignored.
For instance, the packet format could have an indicator in the header
indicating if the TLVs are "in order" or not. Or, the TLV space could be
divided in half, so that each TLV actually has two TLV numbers, one of
which must be used in order, the other of which does not. Or, the packet
could be divided through the use of TLVs so some part of the packet is
in order, and the remainder is not. Some protocols could place all their
TLVs in the "in order" section, some could place all their TLVs in the
"out of order" section, and other protocols could place some in each
section, as they see fit.

There are a lot of creative solutions lying around here. I don't
understand why none of them have been considered before the draft got to
the last call point, nor do I understand how the draft got to last call
with this large of an issue outstanding.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 7 Nov 2007 17:47:51 -0500

> From: Russ White [mailto:[email-masked]] 
> Sent: Wednesday, November 07, 2007 4:05 PM
> To: Thomas Clausen
> Cc: manet; Stan Ratliff (sratliff)

...

> I would suggest that if the packet ordering constraints are 
> left as they are, many protocols will find them to be so 
> restrictive, and so unuseful, as to make packetbb unuseful. 
> That would defeat the entire purpose of creating a standard 
> in this area, IMHO.

...

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. 

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.

Justin

---

From: Russ White <[email-masked]>
Date: Wed, 07 Nov 2007 18:57:16 -0500

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

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

> list of values in one value field which can be used however the protocol

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.

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.

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.

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.

Russ

- --

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 07 Nov 2007 16:11:51 -0800

Hello Ian,

Clearly, I disagree with Thomas.  I believe that packetBB must be
considered as applicable to not only current specifications, but also
specifications that may be important for future work in [manet].
Sufficient objections have been raised to indicate that the
mandates should be softened. This can be done in a way
that would not represent any significant delay to the progress
of the document, once agreement in principle is obtained on
the wisdom of relaxing the mandate.

Regards,
Charlie P.

ext Thomas Clausen wrote:
> --Thomas Clausen

---

From: Russ White <[email-masked]>
Date: Wed, 07 Nov 2007 20:51:42 -0500

> the wisdom of relaxing the mandate.

I completely agree with this, and would like to see a "mailing list hum"
on this.... There appears to be a very small group of people involved in
the discussion, but I'm getting some off list email supporting this
position. I'd like to see what the real concensus looks like, and not
just a small group of folks discussing it.

:-)

Russ

- --

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 9 Nov 2007 17:13:45 +0100

Hi,

Here some remarks made during reviewing. All are not that important.

Page 4: typo "praocessing"

Page 7: I don't like the text "may travel over a single logical hop which
might consist of one or more IP hops". Text could be removed from this
document.
   
Page 11: I think <msg-size> is always there, so "?" should be removed.

Page 13: I did not verify the compact address blocks before. I would have
used bit-strings for head, mid and tail instead of octet-strings. 
When using octets, <head-length> and <tail-length> could be packed into one
octet. For header or for tail, two bits needed for IPv4, 4 bits for IPv6.
Spending one octet would be enough.

Page 16: I would use name thaslengthext for tisextended. Now we have
extended type and extended length, which is confusing. For tnovalue, I would
have used tnolength.

Page 16: Why can't we have <index-start> not included and <index-stop>
included? I would prefer the bits tnostartindex and tnostopindex. We have 2
bits for 4 options.

Page 37, 38 and 40: I think a message without <msg-hop-count> and with
<msg-hop-limit> is invalid. As such, invalid messages are depicted.

Just for the record:
I posted some issues before, related to native transport over IP
1) 5.1; content variable pkt-size is not clearly defined when no packet size
information from transport layer and no <pkt-header>.
2) 5.1; <pkt-header> misses checksum field, to be used when integrity check
cannot be guaranteed from lower layers.
3) On type allocation, I think range 128-255 is for experimental and not
private/local.
4) Type allocation is on type, not on full type. This requires maintaining a
large set of type-extension registries.

Last one: 
I think there is no rough consensus on the restrictions issue. I don't have
a strong opinion, but I think it is needed that we have a document
explaining why we have those restrictions and how packetbb encoding is used
most efficiently.

Teco.

> Van: Ian Chakeres [mailto:[email-masked]]
> Verzonden: woensdag 7 november 2007 18:49
> Aan: manet
> CC: Christopher Dearlove; Cedric Adjih; Thomas Heide Clausen (work)
> Onderwerp: [manet] draft-ietf-manet-packetbb - WGLC
>

---

From: Philip Levis <[email-masked]>
Date: Sat, 10 Nov 2007 19:16:01 +1000

On Nov 8, 2007, at 11:51 AM, Russ White wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

The problem seems to be that neither case is grounded in fact. "It  
will lead to more complex parser code" and "no it won't" are  
hypothetical arguments. The fact that not every possible packet can  
be encoded with ordering isn't a show-stopper; if a format can do  
everything, chances are it can't do anything well. Let's not get  
trapped in the rathole of software engineering generalization, and  
instead follow Butler Lampson's advice.

Unless we elevate the discussion, this debate will continue to be a  
circular one. How about this: the pro-order folks should write the  
meanest, leanest parser they can and the pro-reorder folks should do  
the same. If it turns out that the no-order parser is 15 times as  
long and has numerous bugs, then we'll know what the answer is. But  
if it's only twice the size and is no more bug-prone, that seems like  
a good tradeoff for flexibility. And if one side doesn't want to  
write a parser, then maybe they shouldn't tell the other side how to  
write their code...

Phil

---

From: Russ White <[email-masked]>
Date: Sun, 11 Nov 2007 18:03:54 -0500

> meanest, leanest parser they can and the pro-reorder folks should do the
> same. If it turns out that the no-order parser is 15 times as long and
> has numerous bugs, then we'll know what the answer is. But if it's only
> twice the size and is no more bug-prone, that seems like a good tradeoff
> for flexibility. And if one side doesn't want to write a parser, then
> maybe they shouldn't tell the other side how to write their code...

How about this--we come up with a packet format that allows either in
order or out of order information transport. If a specific protocol only
wants to use in order encoding, then they can do so. If another protocol
only wants to use out of order encoding, then they can do so.

If, in the future, someone comes up with a way to make either encoding
mechanism 1 million times more efficient than the other, then the
protocol can support it.

It makes no sense to set something like this in stone for a packet
format designed to support many protocols over a lot of years--for the
foreseeable future, in fact. All a "contest" would show is that for
today, these two methods either break even, or one beats the other by
some small amount, using current languages, and current development
strategies, for current processor technology. Since we've no idea what
sort of languages, development strategies, and hardware might be used in
the future, the results would be trapped in a time bubble. In other
words, the results of such a "contest" would be, effectively, useless.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Sun, 11 Nov 2007 18:12:24 -0500

> The problem seems to be that neither case is grounded in fact. "It will
> lead to more complex parser code" and "no it won't" are hypothetical
> arguments. The fact that not every possible packet can be encoded with
> ordering isn't a show-stopper; if a format can do everything, chances
> are it can't do anything well. Let's not get trapped in the rathole of
> software engineering generalization, and instead follow Butler Lampson's
> advice.

BTW, if everyone who supports in order encoding only is _so_ certain
it's the only correct way to do things, then why does it hurt to offer
other options? If you're correct, and in-order encoding _always_ saves
so much in code and efficiency that it would be insane to do it any
other way, then the parts of the standard supporting out of order
encoding will be a dead letter anyway.

What's the harm in allowing the option, if you think the advantages are
so clear cut one way that no-one will ever use anything else?

I'll go back and suggest what I suggested in the first place--it's
perfectly fine to have sections of the packet which must be processed
before other sections of the packet. It's perfect fine to have sections
of the packet where TLVs must be in order. It's also perfectly fine to
have sections of the packet where the TLVs can be in any order, or where
the processing results do not depend on the order.

Generally speaking, atomic operations are to be desired. They aren't
always possible, but they are to be desired. The way the draft is
currently written, there's no such thing as an "atomic operation."

:-)

Russ

- --

---

From: Philip Levis <[email-masked]>
Date: Sun, 11 Nov 2007 19:50:56 -0800

> words, the results of such a "contest" would be, effectively, useless.

On one hand, I agree with you; I think flexibility is really  
important, and the restriction limits flexibility. On the other, the  
folks advocating it are those who wrote the document and have  
implemented parsers for it, and it's important we don't ignore the  
conclusions they've reached from that experience.

To be fair, I don't think they've really articulated the case that  
well, but it's clear they strongly believe the restriction is a good  
thing. And so if we really think that's not true, and care about the  
draft, then we should run an experiment to test the hypothesis  
(implement a parser), which will hopefully refute or validate the claim.

Phil

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 12 Nov 2007 09:44:28 +0100

Review on review;-)
Apology for any misconception.
Teco.

> Spending one octet would be enough.
Claim is false, length in octets is range 0 to 4 (v4), requiring 3 bits or 0
to 16 (v6) requiring 5 bits. Two times 5 bits does not fit in one octet.

> <msg-hop-limit> is invalid. As such, invalid messages are depicted.
Comment is correct or incorrect, depending on what forwarding rules are
mandated.

When text is included that <msg-hop-limit> MUST be decremented when
forwarding, and message MUST NOT be forwarded when reaching zero, the
examples are valid. 
I overlooked this option, as I was searching in the draft and found nothing
like that. 
Proposed text (out of IPv6 - RFC2460):
   Hop Limit            8-bit unsigned integer.  Decremented by 1 by
                        each node that forwards the packet. The packet
                        is discarded if Hop Limit is decremented to
                        zero.