其实跟上一篇是同一篇文章。不过上一篇是发表在IEEE Secon2010了，这篇是后来又增加了部分内容后的一版，收录在IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 20, NO. 4, AUGUST 2012
只说不同的地方。主要是二点：
1、增加了UDP的部分（正如上一篇文中所计划的那样）
2、在UDP的部分，实现了分布式的部署DSASync，每个DSAN内的节点都部署DSASync。当然同时BS上的DSASync继续发挥作用。
关于UDP，由于是非连接的、没有内建的控制算法机制来调用（像TCP那样的，可以给DSASync使用的状态参数），因而DSASync其实是无法对它做出控制的（也是因为UDP本身的设计如此）。这时候非要对UDP做出控制，作者转向了高层协议——RTP，因为作者的本意就是要提升性能，且强调的背景就是多媒体传输、Qos的需求、视频通话等等，而RTP就是这些所对应的协议，因而有这种选择也是可以想见的。故而，整个UDP方面的涉及，其实都是围绕RTP的。
要说的是，最后的结果跟TCP类似，也是有显著的提升。另外，在UDP性能实验上，作者实现了分布式的DSASync，结果在应用层（ekiga VoIP）上表现良好（jitter/抖动这一参数）。
另外要提的是、DSASync对RTP协议的识别，RTP没有专门的特征，比如端口好可以识别，因而暂时采取了其他的方法（在RTP连接建立的时候通过一些特征识别）：
In our implementation, we use a method similar
to that of packet sniffing tool Ethereal [28], which uses packets
seen earlier (e.g., SIP or RTSP packets) during the setup of
connection to identify the RTP sessions. We improve this
approach by looking for specific port ranges that are typically
used by applications for RTP session setup and subsequent
data transfer. Though this approach works fairly well, it cannot
capture all RTP-based UDP flows.
正如其所说，不能识别所有的RTP，但工作的也够不错的了。
其他实验中提出的问题有两点：
1、对于加密的连接，DSASync会有问题。对TCP部分，如果是高层（应用层）的加密，则没有影响；如果是类似IPSec的IP层加密，DSASync就完全失效了。因为加密了传输层和应用层的头部（transport/application header）。对UDP部分，因为是要识别应用层的RTP，则如果是加密连接，则DSASync完全不可用。
1、虽然分布式DSASync在UDP的实验中有良好表现，但作者建议只把它作用可选拓展模块，因为限于资源问题，并不能保证终端都部署DSASync，比如手机。
最后，future work
1、基本的DSASync就定了，以后会研究一下扩展，来优化性能。
2、研究Qos，比如不同节点优先权的问题（priority issues）。