Subject: Re: [P2PSIP] P2P SIP - Real-time Multimedia Services

From: FORTAINE Guillaume <[email-masked]>
Date: Sat, 05 Apr 2008 20:01:50 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Tue, 08 Apr 2008 11:27:26 -0400

Hi, Guillaume:

The technical points that you have made are being investigated since the inception of the MANET networking. Probably, nearly two decades have been passed in MANET research and some of the commercial prototypes of MANETs have been implemented and their results are being published in various literatures.

My personal understanding is the, encouraged by experiences of prototype implementations of MANETs, their large-scale implementations are being followed between now and 2015 especially for military networks. And you are right, standards also need to follow hand-by-hand to obtain the fruits of MANETs in the commercial large-scale networks. In fact, it is challenges of the day going forward.

The encouraging news is that MANET WG and AUTOCONFIG WG are developing the standards for MANETs in the network layer/IP layer. In directly, P2PSIP WG is also working for P2P SIP application that may be the first step which can be also be used for MANETs.

However, more standard works also need to be done as follows:

1. Implications of call signaling messages for call setup/teardown/re-establishment as mobile users will move with almost randomly unpredictable speed and direction with constantly variable topology and, thereby, the needs for extensions of P2PSIP standards.

2. In MANETs, there is no such "guaranteed QOS," and thereby, new QOS standards such as "soft" QOS has been to be created. For example, IETF research group is working on "delay tolerant networking" etc.

3. The congest ions/interferences in MANETs will be pushed back to the application layer (e.g., Navy's SBIR). It means that dynamic encoding of bandwidth-intensive application like video and others with a given session.

4. Items 1, 2, and 3 indicate that there may not anything that is called layer-agnostic. That is, cross-layer mechanisms will be a part of the usual MANET networking.

I do not want make the list long. The above items 1, 2, 3, and 4 reveal the fact that the days for the traditional networking are over for MANET networking. It also implies that an enormous amount of STANDARD works need to be done for full implementations of MANETs.

Now to do the standard works you may need to follow as explained in my earlier email:

* Wirte some drafts what works on standards need to be done related to MANETs

* Suggest for extensions of P2PSIP, MANET, AUTOCONFIG, and NSIS WG for may particular standards that may be applicable for MANETs

* If no existing WGs are suitable (e.g. X-layer) for any MANET topics, suggest to form new WGs writing some drafts explaining the needs and IETF management will be, I think, kind enough to provide chances for BOFs.

Best regards,
Radhika

----- Original Message -----
From: FORTAINE Guillaume 
Date: Saturday, April 5, 2008 14:01
Subject: Re: [P2PSIP] P2P SIP - Real-time Multimedia Services
To: "Roy, Radhika R Dr CTR USA USAMC" 
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

> DirecNet Portal 
> Home - *Delay Tolerant Networking Research Group* 
> 
> 
> -Open Source :
> 
> 
> 
> 
> Layer-5 :
> 
> > 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.
> >