Dear Mister Roy, You are Excellence and it's definitely an honor for me to be in contact with You Today
There are various ways for P2P Networking : -US Army : DirecNet Portal <http://direcnet.org/> -DARPA : Home - *Delay Tolerant Networking Research Group* <http://www.dtnrg.org/> -Open Source : B.A.T.M.A.N. — *open-mesh* <https://www.open-mesh.net/batman> What I really appreciate in Navy SBIRs are their pragmatic approach and their low-level details (including Publications & Quantitative measurements) : (SBIR) Navy - *High Throughput and Low Latency Multi-Hop Mobile Ad* … <http://www.navysbir.com/n08_1/N081-102.htm> OBJECTIVE: While MANET promises to significantly increase the available Navy bandwidth, existing MANET throughput decreases exponentially as the number of hops increases (hops > 4). This research will enable: 1) a multimedia stream to hop over hundreds of nodes without quality degradation and 2) hundreds of multimedia steams to cross a single node without quality degradation; 3) an advance in the state-of-the art videoconferencing and legacy application virtualization. Develop an end-to-end software solution (based on low-cost commodity hardware) that allows a multimedia stream (voice-over-internet-protocol [VoIP], videoconferencing, screen/application sharing, file transfer, and biological/chemical sensor data) to hop over a large number of nodes without quality degradation as defined by psychological human factor quality-of-service (QoS) requirements. DESCRIPTION: Existing MANET solutions have difficulty delivering a multimedia stream over a large number of hops. This research will develop novel software solutions to maintain high throughput and low latency for multimedia delivery over a large number of hops. The solution should: allow >1 Mbps and <500 msec of delay over 100 hops and be able to handle the cross-stream interference from multiple steams flowing over a particular node; and allow low-bandwidth videoconferencing for multiple sites (>100); exploit the difference in human factor requirements for QoS for different multimedia (audio vs. video, vs. sensor data, etc) to optimize the streaming of different media types; use advanced compression and networking techniques to achieve a significant reduction (10X) in bandwidth compared to existing commercial solutions; advance in the state-of-the art videoconferencing and legacy application virtualization; adapt to a variety of networks (available bandwidth, packet loss rate and jitter); support FIPS 140-2 256 bit AES encryption; record the training sessions; and be able to run as a web-service or as a stand-alone program on segmented/closed/MANET networks. During the past Years, I have benchmarked all the various approaches and I have always been convinced by the superiority of P2P Networking and its potential in the Commercial Sector, especially in emerging countries. To quote : PRIVATE SECTOR COMMERCIAL POTENTIAL/DUAL-USE APPLICATIONS: If this SBIR can demonstrate that high throughput and low latency multi-hop MANET multimedia streaming is possible, it would solve a parallel need in the business and education communities. It could provide networks to developing countries (e.g. in Africa) where infrastructure-based networks is not cost-effective. The resulting network could deliver distance education, just-in-time remote training and telemedicine. The capability is critical to First Responders in hastily formed networks, where the Internet is not available due to natural or man-made disasters. The system could play an important role in government. In the event of a natural or man-made disaster in the Nation’s Capital, it might be necessary for Congress to meet virtually. The capability would allow Congress members to meet from their home office to carry out their duties. QoS is maybe one of the most elusive (not to say a buzzword) in the Network Engineering World that's why I will propose a bottom-up approach to try to follow the Navy SBIR Requirements, ensuring compliance to the OSI Model, by reducing the latency time at each layer, and around a common Kernel (Linux) and an underlying COTS platform ( that I am currently defining with my suppliers) to be able to have common denominator. Layer 1 : *Channel Access over Path Segments* for Ultra Low Latency MANETs <http://www.ir.bbn.com/%7Eramanath/pdf/caps-milcom07.pdf> Layer-2 : -MAC : http://www.rts.uni-hannover.de/rtnet/roadmap.html RTmac : WLAN-Specific MAC Discipline -Routing : 24C3: *Wireless Kernel Tweaking* <http://events.ccc.de/congress/2007/Fahrplan/events/2292.en.html> Wireless Kernel Tweaking or how B.A.T.M.A.N. learned to fly Kernel hacking definitely is the queen of coding but in order to bring mesh routing that one vital step further we had to conquer this, for us, unchartered territory. Working in the kernel itself is a tough and difficult task to manage, but the results and effectivity to be gained justify the long and hard road to success. We took on the mission to go down that road and the result is B.A.T.M.A.N. advanced which is a kernel land implementation of the B.A.T.M.A.N. mesh routing protocol specifically designed to manage Wireless MANs. During the last years the number of deployed mesh networks has increased dramatically and their constant growth drove us around the edge of what we thought was possible. To cope with this rapid development we had to leave the slow and limited track of tweaking existing approaches and take an evolutionary step forward by porting the B.A.T.M.A.N. protocol into the kernel land and going down to layer 2. Using B.A.T.M.A.N. advanced as a showcase we will, in our lecture, deliver a detailed review on how one can go about developing linux kernel modules, give insights in what difficulties to expect and provide practical tips on how to go about this challenge without experiencing a damaging kernel freeze in due process. We will describe what problems we faced migrating down to layer 2 and how we went about solving them for example how we moved away from the kernel routing and handle the actual routing and data transport in B.A.T.M.A.N. itself. Also moving to layer 2 meant to leave IPs behind and solely rely on MAC-routing enabling features like DHCP, IPX, IPv6, etc which up to now was not possible and therefore comes as a big plus. On the other hand there were little if none diagnostic tools at all for routing on that level so we had to go back one step and develop the tools we needed ourselves. These and other things we will cover in our presentation and also give an outlook into the future of mesh-routing, which will bring it even closer to the source of wifi - the wireless stack and its drivers and thereby improving the overall performance even more. Layer-3 : TNRL Projects <http://www.cs.ou.edu/%7Enetlab/sigma.html> *SINEMO (_S_eamless _I_P-diversity based _NE_twork _MO_bility)* ** SINEMO is an extension of SIGMA architecture for NEtwork MObility (NEMO). IETF has proposed NEMO basic support protocol based on Mobile IPv6 to support mobile networks. NEMO basic support protocol inherits all the drawbacks of Mobile IPv6, such as inefficient routing path, single point bottleneck, increased handover latency and packet loss rates, and increased packet overhead etc. To address those problems, we propose a novel IP-diversity based mobile network architecture called SINEMO. The basic idea of SINEMO is to exploit IP diversity to keep the old path alive during the process of setting up the new path, thus achieving seamless handover of mobile networks between adjacent cells. In addition to seamless handover, SINEMO has a number of advantages such as easier deployment in the Internet infrastructure, co-operation with Internet's security protocols, efficient utilization of network bandwidth, etc. SINEMO's design incorporates a number of desirable features (for example, complete transparency of network mobility to the nodes in the mobile network and efficient utilization of the wireless links (i.e. minimum signaling)) for mobile networks. Layer-4 : http://sourceforge.net/projects/lksctp Stream Control Transmission Protocol (SCTP) is a reliable, message-oriented, multihomed transport protocol. Developed by the IETF SIGTRAN working group to transport SS7 over IP, it is now the third general-purpose transport developed by the IETF. Layer-5 : *Real*-*time Multimedia Services Using Hybrid P2P SIP* <http://ieeexplore.ieee.org/iel5/4141327/4084518/04141533.pdf?tp=&isnumber=&arnumber=4141533> *Real-time Multimedia Services Using Hybrid P2P SIP* Mo, Yijun; Wang, Fei; Huang, Benxiong; Luo, Fu Communications and Information Technologies, 2006. ISCIT apos;06. International Symposium on Volume , Issue , Oct. 18 2006-Sept. 20 2006 Page(s):157 - 161 Digital Object Identifier 10.1109/ISCIT.2006.339907 *Summary:*SIP becomes one most poplar protocol in real-time multimedia services, but the central server becomes the single point of failure, While P2P becomes "killing level application" in Internet because of its robust and low cost. Combing P2P and SIP, we propose hybrid P2P SIP framework in the paper, and describe several important procedures, such as node registration, user registration and call procedure. But current P2P searching and routing arithmetic does not meet the requirement for low time delay in real-time multimedia applications. Then, we present a novel SOMCO arithmetic, which decreases the call delay and media forwarding delay to some extend. Simulation verifies that SOMCO is practical to support real-time multimedia services I look forward to Your Answer, Best Regards, Roy, Radhika R Dr CTR USA USAMC wrote: > Hi, Fortain: > > I think that you can start working for all those QOS mechanisms within the > framework of P2PSIP. Let me explain as follows: > > 1. Mobile Ad Hoc networks need P2P networking. As result, the applications > also need to be P2P. P2PSIP WG is working for facilitating in building of > P2PSIP applications. > > 2. The ad hoc mobility part is primarily related to the topology control of > MANETs and MANET WG and AUTOCONFIG WG are working in the layers 2-through > 3/4. The QOS-mechanisms of the network layer are being taken care of by those > WGs. > > 3. The application layer QOS for SIP in peer-to-peer mode can best be working > within the framework of P2PSIP WG because, I believe, you do not need to do > anything explicitly related to mobility assuming that the lower MAC and > network layer of MANET are being taken care of by those WGs (e.g. topology > control, routing, QOS) and we can plug those things from the application > layer to the lower network to work cooperatively. > > 4. It is true that we may have to do something in the P2P application layer > like P2PSIP for QOS as well as for taking care of the ad hoc mobility, it is > still not well understood by all of us. Once the P2PSIP signaling protocol is > taken care of, we will gain more experiences what we have to do next. > > However, if you suggest what specific problems related to QOS you want to > address in the P2PSIP application Layer for solving the performance problems, > we can then look into those taking Navy's QOS requirements for MANET networks. > > I appreciate for bringing the interesting real problems in the P2PSIP WG > mailing list. > > Best regards, > Radhika > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
