Subject: [manet] RE: Comments about draft-ietf-manet-packetbb-04

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Fri, 11 May 2007 09:49:48 +0100

Some comments on a few of Charlie's comments.

> When do we need to transmit a packet with zero messages?

If someone wants to send just a packet TLV. I don't have a
use for it right now, but it's trivial to permit and harmless.

> You can just say that type 0 (zero) is RESERVED.

No. RESERVED suggests it could be used sometime in the future.
Using type zero breaks the format - it leads to parsing
ambiguity. So we want to make it absolutely clear it is not
used, cannot be used, will never be used in the future,
MUST NOT be used.

> However, for the case of unaggregated
> IPv4 addresses, the overhead from the address block
> mechanism as given, is 50%.

If you are creating address blocks each with one address
in them. Why would you do that? If efficiency is your
goal, don't do that. Make one address block with a single
one-off 2 octet overhead for all addresses.

> Or, did I misinterpret, and <tlv-length> is intended
> to include the length of <value>?

<tlv-length> is the total length of all TLVs in the
block, not just a single TLV. That includes all types,
semantics, indices, lengths and values.

Each individual TLV has a semantics bit to indicate if
it has a 0, 8 or 16 bit value length. But there's no
point having a TLV block semantics octet as that costs
the octet you are trying to save.

> Packet headers and messages MAY be padded to ensure 32 bit alignment

Good catch. Thanks. Ditto in security considerations I think
(I haven't checked).

> It would be better to put into the OLSR document a part
> of the IANA considerations to reserve the four message
> types, and delete the discussion in the PacketBB document.

I don't agree.

With regard to the rest of Charlie's comments, they include some
changes to substance, rather than wording which could be done.
(But aren't the only things that could be done - some going in
the opposite direction.) I don't agree with them, not because
they have no merit but because I (and, recognising reality, the
company that pays me) have as highest priority getting this
published as soon as possible, and with minimal changes. I've
said before, there are tradeoffs here and we've made some. Are
they perfect? I'm not claiming that, but rather that "the best
is the enemy of the good" (which Googling tells me is Voltaire).
Although in many cases I'd argue against them being best too.

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

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 11 May 2007 09:06:26 -0700

Hello Chris,

> used, cannot be used, will never be used in the future,
RESERVED does not have the connotation you suggest.

It would probably be better to put this discussion in
the IANA considerations.  Presumably anyone familiar
enough with PacketBB to serve as an advisor for
future allocations would recognize the basic fact.
> one-off 2 octet overhead for all addresses.
A lot of ad hoc networks will be either partially or completely
populated by nodes with previously assigned addresses.
They get together, they work, they break apart.  Like
ad hoc networks do.

Your perspective seems to assume the existence of a
centralized address allocation agency, either online or
offline by preassignment.  That is very worrisome to me.

> the octet you are trying to save.
No, it does not have to be that way.  I think I already suggested
a way to do it without adding any more bytes...  But if need be
I can repeat it.

>> types, and delete the discussion in the PacketBB document.
Well, that doesn't seem to explain anything.  This document
should not have any normative dependencies on OLSR
whatsoever, and I don't really see any necessity for any
informative references either except for historians.
> Although in many cases I'd argue against them being best too.
I have been saying some of these things for many, many
months, both at IETFs and in e-mails.  The request has been
made for comments many times and I have finally responded
at some length, as a formal process step.  Your logic would
seem to validate the acceptance of almost anything.  I do not
claim that PacketBB is terrible, but this is the time to make
improvements.  The suggestions I have made for the substance
are, if you look objectively, quite minor indeed, but can offer
real performance improvements and real flexibility for future
protocol designers.   I reckon the changes could be made
in two weeks.

I doubt that Voltaire would disagree with my attempt to
make these suggestions.  Furthermore, the sense of that
quotation rather supports my argument.  The point of
the quote is exactly that when things are thought to be the
"best", there seems to be no opportunity for improvement.
How could one improve on the "best"?  We seem to be in
agreement that the document is not the "best" in absolute
terms, but your claim is that it is the "best" we can expect
in terms of some hypothetical time window for making it
available.

Oh how I wish we could have rammed through Mobile IPv6
with the same logic offered in the your quoted paragraph.
In that case, the suggestions were not even remotely targeted
towards performance improvements, sigh...

Regards,
Charlie P.