Subject: Re: [manet] A view on packet-BB

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 1 May 2012 23:01:15 +0100

Hi

>Also, to be clear, we can standardize AODVv2 *with* packet-BB
>right now, and submit for consideration another document for
>AODVv2 that does not require packet-BB.  Or, we can enable both
>ways in the next revision.  Or, we can standardize AODVv2
>that does NOT use packet-BB, and then submit for consideration
>another document that DOES use packet-BB.  All cases are just
>fine with me, depending on what the working group wants.
I support/prefer the option:  AODVv2 without packet-bb first then, to
submit consideration
another document that uses packet-BB, with different name. To make things
simple and leaving
messaging issues in the end, the functionality is more important.

Abdussalam Baryun
University of Glamorgan,UK

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Hello folks,

I have not participated very much in any discussions about
packet-BB other than to encourage header size reduction and
offer a few suggestions about how to achieve it.  During that
time, it was claimed that for many networks of interest, the
use of packet-BB would *decrease* header size, perhaps
especially for proactive protocols.  This is a question
very suitable for resolution by way of simulation.

If, as I suspect, packet-BB does (on average) introduce
header enlargement on some networks that cannot afford it,
I would be in favor to introduce the option to run AODV
(or OLSR, for that matter) with some sort of "reduced"
header.  This should only be deployed in networks where
otherwise there would be no feasible deployment of an
ad-hoc networking protocol.  From that perspective, it's
almost a no brainer -- either deploy the standard stripped-
down version, or deploy something else nonstandard that
looks exactly like the stripped-down version.

In summary, if there are cases where the [manet] protocols
can only be deployed without packet-BB header overhead,
then I think we should provide a solution for those cases.

To be clear, I am happy either way, whether or not packet-BB
headers are mandates in all cases.

Also, to be clear, we can standardize AODVv2 *with* packet-BB
right now, and submit for consideration another document for
AODVv2 that does not require packet-BB.  Or, we can enable both
ways in the next revision.  Or, we can standardize AODVv2
that does NOT use packet-BB, and then submit for consideration
another document that DOES use packet-BB.  All cases are just
fine with me, depending on what the working group wants.

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 May 2012 08:50:47 +0000

The constraints here are first that RFC 5498 mandates use of RFC 5444 (formerly packetbb) for protocols using the manet UDP port or manet IP protocol. If anything not using RFC 5444 were to do so that would cause interoperability issues.

But of course AODVv2 could use another port, for example AODV's port (except there could be compatibility problems there, but that's not something I've considered). That comes up against a second issue, that the rough consensus in the WG was that all Standards Track protocols developed in the WG would use RFC 5498/5444. Of course could change - unlike RFCs that can't be overturned that way - but it hasn't been yet.

--
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: [email-masked] [mailto:[email-masked]] On Behalf Of Abdussalam Baryun
Sent: 01 May 2012 23:01
To: [email-masked]
Cc: manet
Subject: Re: [manet] A view on packet-BB

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.

Hi

>fine with me, depending on what the working group wants.
I support/prefer the option:  AODVv2 without packet-bb first then, to submit consideration
another document that uses packet-BB, with different name. To make things simple and leaving
messaging issues in the end, the functionality is more important.

Abdussalam Baryun

Regards,
Charlie P.

********************************************************************
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: Abdussalam Baryun <[email-masked]>
Date: Wed, 2 May 2012 13:48:15 +0200

On 5/2/12, Dearlove, Christopher (UK) <[email-masked]> wrote:
> The constraints here are first that RFC 5498 mandates use of RFC 5444
> (formerly packetbb) for protocols using the manet UDP port or manet IP
> protocol. If anything not using RFC 5444 were to do so that would cause
> interoperability issues.

Yes, 5498 is for a specific port not for all and not in general, even
though the word general is mentioned in packet-bb 5444, which I think
it is not general format because it specifies some rules that try to
cover all aspects.

>
> But of course AODVv2 could use another port, for example AODV's port (except
> there could be compatibility problems there, but that's not something I've
> considered). That comes up against a second issue, that the rough consensus
> in the WG was that all Standards Track protocols developed in the WG would
> use RFC 5498/5444. Of course could change - unlike RFCs that can't be
> overturned that way - but it hasn't been yet.
>

Yes, I suggested AODVv2 uses another port, and every protocol that
does not use 5444. The issue is if any protocol does not use 5444 it
MUST have different port than the RFC5498, but we don't say all MANET
use 5444 and then it must use that port of RFC5498. The reason why is
because the 5444 does not state that all MANET routing protocols
SHOULD use packet-bb, if it does state that then we have to update
5498 to include all ports that do cover all MANET routings including
AODV.

First, the best development and testing approach in the experimental
wroking in progress stage, that we focus on the protocol's ideas first
and then think if they may join a format, a method, a standard, etc.
Secondly, is to update this general format 5444 to match really all
protocols in their interest as was clarified by the first poster of
the topic. Thirdly update RFC5498 as well. But another complicated
approach is going in the other direction, to start adjusting protocol
ideas to adapt to the message format and port assigned by 5444/5498,
then testing functionality, or testing twice with and without. This
may limit some of the design-protocol-functionality which should be
carefully considered if this second direction approach was choosen.

Abdussalam Baryun
University of Glamorgan, UK
++++++++++++++++++++++
> Please see this
> process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>
> on how to deal with suspicious emails.
>
> Hi
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 May 2012 12:28:19 +0000

You refer to the experimental stage. But the reactive protocol that the MANET WG is supposed to be working on is meant to be Standards Track, not Experimental. AODV (v1) and DSR were supposed to be the experimental stage.

Updating 5444 and 5498 is really not what we need to do.

[email-masked] | http://www.baesystems.com

-----Original Message-----
From: Abdussalam Baryun [mailto:[email-masked]] 
Sent: 02 May 2012 12:48
To: Dearlove, Christopher (UK)
Cc: [email-masked]; manet
Subject: Re: [manet] A view on packet-BB

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Abdussalam Baryun

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 2 May 2012 18:23:08 +0200

Hi Chris,

thanks for your explanation, I missed to understand different
standards tracks. But do you think it is a good idea to make all
routing protocols use packet-bb, and do we got some results that it is
suitable for all reactive, proactive and hybrid. I have results of
OLSRv2 as the proactive but no reactive using it nor hybrid or i am
wrong,

I hope that also protocols that don't use 5444 mention why they don't
so we can know,

Thanks
Abdussalam
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On 5/2/12, Dearlove, Christopher (UK) <[email-masked]> wrote:
> You refer to the experimental stage. But the reactive protocol that the
> MANET WG is supposed to be working on is meant to be Standards Track, not
> Experimental. AODV (v1) and DSR were supposed to be the experimental stage.
>
>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
>> Centre,
>> Farnborough, Hants, GU14 6YU, UK
>> submit
>> consideration

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 May 2012 08:40:14 +0000

Is it a good idea for all current MANET WG protocols to use 5444? I think so, because there are some clear gains, especially in flexibility for future expansion. Is it the best idea? That's still a matter for discussion.

I don't think it would be appropriate for a final RFC of any protocol not using 5444 to say why not. It would be necessary in discussion before that. It could be mentioned in earlier versions of the ID.

-----Original Message-----
From: Abdussalam Baryun [mailto:[email-masked]] 
Sent: 02 May 2012 17:23
To: Dearlove, Christopher (UK)
Cc: [email-masked]; manet
Subject: Re: [manet] A view on packet-BB

Hi Chris,

Thanks
Abdussalam

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 4 May 2012 12:00:43 +0200

Hi Chris,

The packet of RFC 5444 do I call it RFC5444-Packet, or which name do
you use/prefer, is it Packet-BB, MANET-Packet, General-MANET-Packet?
and Is it specified the name for the packet in RFC5444 or other RFC,
to distiguish with other packets of other IETF groups?

Thanking you,

Abdussalam Baryun
+++++++++++++++++++++++

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 29 May 2012 15:07:46 +0200

I have another thought for AODVv2 and RFC5444 (some call it
packet-bb). I think it is possible to change hop-count-distance to
metric-type in AODVv2, and to add metric-type in the RFC5444 (modified
format) if you think it is better for the protocol, this is a way that
makes AODVv2 more different than LOADng. Having in mind not to worry
about using any RFC now, because any update to a RFC or draft is
possible but as long as it is convensing and discussed on the list.

> to be clear, we can standardize AODVv2 *with* packet-BB

In MANET reactive protocols may be good idea to have DYMO without
5444-format (special formats for DYMO), and AODVv2 with using
modified-5444-format (as below suggestion of adding metric-type), and
LOADng fully using RFC5444. So we may join LOADng in MANET.

Abdussalam Baryun

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subject: [manet] A view on packet-BB
From: "Charles E. Perkins" <charliep at computer.org>
Date: Thu, 29 Mar 2012 07:31:06 -0700
> fine with me, depending on what the working group wants.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Subject: Re: [manet] OLSRv2: which node defines link metric
From: "Charles E. Perkins" <charliep at computer.org>
Date: Mon, 28 Nov 2011 15:28:17 -0800

Hello folks,

I'd given up on the link metric discussion a long time
ago, and maybe some things have changed that escaped
my notice.  I had argued for the inclusion of a "type"
field for the metric -- e.g., "delay", "cost", "ETX",
"least occupancy", "throughput", bit-error rate, ...
This would not be a short list of types, but it would
be manageable.

Without knowing the type, it is possible to have some
seriously bad effects.  For instance, suppose there are
three metrics of interest, and three disjoint paths
between source and destination.  If each node advertises
whatever metric value it chooses, without coordination
or type, it is possible for the source to always pick
the _worst_ path for any of the three metrics.  The
degree of "worstness" can be arbitrarily large.  I'm
certain this can be extended to always picking the
_worst_ path for any of N possible metrics, and also
to many different topologies -- not just disjoint
paths.  I am not sure if the topology can be
completely arbitrary, or how to characterize the
methods by which node advertisements can produce
this terrible behavior.  It's no doubt an interesting
research problem.

I was assured in several conversations that this was
not an issue and that including a type for the metric
was a non-starter.  At that point, I really had to
surrender.  At least the metrics as defined do not
lead to routing loops.

If this has been solved, please send me a URL for
the document so I can read about it, and accept my
apology for the distraction.

Regards,
Charlie P.
++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 30 May 2012 12:12:02 -0700

Hello folks,

I think it's a good idea to enable alternate metrics in AODVv2/DYMO
and for LOADng for that matter.  In fact, LOADng already has a form of
alternate metric.

> possible but as long as it is convensing and discussed on the list.

Check.

> LOADng fully using RFC5444. So we may join LOADng in MANET.

I understand this point.  However, I have always believed that AODV is also
applicable for LLNs and sensor networks.  Previous work to focus AODV for
better performance in specific networks has produced quite interesting and
good results.  It would have been very appropriate to bring these 
modifications
into the [manet] WG for adoption into the evolved WG documents.  Making
an oversimplification, it seems that the areas where DYMO/AODV have been
viewed as inadequate for networks with reduced-functionality nodes are
mostly as follows:
1. protocol complexity
2. packet size
3. neighborhood detection

1) is clearly an area where discussion in [manet] should have happened,
      and is happening now thanks to LOADng development
2) is a problem sometimes difficult to solve in the IETF
3) was mostly resolved by specifically enabling DYMO/AODVv2 to use
      any appropriate neighborhood detection algorithm.  In fact, this was
      always possible even with AODV, but somehow the HELLO messages
      were viewed as a central part of AODV even after the publication of
      SMURF and other related efforts.

In particular I would not be happy to see any divergence between a protocol
named "DYMO" and a protocol named "AODVv2".

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 31 May 2012 07:24:05 +0200

On 05/30/2012 09:12 PM, Charles E. Perkins wrote:
> applicable for LLNs and sensor networks.

I agree, the difference between "LLNs" and "MANETs" is mostly one of the 
focus of optimization. Depending on the traffic pattern and timing 
settings, AODV should work well for LLNs.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 31 May 2012 12:30:02 +0100

Hi Charlie, and All

I don't mind to have DYMO and AODVv2 without divergence, just from the
protocol name and draft-understanding, DYMO was derived from AODV+DSR, and
from the change of name to AODVv2 it made me think more about the extending
of AODV. Therefore, I may suggest that it is interested to see DSRv2 (
which I thought new DYMO may take that direction), and was thinking if the
authors of DSR or others in WG are happy to extend that protocol.

If we can get a new DSRv2 that is able to use RFC5444 or use a modified
format of RFC5444, it will be great. Because if OLSRv2-15 is now deleting
its source-routing option as was included in OLSRv2-14, and AODVv2 is not
doing source routing, then it is interested to have a routing protocol that
is able to source route.

Abdussalam Baryun,
University of Glamorgan, UK.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: Henning Rogge <[email-masked]>
Date: Thu, 31 May 2012 13:38:14 +0200

On 05/31/2012 01:30 PM, Abdussalam Baryun wrote:
> Hi Charlie, and All
>
> I don't mind to have DYMO and AODVv2 without divergence, just from
> the protocol name and draft-understanding, DYMO was derived from
> AODV+DSR, and from the change of name to AODVv2 it made me think more
> about the extending of AODV. Therefore, I may suggest that it is
> interested to see DSRv2 ( which I thought new DYMO may take that
> direction), and was thinking if the authors of DSR or others in WG
> are happy to extend that protocol.
 >
> If we can get a new DSRv2 that is able to use RFC5444
> or use a modified format of RFC5444,
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I would consider this a reason the not accept a protocol.

> it will be great. Because if OLSRv2-15 is now deleting its
> source-routing option as was included in OLSRv2-14,

Not sure why it was ever there, because the mechanism to use source
routing with OLSR was never described in the draft. Feel free to write
an extension draft OLSRv2-with-sourcerouting

> and AODVv2 is not doing source routing, then it is interested to have
> a routing protocol that is able to source route.

Can you state a reason why you think that source routing is interesting 
for you? I know it makes a lot of trouble, but whats the advantage if 
every OLSR node (as an example) has to store the whole topology anyways?

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 31 May 2012 12:18:20 +0000

I agree with Henning, including on his emphasised point.

With regard to the source routing paragraph in OLSRv2, it appeared for about one draft, because someone (I don't recall who) said (roughly) "you've got the information to do source routing, why not mention that", and so it was added in the non-normative part. (Note that it was never in the normative part.) Then a draft or so later it was taken out because actually no one ordered that, and because it's not quite that simple, you can't source route to attached networks, only to their gateways. The idea of having to explain an exception to a mechanism that no one wanted and wasn't normative seemed like a very bad idea.

"Interesting" is not enough. I could write a long list of interesting things. What we should be doing in an IETF WG is something people want (or even need). We also don't want more protocols, we dropped from four experimental protocols to two standards track deliberately. Roughly speaking OLSR and AODV won over DSR and TBRPF for a variety of reasons, but DSR's source routing was a strike against it, not for it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 31 May 2012 12:38
To: [email-masked]
Subject: Re: [manet] A view on packet-BB

Henning Rogge

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 31 May 2012 08:47:00 -0700

Hello Abdussalam,

DYMO was exactly designed as "AODVv2" and "DSRv2".  The source routing 
feature
of DSR was renamed to be "Path Accumulation".  We did a lot of testing 
and discovered
that path accumulation was strangely unhelpful for improving 
performance.  There
may be circumstances for which accumulating a source route is 
advantageous for
routing, but they haven't been clearly articulated to my knowledge.  On 
the other
hand, accumulating a source route does present advantages for security.

After a too-long hiatus in progress with DYMO, I had found that AODV had a
lot better name recognition and I thought, with some encouragement from 
other
people, that since path accumulation was no longer mandated, there was much
to be gained by reverting to the better-recognized name of AODV, but 
with the
clear intention of aligning the protocol with recent experience.

The value of having one standard reactive protocol instead of two
experimental ones is, in part, to make it easier for customers to know
which protocol to use.   This is still a good idea, regardless of various
specializations that have occurred.

Regards,
Charlie P.

On 5/31/2012 4:30 AM, Abdussalam Baryun wrote:
> protocol name and draft-understanding, DYMO was derived from AODV+DSR, 
> and from the change of name to AODVv2 it made me think more about the 
> extending of AODV. Therefore, I may suggest that it is interested to 
> see DSRv2 ( which I thought new DYMO may take that direction), and was 
> thinking if the authors of DSR or others in WG are happy to extend 
> that protocol.
> If we can get a new DSRv2 that is able to use RFC5444 or use a 
> modified format of RFC5444, it will be great. Because if OLSRv2-15 is 
> now deleting its source-routing option as was included in OLSRv2-14, 
> and AODVv2 is not doing source routing, then it is interested to 
> have a routing protocol that is able to source route.
> Abdussalam Baryun,
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Hello folks,
>

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 31 May 2012 18:11:49 +0200

Hello Chalie,

I agree with you regarding DYMO and AODVv2. Also thank you for your
comments, it will help us in the group's progress testing.

Best regards

Abdussalam Baryun
University of Glamorgan, UK.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: Don Sturek <[email-masked]>
Date: Thu, 31 May 2012 09:29:14 -0700

Hi Charlie,

I think updating AODV would be a great idea.   We have some experience with
AODV in a commercial deployment.  Here are some enhancements to consider:
1)  Neighbor table management supported by exchanging one hop messages
containing LQI between one hop neighbors.  This would be nicely supported
via Packet BB.
2)  Pruning of neighbor table entries to ensure two way communication
(allows for use of forward routing path as the return routing path)
3)  Multicast route replies from data sink devices (many to one feature)
4)  Optimization of route tables to reduce size (have a look at AODV Jr in
SourceForge)

Overall, AODV has many benefits that would be useful as an enhanced RFC.

Don

From:  "Charles E. Perkins" <[email-masked]>
Organization:  Saratoga Blue Skies
Date:  Thursday, May 31, 2012 8:47 AM
To:  Abdussalam Baryun <[email-masked]>
Cc:  manet <[email-masked]>
Subject:  Re: [manet] A view on packet-BB

 Hello Abdussalam,
 
 DYMO was exactly designed as "AODVv2" and "DSRv2".  The source routing
feature
 of DSR was renamed to be "Path Accumulation".  We did a lot of testing and
discovered
 that path accumulation was strangely unhelpful for improving performance.
There
 may be circumstances for which accumulating a source route is advantageous
for
 routing, but they haven't been clearly articulated to my knowledge.  On the
other
 hand, accumulating a source route does present advantages for security.
 
 to be gained by reverting to the better-recognized name of AODV, but with
the

 Regards,
 Charlie P.

 
 On 5/31/2012 4:30 AM, Abdussalam Baryun wrote:
> from the change of name to AODVv2 it made me think more about the extending of
> AODV. Therefore, I may suggest that it is interested to see DSRv2 ( which I
> thought new DYMO may take that direction), and was thinking if the authors of
> DSR or others in WG are happy to extend that protocol.
>  
>  
>  
> If we can get a new DSRv2 that is able to use RFC5444 or use a modified format
> of RFC5444, it will be great. Because if OLSRv2-15 is now deleting its
> source-routing option as was included in OLSRv2-14, and AODVv2 is not doing
> source routing, then it is interested to have a routing protocol that is able
> to source route.
>  
>  
>  
> Abdussalam Baryun,
>  
> On Wed, May 30, 2012 at 8:12 PM, Charles E. Perkins <[email-masked]>
> wrote:
>  
>> 
>>  Hello folks,
>>  

-- 
Regards,
Charlie P.
 
_______________________________________________ manet mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/manet