Difference between revisions of "Archived-DMM"
Qing.chang (Talk | contribs) |
|||
| Line 24: | Line 24: | ||
* Use different network protocol stacks based on their functional and performance requirement (QOS). | * Use different network protocol stacks based on their functional and performance requirement (QOS). | ||
* Work with multiple instances of transport protocol stack. | * Work with multiple instances of transport protocol stack. | ||
| − | + | It Engage or adopt new protocol stack dynamically. | |
| − | + | ||
[[Project_Proposals/DMM|DMM Project Proposal]] | [[Project_Proposals/DMM|DMM Project Proposal]] | ||
<!--[[File:TLDK - Network Sample Code - TCP plan.pptx|thumb|TLDK TCP Plan]] --> | <!--[[File:TLDK - Network Sample Code - TCP plan.pptx|thumb|TLDK TCP Plan]] --> | ||
| + | |||
| + | == History == | ||
| + | |||
| + | Emerging applications are bringing extremely high-performance requirements to the network system. Eg. AR/VR, IOT etc. And Many of them | ||
| + | coming with their unique demand of QOS/SLA. Some application need low latency network, some need high reliability etc. Though such performance | ||
| + | targets should be required for the complete communication system, the transport layer protocols play a key role and encountered a relatively higher | ||
| + | challenge, because traditionally the TCP-based transport layer exploits the “best-effort” principle and provides no performance guarantees in its nature. | ||
| + | However, as Internet applications rapidly grow and diversify, an all-powerful or one-fits-all protocol or algorithm becomes less feasible. Thus, | ||
| + | the traditional single-instance TCP-based network stack bears great challenges when serving many applications with different QoS/SLA requirements | ||
| + | simultaneously on the same platform. | ||
| + | |||
| + | Also Moving the networking stack out of the kernel is an obvious trend in both the industry and literature. | ||
| + | Technolgies like DPDK, etc improving performance of network stack, by bypassing the kernel, avoiding context-switching and data copies, as well | ||
| + | as providing a complete set of packet-processing acceleration libraries. | ||
| + | |||
| + | Keeping above trends in mind the DMM/nStack provides a framework where, system operators can plug in dedicated types of networking stack | ||
| + | instances according to performance and/or functional requirements from the user space applications. Application doesnt have to worry about | ||
| + | change their transport layer API. A lightweight nStack management daemon is responsible for maintaining the stack instances and the | ||
| + | app/socket-to-stack-mappings, which are provided via the orchestration/management interface. | ||
== Get Involved == | == Get Involved == | ||
| Line 42: | Line 60: | ||
How to submit a patch to DMM - [https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pushing Pushing Code with git review] | How to submit a patch to DMM - [https://wiki.fd.io/view/VPP/Pulling,_Building,_Running,_Hacking_and_Pushing_VPP_Code#Pushing Pushing Code with git review] | ||
| + | |||
| + | ==Reference== | ||
| + | |||
| + | Enabling “Protocol Routing”: Revisiting Transport Layer Protocol Design in Internet Communications - [http://ieeexplore.ieee.org/document/8114687/] | ||
Revision as of 07:36, 22 March 2018
| DMM Facts |
|
Project Lead: George Zhao
Repository: git clone https://gerrit.fd.io/r/dmm |
What is DMM
DMM (Dual Mode, Multi-protocol, Multi-instance) is to implement a transport agnostic framework for the applications where applications can
- Work with both user space and kernel space network stacks.
- Use different network protocol stacks based on their functional and performance requirement (QOS).
- Work with multiple instances of transport protocol stack.
It Engage or adopt new protocol stack dynamically.
History
Emerging applications are bringing extremely high-performance requirements to the network system. Eg. AR/VR, IOT etc. And Many of them coming with their unique demand of QOS/SLA. Some application need low latency network, some need high reliability etc. Though such performance targets should be required for the complete communication system, the transport layer protocols play a key role and encountered a relatively higher challenge, because traditionally the TCP-based transport layer exploits the “best-effort” principle and provides no performance guarantees in its nature. However, as Internet applications rapidly grow and diversify, an all-powerful or one-fits-all protocol or algorithm becomes less feasible. Thus, the traditional single-instance TCP-based network stack bears great challenges when serving many applications with different QoS/SLA requirements simultaneously on the same platform.
Also Moving the networking stack out of the kernel is an obvious trend in both the industry and literature. Technolgies like DPDK, etc improving performance of network stack, by bypassing the kernel, avoiding context-switching and data copies, as well as providing a complete set of packet-processing acceleration libraries.
Keeping above trends in mind the DMM/nStack provides a framework where, system operators can plug in dedicated types of networking stack instances according to performance and/or functional requirements from the user space applications. Application doesnt have to worry about change their transport layer API. A lightweight nStack management daemon is responsible for maintaining the stack instances and the app/socket-to-stack-mappings, which are provided via the orchestration/management interface.
Get Involved
- Bi-Weekly DMM Meeting.
- Join the DMM Mailing List.
- Join fdio-dmm IRC channel.
- Browse the code.
- 18.04 Release Plan
Start Here
How to submit a patch to DMM - Pushing Code with git review
Reference
Enabling “Protocol Routing”: Revisiting Transport Layer Protocol Design in Internet Communications - [1]
