Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"

["Peter S Lau (peterlau)" <[e-mail]>]

Dear all:

Thank you for the comments. I am going to respond to some comments and
leave the others at a later time.

Thanks,

Peter Lau



1. Response to the comment "there thus may or may not be a space for a
lightweight proactive protocol" made by Christopher.

1.a TRP is intended for nearby social network where people are moving
around with smartphones (installed with TRP) discover and communicate
with each other on the fly when they move into the vicinity of each
other. I believe OLSR/OLSv2 and others were not conceived to support such
an application. I list three requirements that may justify a space for a
lightweight protocol, like TRP.

1.b Delay is very important in highly interactive applications, such as
nearby social network, that must be kept low. This calls for a proactive
protocol. For such a real-time interactive application, it is reasonably
to expect the response time to be a fraction of a second. Performance
study in [WTS2015] shows that TRP achieves sub-second message end-to-end
delay. A rough estimate of OLSR/OLSRv2 message end-to-end delay includes
HNDP (link break detection) delay, TC message delay, and routing set
calculation delay. An experiment done in [www.dtic.mil/cgi-bin/
GetTRDoc?AD=ADA521173] has demonstrated that the delay for OLSR is
multiple seconds for a 18-node manet. Perhaps, solely from the delay
perspective for the intended application, a lightweight protocol, like
TRP, is warranted.

1.c Conserving battery energy for smartphones is another important issue.
TRP attacks the problem in two fronts: less taxing the CPU with a
lightweight protocol and selecting forwarding paths to exclude devices
with low remaining battery energy. By contrast, OLSR/OLSRv2 are running
in routers (which are not smartphones) and presummably have no energy
depletion issue.

1.d Participants in a nearby social network are constantly and rapidly
changing. Users need to know who are in the network to be able to select
them to chat. TRP solves the problem by periodically presenting to the
users with an updated list of all users who are happen nearby, i.e., in
the nearby social network. OLSR/OLSRv2 and others do not have such
capability essential to nearby social networks.

1.e The above argue for a lightweight protocol for nearby social
networks. I think we need to decide first whether there is a space for a
lightweight protocol, like TRP. Are there any existing protocols that can
support nearby social network applications?

2. Response to the comment "Could you please briefly introduce what's the
difference between TRP and other proactive protocols like OLSR(v2)?" made
by Jiazi

2.a OLSR/OLSRv2 use MPRs to aggregate LS information to thereby reducing
LS flooding overhead and for topology reduction. The current form of TRP
does not aggregate type 2 control information. After some thought,
aggregation may be possible in TRP, any ideas?

2.b While OLSR/OLSRv2 requires neighborhood discovery, TRP does not,
contributing to its light weight. Because nearby social networks are
highly dynamic (users are constantly moving), a discovered neighborhood
could quickly become outdated.

2.c While OLSR/OLSRv2 carry out routing set calculation from the network
topology graph after receiving TC messages for the link states, TRP
creates and updates forwarding entries on the fly when processing
individual control messages, eliminating the extra calculations. This
contributes to the TRP's light weight.

2.d While OLSR/OLSRv2 can actively remove advertised content, TRP relies
on timeout to remove users, who have left the network, from the user
list.

2.e While OLSR/OLSRv2 requires bidirectional links, TRP does not test if
a link is bidirectional because directionality could quickly change as
users are moving around. After some thought, it makes sense that once a
node has chosen the next node for a destination, the node confirms the
bidirectional link between the next node and itself.

2.f TRP supports devices with and without cellular data, with and without
a connection to an access point, and therefore, they may or may not have
an IP address. A TRP node self-assigns a node id (which is neither a 4-
byte nor 16-byte IP address but a 2-byte quantity for overhead
efficiency) and relies on id collision detection. Unique IP addresses are
configured (or by some other means) into OLSR/OLSRv2 routers.

2.g While OLSR/OLSRv2 operates up to the transport layer, TRP remains in
the data link layer.

2.h Smartphones have very limited battery energy but OLSR/OLSRv2 routers
do not have energy limitation.

2.i A TRP user can dynamically limit other users to within a physical
distance from herself. OLSR/OLSRv2 do not have such capability.

2.j A TRP user is constantly updated with a list of users within a
distance from her. OLSR/OLSRv2 do not have such capability.

2.k TRP users can independently choose how frequent to broadcast their
presence in the network. OLSR/OLSRv2 do not allow such an option.

2.l While OLSR/OLSRv2 are optimized for large and dense networks, TRP
must support large/small and dense/sparse networks.

2.m While OLSR/OLSRv2 supports security, TRP in its current state does
not call for security. I cannot think of scenarios that require security
in a nearby social network application. Any ideas?

2.n I think the protocol differences are due to the different intended
applications.

3. Response to the comment "Especially, it would be very helpful for the
readers to understand by providing a bit more text about the mechanism of
the protocol in the overview" made by Jiazi

3.a A node (say node X), upon receiving a control message, knows the node
who originated the message (say Node S, the originator) and the node from
which the message was received (say Node N, the forwarder). It is because
the originator puts its id in the control message and the forwarder
modifies the message by putting its id in it before retransmitting it. N
must be a neighbor of X. For example, if S sent the message, then N = S.

3.b An entry (destination node, forwarding node) = (S, N) in the
forwarding table is either created or updated in X. Of course the entry
contains other information such as sequence number, hop count, etc.)

3.c When X needs to forward a user message to S, X will transmit it to N.
The user message may be generated locally in X or forwarded to X by a
neighbor of X.

3.d It is entirely possible that X receives two or more control messages,
each with the same originator but different forwarders. Among these
control messages, X will select the one based on the sequence number, hop
count, etc. to create or update the entry. The other control messages are
discarded.

3.e X then modifies the selected message by putting its id in it and
retransmits it.

3.f As the control messages, with S as the originator, propagate
throughout the network, a tree rooted at S is built. The size of the tree
is limited by the maximum allowable hop count and the physical distance
between S and a leaf node.

3.g Since every node originates control messages, the result is a
complete topology of end-to-end paths.

3.h The tree rooted at a node is updated every time the node transmits a
control message. Since every node periodically transmits control
messages, the result is that the topology is constantly tracking the
movement of the users.

Peter Lau
The University of Memphis
Electrical and Computer Engineering


________________________________
From: Justin Dean <[e-mail]>
Sent: Wednesday, January 4, 2017 9:46 AM
To: Peter S Lau (peterlau)
Cc: Jiazi Yi; [e-mail]; Dearlove, Christopher (UK)
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"

Thank you for the submission. I too have some misgivings about the documents current state and tradeoffs with regard to packet format and lack of use of the Manet building blocks which seem like they could be easily incorporated. RFC5444 has Hop-limit/count and sequence number fields, and NHDP (RFC6130) has neighbor discovery and fixes the bidirectional problem. In addition to the other security pieces and leveraging of CDS algorithms found in either SMF or OLSRv2 one could build a similar protocol with only the addition of a message type and a few TLVS. The two that jump out at me for being useful beyond just this proposed protocol would be GPS and Application/Higher Layer ID TLV encodings.

Justin Dean

On Wed, Jan 4, 2017 at 5:10 AM, Dearlove, Christopher (UK) <[e-mail]<mailto:[e-mail]>> wrote:
There some immediate retrograde steps compared to existing protocols: fixed message format (making adding new information to be used by the protocol hard), forwarding by blind flooding (hence scalability issues), and no security (an example of something that to add would require a changed format). The rather peculiar link metric (in effect) that mixes hop count, time and battery power leads to many questions (and while not simply hop count is likely to be a backward step in flexibility). There’s a rather unusual message body that is not used by this protocol but said to be for the application, which is a bit of a layering issue. GPS is included with no indication how to use and hence no indication why it is there. They are also underspecified in terms of format information (and for GPS at least even size of field). There’s quite a lot underspecified, such as route determination, and there’s no consideration of how the acknowledgements are used - and even what the meaning of acknowledgements in what must be (but is not so described) as a local broadcast/multicast message (with potentially unknown recipients). I don’t see any handling of the problems that link asymmetry produces. I’d have issues over timing parameters and their management (these being not reflected in the message). And in a proposed IETF protocol, I don’t see any IP addresses. That it hasn’t even caught up with the existence of RFC 7181 (only quoting RFC 3626) is not a good sign. It is suggested that RFC 3626 (and hence, no doubt, RFC 7181) is too complex. That may or may not be so (there are reasons for the added complexity in RFC 7181, which need to be understood before deciding whether you need them) and there thus may or may not be a space for a lightweight proactive protocol, but this is not that protocol in current or foreseeable evolutionary form.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  [phone]<tel:+44%201245%20242194>  |  E: [e-mail]<mailto:[e-mail]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Jiazi Yi
Sent: 04 January 2017 09:08
To: Peter S Lau (peterlau)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [manet] A proposed draft "draft-peterlau-manet-topology-refresh"


*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://ws-sites.ent.baesystems.com/sites/HOSECStdsLibrary/StandardsLibrary/Everyone/Dealing%20With%20Suspicious%20Emails.pdf>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Dear Peter,

Thanks very much for your draft.

Looking at the overview section:

   TRP is a table-driven proactive data forwarding protocol and at the
   same time allows users to announce their presence to the network.  A
   node, wishing to be contacted, periodically broadcasts control
   messages about itself to the network.  A node, receiving control
   messages, caches an optimal path to each of the originators of the
   control messages.

Could you please briefly introduce what’s the difference between TRP and other proactive protocols like OLSR(v2)?

Especially, it would be very helpful for the readers to understand by providing a bit more text about the mechanism of the protocol in the overview.

best

Jiazi

On 3 Jan 2017, at 18:09, Peter S Lau (peterlau) <[e-mail]<mailto:[e-mail]>> wrote:

Dear manet Working Group:

I have uploaded a proposed draft entitled "draft-peterlau-manet-topology-refresh-00". for the WG to consider.

Regards,
Peter Lau

Peter Lau
The University of Memphis
Electrical and Computer Engineering
_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.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.
********************************************************************

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet