Source Coding and Fountain Codes meet Multipath TCP (MPTCP)

http://blog.multipath-tcp.org/blog/html/2014/02/17/network_coding_meets_multipath_tcp.html


Source Coding and Fountain Codes meet Multipath TCP

Multipath TCP continues to attract the interest of networking researchers. In less than one week, two preprints of papers that apply networking coding techniques to improve the performance Multipath TCP have been published.

In the first paper [FMTCP] , Yong Cui and his colleagues propose to apply Fountain Codes, as defined in RFC 6380 to Multipath TCP. This is an interesting approach that encodes the data and adds redundancy to the data before transmission. Thanks to this coding scheme, FMTCP does not need to retransmit all segments when losses occur. Of course, the tradeoff is that FMTCP generates more data than Multipath TCP. The paper evaluates the performance of FMTCP by comparing it with Multipath TCP by relying on ns-2 simulations. The simulations show that on lossy links FMTCP performs better than Multipath TCP. This is not surprising given that Multipath TCP’s congestion control scheme tries to move traffic away from lossy paths by reducing its transmission rate on those paths. FMTCP on the other hand can easily recover from a limited number of losses by relying on its coding scheme. It would be interesting to complement these simulations by :

  • evaluating the performance of several competing FMTCP flows. This would show the impact of the losses on the congestion control scheme that is used by FMTCP (the paper is not very clear about the congestion control scheme that it used and unfortunately, the source code of the simulator used is not referenced in the paper)
  • evaluating the support of interactive applications. Such applications are more likely to benefit from FMTCP than bulk transfer, but this might have an impact on the coding scheme that will not have to deal anymore with fixed size segments

Another related paper is SC-MPTCP [SCMPTCP] . SC-MPTCP relies on source coding to encode the segments before being transmitted. It also compares SC-MPTCP with regular Multipath TCP, but explicitly mentions the utilisation of the coupled congestion control scheme and relies on ns-3 simulations. The simulations analyze the impact of losses on the performance of both SC-MPTCP and regular Multipath TCP. In addition, it also proposes a scheduling technique to select on which subflows segments have to be sent to minimize reordering on the receiver and thus prevent head-of-line blocking when the receive buffer is limited. This technique is applicable to both regular Multipath TCP and SC-MPTCP. The paper then evaluates two interesting multihoming scenarios and shows the benefits of SC-MPTCP compared to Multipath TCP.

These two papers show that by adding redundancy to the data segments, it is possible to improve the performance of Multipath TCP in lossy environments. These results were based on simulations and there are two remaining questions that need to be answered :

  • How can these techniques be efficiently implemented in TCP stacks, either kernel-based on by modifying user-level TCP stacks that start to (re)appear ? How do applications interact with such modified stacks ?
  • What happens when several sources using source coding or fountain codes compete for the same bottleneck link where packets are discarded due to congestion ? Is the loss pattern as favorable for the source coding and fountain codes are random losses that mainly correspond to wireless links ?

Bibliography

[FMTCP]Yong Cui, Lian Wang, Xin Wang,Hongyi Wang, and Yining Wang, FMTCP: A Fountain Code-Based Multipath Transmission Control Protocol, to appear in IEEE/ACM Transactions on Networking, http://dx.doi.org/10.1109/TNET.2014.2300140
[SCMPTCP]Ming Li, Andrey Lukyanenko, Sasu Tarkoma, Yong Cui, Antti Yla-Jaaski, Tolerating path heterogeneity in multipath TCP with bounded receive buffers, Computer Networks, Available online 6 February 2014, ISSN 1389-1286, http://dx.doi.org/10.1016/j.comnet.2014.01.011.

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
2.2功能描述 本软件为协议转换软件,从OPC server端获取数据,然后通过协议转换成Modbus server端及FMTCP Server端,供第三方设备或系统进行访问,支持Modbus RTU模式和Modbus TCP模式。 2.3应用场景 场景一:目前大多数现场控制系统(DCS)都提供OPC server接口,但是为了安全起见,很多生产型企业的OPC服务器禁止外部的设备或系统通过TCP方式接入,对外只提供串口。在这种情况下,可以在OPC服务器上部署Opcquickclient软件,通过在本地将OPC协议转换成Modbus RTU协议映射到相应的串口,就很方便的供第三方硬件或系统进行访问。 场景二:Opcquickclient软件可以用来解决远程访问OPC服务器遇到的DCOM配置问题(远程OPC缺点:通讯不稳定,DCOM配置麻烦,不利于维护)。在OPC服务器运行的电脑上安装Opcquickclient软件后,通过此软件读取OPC服务器并转换成Modbus服务器,这样其它电脑仅仅通过访问Modbus服务器,就可以实现监视和控制(读写OPC服务器),习惯使用OPC的客户可以使用免费的软件OPCRemote.exe在远程计算机还原成OPC通讯方式。 场景三:可以让Linux平台的设备(如某些工业触摸屏)或者不带操作系统的设备(如PLC)通过Modbus协议可以访问PC上的OPC服务器,从而实现系统集成。 本软件优点:可配置性强,操作简单,稳定可靠。在OPC服务器意外关闭的时候,该软件能够使OPC服务器自动运行起来,方便用户操作。 2.4应用领域  解决工业触摸屏访问OPC服务器;  解决不带Windows操作系统的控制器访问OPC服务器,如Linux OS 电脑、PLC、DCS等;  解决访问Citect、IFIX、RSVIEW、WINCC、组态王、易控等组态软件远程OPC服务器的问题;  等等……
Go语言(也称为Golang)是由Google开发的一种静态强类型、编译型的编程语言。它旨在成为一门简单、高效、安全和并发的编程语言,特别适用于构建高性能的服务器和分布式系统。以下是Go语言的一些主要特点和优势: 简洁性:Go语言的语法简单直观,易于学习和使用。它避免了复杂的语法特性,如继承、重载等,转而采用组合和接口来实现代码的复用和扩展。 高性能:Go语言具有出色的性能,可以媲美C和C++。它使用静态类型系统和编译型语言的优势,能够生成高效的机器码。 并发性:Go语言内置了对并发的支持,通过轻量级的goroutine和channel机制,可以轻松实现并发编程。这使得Go语言在构建高性能的服务器和分布式系统时具有天然的优势。 安全性:Go语言具有强大的类型系统和内存管理机制,能够减少运行时错误和内存泄漏等问题。它还支持编译时检查,可以在编译阶段就发现潜在的问题。 标准库:Go语言的标准库非常丰富,包含了大量的实用功能和工具,如网络编程、文件操作、加密解密等。这使得开发者可以更加专注于业务逻辑的实现,而无需花费太多时间在底层功能的实现上。 跨平台:Go语言支持多种操作系统和平台,包括Windows、Linux、macOS等。它使用统一的构建系统(如Go Modules),可以轻松地跨平台编译和运行代码。 开源和社区支持:Go语言是开源的,具有庞大的社区支持和丰富的资源。开发者可以通过社区获取帮助、分享经验和学习资料。 总之,Go语言是一种简单、高效、安全、并发的编程语言,特别适用于构建高性能的服务器和分布式系统。如果你正在寻找一种易于学习和使用的编程语言,并且需要处理大量的并发请求和数据,那么Go语言可能是一个不错的选择。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值