RE: manet Digest, Vol 40, Issue 37

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet

RE: Distance Maximum Size 8-bits or 16-bits?

I thought about using 8-bit exponential link metrics combined with a 8-bit
distance, used as exponential path metric. I used the (16+a)*2^b-15 format,
as I still highly prefer this one for being used by OLSR.

I performed all possible calculations and checked the outcome. I used the
following algorithm:
 1) Uncompress IncomingDistance
 2) Add (linear) link metric 
 2) Compress outcome into exponential path metric
 4) The AdvertizedDistance is maximum of:
    - IncomingDistance + 1
    - CalculatedDistance (step 3)
Although is seems to work, there are some problems.

One problem is the decreased number of hops supported. This problem occurs
when nodes use increments larger than one, which is allowed in the current
DYMO draft text also.
Supporting 255 hops, each with a link metric of 254, the linear path metric
is 250.671.375, using (16+a)*2^b-15 the value 381 is needed. So an
exponential 9-bit distance would handle this, using a 5-bit exponent.
Many hops with such a high link metric would not be needed, but what about 2
links with metric 557.041 (exponential value: 241)? Or one link with metric
557.041 and 15 high speed links?

Another problem is defining the in- or outbound interface link metric. When
not specified, one implementation would select inbound, another
implementation selects outbound. In the same MANET, one direction would have
a double counted high metric link; the opposite direction does not use the
metric for this link at all. 
We have a similar discussion on OLSR inbound or outbound interface metrics
for path calculation.

And another problem is the loss of accuracy. When in the path a high metric
link is present, path calculation before this link is accurate, after
passing the link it is not. In the opposite direction, loss of accuracy is
on the other part of the path. 

                +----+       321      +----+ 
                | R1 |----------------| R4 |
                +----+                +----+    
                /  |                    | \
              1/   |                    |  \1
              /    |                    |   \
           +----+  |                    |  +----+
           | R2 |  |11                11|  | R5 |
           +----+  |                    |  +----+
               \   |                    |   /
               1\  |                    |  /1
                 \ |                    | /
                +----+                +----+
                | R3 |                | R6 |
                +----+                +----+

In this example, the path from R3 to R6 is R3-R2-R1-R4-R6. Opposite
direction is R6-R5-R4-R1-R3. Note that the WPF path is chosen after the high
metric link. Link state protocols would select the best path:
R3-R2-R1-R4-R5-R6. 
In practice, the effect of the problem would not be that annoying, as the
metric is to be used to select a path around the "real bad link" in the
first place. But IMHO it is a bad behavior of the protocol and it needs to
be solved.

Teco.

> -----Original Message-----
> From: Ian Chakeres [mailto:ian.chakeres <at> gmail.com]
> Sent: vrijdag 17 augustus 2007 19:20
> To: manet
> Subject: [manet] Distance Maximum Size 8-bits or 16-bits?
> 
> I wanted to ask everyone if they have an opinion about the maximum
> distance size in DYMO.
> 
> Do you think 8-bits are sufficient (i.e. 256 values)? Or are 16-bits
> required?
> 
> Please let me know your opinion. In the absence of responses I will
> assume 8-bits are enough.
> Ian Chakeres
> 
> 
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/manet

Request to publish draft-ietf-manet-jitter-02.txt - write-up included

I would like to request that draft-ietf-manet-jitter-02.txt be
published. I am the shepherding WG chair.
Ian Chakeres

===WRITE-UP===

   1. Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready to
forward to the IESG for publication?

YES.

   2. Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

YES the ID has been reviewed. NO there is no concern about the reviews.

   3. Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

NO.

   4. Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document, or
have concerns whether there really is a need for it. In any event, if
your issues have been discussed in the WG and the WG has indicated it
that it still wishes to advance the document, detail those concerns in
the write-up.

NO.

   5. How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

STRONG - Several other WG documents contain references to this ID.

   6. Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email to the Responsible Area Director.

NO.

   7. Have the chairs verified that the document adheres to all of the
ID Checklist items ?

YES.

   8. Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not also
ready for advancement or are otherwise in an unclear state? (note here
that the RFC editor will not publish an RFC with normative references
to IDs, it will delay publication until all such IDs are also ready
for publication as RFCs.)

YES.

   9. What is the intended status of the document? (e.g., Proposed
Standard, Informational?)

Informational.

  10. For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following sections:

          * Technical Summary

This document provides recommendations for jittering (randomly
modifying timing) of control traffic transmissions in MANET routing
protocols to reduce the probability of packet collisions.

          * Working Group Summary

This document contains information that was originally in OLSRv2. It
was pulled out and put in its own document, since it is applicable to
many MANET WG protocols (e.g. NHDP, OLSRv2, and DYMO) to avoid
collisions.

          * Protocol Quality

There are a number of IETF documents/protocols that discuss introduced
jitter; these documents are cited. Though jitter is discussed in these
documents, in the context of MANET jitter should be handled in a
slightly different manner. This document goes into more details about
how jitter should be employed in MANETs.

RE: Distance Maximum Size 8-bits or 16-bits?

From: Teco Boot [mailto:teco <at> inf-net.nl] 
> Another problem is defining the in- or outbound interface link metric.
When
> not specified, one implementation would select inbound, another
> implementation selects outbound. In the same MANET, one direction
would have
> a double counted high metric link; the opposite direction does not use
the
> metric for this link at all.
> 
> We have a similar discussion on OLSR inbound or outbound interface
metrics
> for path calculation.

No to the latter point (I don't know about DYMO). The whole
rationale for having directional link metrics in the first
place (in draft-dearlove-olsrv2-metrics-00) is that which
direction link metric must be (and in that document is)
specified.

Of course you may end up selecting different paths A to B
and B to A, but that can and does happen with minimum hop
paths 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.
********************************************************************

helping

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet

CfP MP2P'08: 5th IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'08)

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet

Nomcom 2007-8: Nominations Close on Sep 10, 2007

---------- Forwarded message ----------
From: Lakshminath Dondeti <ldondeti <at> qualcomm.com>

All,

Here is the link to nominate:
https://tools.ietf.org/group/nomcom/07/nominate

You may also send nominations or comments via email to nomcom07 <at> ietf.org
or ldondeti <at> qualcomm.com.

We have received very few nominations (1, 2, 2, 2, 3, 4, 8, 8, 19) and
even fewer accepted (1-2 people in each area, IAB acceptances is 4 at
last count).

I request the community to provide feedback on the incumbents (send
email or send notes via the web page).

1) If you think that the incumbent is doing a good job
     a) provide feedback AND
     b) nominate similar people just in case there is strong negative
feedback on the incumbent

2) If you think the incumbent can do somethings better
    a) provide feedback AND
    b) nominate someone who you think might do better

Candidates, if time commitment is the only issue, please indicate that
to the nomcom and accept the nominations.

thanks,
Lakshminath

I-D ACTION:draft-ietf-manet-packetbb-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Generalized MANET Packet/Message Format
	Author(s)	: T. Clausen, et al.
	Filename	: draft-ietf-manet-packetbb-09.txt
	Pages		: 49
	Date		: 2007-9-10
	
This document specifies a multi-message packet format that may be
   used by mobile ad hoc network routing and other protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-09.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-manet-packetbb-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-packetbb-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

Comments on PacketBB Draft

Hi all,

The following are a few comments on Packet BB.  These are from draft
8, but looking at a diff against version 9, none of these comments
were effected by the changes.

I preface by saying that I have read much of the ongoing discussions
on ordering & bit saving but have not necessarily seen all of the
arguments.

Thx

-------
[ Content ]

These comments all refer to page 16, Constraints.

It's not clear what the value is in some of the constraints given
here, at least just from reading this document.

The only value I can see from the ordering constraint is that a
receiver can easily pull all the TLVs into an array and provide
efficient random access to it.  But for a hash or other map
implementation, that doesn't matter.  You also still need to sort on
the sending end, as well as check on the receiving end.

Relying on the numeric values of the TLVs sounds like something that
will be regretted sooner or later.  It attaches too much meaning to a
number that should just be a unique identifier.  It seems reasonable
that some protocols will want to impose an ordering over their
elements, but that should be up to the protocol and doesn't require
this to do so.

Specifically allowing child protocols to allow or disallow duplicate
TLVs is a good thing.

I don't see the value in requiring a given TLV type to be associated
with an address exactly once.  For possible implementations that I'm
thinking of, it sounds like (slightly) more of a hassle to check that
if it's already been associated than to just go ahead and mark the
address.  Ditto requiring redundant TLVs to be index sorted.

My personal plan for a PacketBB API provides more of a declarative or
relational view than I think these constraints imply.  I'm thinking of
the main access mechanisms as being a query for all TLVs associated
with an address, for all addresses associated with a TLV, or direct
access access to the received packet structure (i.e.  to loop over
each message, address blocks in a message, etc).  None of these
requires the constraints imposed here, and they sound like more of a
hindrance because now care has to be chosen in picking identifiers,
data has to be asserted in order or sorted, etc.

[ Typographical Notes ]

pg 15: "For an address block... block, where the first address has
position zero." should perhaps be clarified a bit: "For an address
block... block, where the first address in the block is position
zero."
-------

--

-- 
- joe kopena
  shelter from the storm

RE: Comments on PacketBB Draft

Please see previous discussion in this group in
which the value of these constraints has been
summarised extensively.

-----Original Message-----
From: Joseph Kopena [mailto:tjkopena <at> cs.drexel.edu] 
Sent: 11 September 2007 17:28
To: manet <at> ietf.org
Subject: [manet] Comments on PacketBB Draft

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

Hi all,

The following are a few comments on Packet BB.  These are from draft
8, but looking at a diff against version 9, none of these comments
were effected by the changes.

I preface by saying that I have read much of the ongoing discussions
on ordering & bit saving but have not necessarily seen all of the
arguments.

Thx

-------
[ Content ]

These comments all refer to page 16, Constraints.

It's not clear what the value is in some of the constraints given
here, at least just from reading this document.

The only value I can see from the ordering constraint is that a
receiver can easily pull all the TLVs into an array and provide
efficient random access to it.  But for a hash or other map
implementation, that doesn't matter.  You also still need to sort on
the sending end, as well as check on the receiving end.

Relying on the numeric values of the TLVs sounds like something that
will be regretted sooner or later.  It attaches too much meaning to a
number that should just be a unique identifier.  It seems reasonable
that some protocols will want to impose an ordering over their
elements, but that should be up to the protocol and doesn't require
this to do so.

Specifically allowing child protocols to allow or disallow duplicate
TLVs is a good thing.

I don't see the value in requiring a given TLV type to be associated
with an address exactly once.  For possible implementations that I'm
thinking of, it sounds like (slightly) more of a hassle to check that
if it's already been associated than to just go ahead and mark the
address.  Ditto requiring redundant TLVs to be index sorted.

My personal plan for a PacketBB API provides more of a declarative or
relational view than I think these constraints imply.  I'm thinking of
the main access mechanisms as being a query for all TLVs associated
with an address, for all addresses associated with a TLV, or direct
access access to the received packet structure (i.e.  to loop over
each message, address blocks in a message, etc).  None of these
requires the constraints imposed here, and they sound like more of a
hindrance because now care has to be chosen in picking identifiers,
data has to be asserted in order or sorted, etc.

[ Typographical Notes ]

pg 15: "For an address block... block, where the first address has
position zero." should perhaps be clarified a bit: "For an address
block... block, where the first address in the block is position
zero."
-------

--

-- 
- joe kopena
  shelter from the storm

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www1.ietf.org/mailman/listinfo/manet

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