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

[Christopher Dearlove <[e-mail]>]

On the contrary, that's exactly the sort of scenario OLSRv2, and before it OLSR were developed for. Well, for OLSR it was laptops and PDAs. Several of us have networked such devices in that way.

Delay in OLSRv2 is a function of its parameters. It's not meaningful to define a single delay value. I've yet to see why you think TRP is inherently faster.

The comments about smartphones and routers completely misses the point. A router is a function, not a device. If you run OLSRv2 in a smartphone, the smartphone is a router.

The comment about OLSRv2 not knowing who is in the network is simply wrong.

At that point I've just decided to stop answering point by point. I suggest first understanding what exists, and why it has the features it has, before trying to suggest you have something better.

--  
Christopher Dearlove
[e-mail]
[e-mail] is dead

> On 9 Jan 2017, at 20:06, Peter S Lau (peterlau) <[e-mail]> wrote:
> 
> 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]> 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]  |  E: [e-mail]
>> 
>> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>> 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]] On Behalf Of Jiazi Yi
>> Sent: 04 January 2017 09:08
>> To: Peter S Lau (peterlau)
>> Cc: [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.
>> If you feel the email is suspicious, please follow this process.
>> 
>> *** 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]> 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]
>> 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]
>> https://www.ietf.org/mailman/listinfo/manet
>> 
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet