Designing and implementing a new type of transport-layer socket: the UDTCP socket case
Abstract
On most operating systems, the UDP and TCP sockets are the two main types of sockets used to provide transport-layer networking services. However, for several reasons, UDP and TCP sockets are unsuitable for transporting delay-sensitive but error-tolerant streaming data such as the data generated by multimedia streaming applications. In this paper, we create a new type of socket that is suitable for transporting such data and propose a novel and simple implementation for it.
- Introduction
Multimedia streaming applications are becoming more popular on the Internet . These applications are usually delay and delay jitter-sensitive. However, because human perception can tolerate some errors, usually some degree of packet loss and packet reordering can be tolerated by these applications. By using dynamic variable rate encoding or layering techniques, these applications can be made adaptive. The band-width requirement for such an adaptive application can be varied over time to dynamically match the current available bandwidth. This often results in lower packet loss rates and smaller delays.
Most of these delay-sensitive, but error-tolerant multi-media streaming applications use UDP rather than TCP to transport an audio or video stream on the Internet . An example is Microsoft Incrsquo;s lsquo;Media Playerrsquo; product. These applications choose to use UDP rather than TCP because otherwise some undesirable delay problems will result as follows. First, when TCP packets are lost, TCP at the sending host will automatically retransmit them until they are received by the receiver. However, retransmitted packets may arrive too late to be useful for these delay-sensitive applications. This will only waste network bandwidth. Second, because TCP is designed to provide a reliable and in-sequence delivery service, when some TCP packets are lost, TCP at the receiving host will put other received out-of-order packets into its reassembly queue for re-sequencing. (Note: As long as one TCP packet is lost, all following TCP packets are viewed as out-of-order even though they are in sequence.) This design unnecessarily delays the delivery of arrived packets (actually, the data carried in these packets) to delay-sensitive multimedia streaming applications.
Unlike TCP, UDP performs no congestion control. Today many multimedia streaming applications use a fixed rate (e.g. 28, 33, 56, 112 Kbps or 1.5 Mbps) to transport their audio or/and video stream data. If these applications become popular and their traffic constitutes a large portion of the Internet traffic, the use of UDP as their transport protocol will disrupt Internet congestion control and cause problems. The first problem is congestion collapse. When a larger portion of the Internet traffic is carried by UDP, network congestion control will become less effective. Therefore, during network congestion, these UDP-based applications may cause TCP-based applications such as web, ftp and email to stop their data transfers. More concerns about this problem have been discussed in Ref.
Recently, to solve the above problems, many approaches have been proposed to apply TCP congestion control to a UDP packet stream. In these approaches, the multimedia streaming application uses a UDP socket to send and receive packets and a lsquo;TCP-friendlyrsquo; or lsquo;TCP-likersquo; congestion control protocol to control when to send data into the UDP socket. Because it is difficult to prove that these approaches implement true TCP congestion control under any given network condition, these approaches are often called lsquo;TCP-friendlyrsquo; or lsquo;TCP-likersquo;.
To provide true TCP congestion control but no TCP error control for a stream of delay-sensitive but error-tolerant packets, we design and implement the UDTCP socket in FreeBSD 4.8. The UDTCP socket is a new type of socket. It has the properties of UDP and TCP sockets that are suitable for multimedia streaming applications but not those UDP and TCP properties that are unsuitable for such applications. The UDTCP socket properties include (1) datagram (i.e. unlike TCPrsquo;s byte-stream service, the message boundary of application data is preserved), (2) true TCP congestion control (i.e. packets are sent under true TCP congestion control), (3) no mandatory TCP error control (i.e. lost/corrupted packets need not be forcibly retransmitted by the sending host), and (4) no mandatory TCP out-of-order packet re-sequencing (i.e. out-of-order packets need not be forcibly delayed in the TCP reassembly queue). Because of these properties, the UDTCP socket is very suitable for multimedia streaming applications.
The contributions of this paper are as follows. The first contribution is about protocol design. We create a new type of socket (UDTCP) that uses TCP congestion control but no TCP error control to transport a stream of delay-sensitive but error-tolerant data. The transported stream is 100% TCP friendly and causes no harm to network congestion control because the default in-kernel TCP congestion control is used. The second contribution is about protocol implemen-tation. We propose a novel and simple implementation for the UDTCP socket. On FreeBSD 4.8, we can convert the TCP socket implementation into the UDTCP socket implementation by adding, modifying, or deleting only 43 lines of C statements of the TCP socket implementation.
The rest of this paper is organized as follows. Section 2 surveys related work. Section 3 presents our design and implementation of the UDTCP socket. Section 4 describes the design features that reduce the queuing delay of packets waiting in a UDTCP socket send buffer. Section 5 presents an analysis showing that to reduce the delay, re-sequencing packets in the TCP reassembly queue should be eliminated. Section 6 presents si
剩余内容已隐藏，支付完成后下载完整资料
附录A 外文翻译
设计和实现一种新的传输层套接字:UDTCP套接字
摘要：
在大多数操作系统上,UDP和TCP套接字是两种主要类型的传输层网络套接字用于提供服务。然而,由于几个原因,UDP和TCP套接字不适合运输对延迟敏感但不变性流数据等多媒体流媒体应用程序生成的数据。在本文中,我们创建一个新的套接字的类型,适用于新颖的且简单运输这些数据。
1. 介绍
多媒体流媒体应用越来越受欢迎的在互联网上。这些应用程序通常延迟和延迟抖动敏感。然而,因为人类感知可以容忍一些错误,通常是某种程度的丢包和包重新排序可以容忍这些应用程序,通过使用动态可变速率编码或分层技术,这些应用程序可以自适应。这样一种自适应的带宽要求应用程序可以动态变化随着时间的匹配当前可用带宽。这往往导致较低的丢包率和较小的延迟。
大多数的迟敏锐，高容忍的多媒体流媒应用软件在互联网上使用UDP而非TCP传输音频或视频。比如微软公司的媒体播放器的产品。这些应用程序选择使用UDP而非TCP,否则一些不良的延迟将导致如下问题。首先,当TCP数据包丢失,TCP发送主机将自动重新发送他们,直到他们由接收器接收。然而,转播的数据包到达太迟，可能对于这些对延迟敏感的应用程序而言它就没用了。这只会浪费网络带宽。其次,由于TCP旨在提供一个可靠的和依次交付服务,当一些TCP数据包丢失,TCP在接收主机将其他收到的无序的数据包变成为re-sequencing重组的队列。（注意:只要一个TCP数据包丢失,所有TCP数据包后被视为无序,尽管他们有序）这个设计延迟交付数据包到达(事实上,是这些数据包中的数据)那些对延迟敏感的多媒体流的应用程序事没有必要的。
与TCP,UDP执行没有拥塞控制不同的是，如今许多多媒体流媒体应用程序使用固定汇率(例如28,33,56，112 Kbps或1.5 Mbps)去运输他们的音频或视频流数据。如果这些应用程序变得受欢迎,他们的交通构成了大部分的互联网流量,使用UDP作为传输协议将扰乱互联网拥塞控制并且会引发一些问题。第一个问题就是拥塞崩溃。当网络流量的一个更大的部分是由UDP,网络拥塞控制将变得不那么有效。因此,网络拥塞期间,这些UDP的应用程序可能会导致基于tcp的应用程序,比如web、ftp和电子邮件停止数据传输。更多的关于这个问题担忧已经在Ref里讨论了。
最近,为了解决上述问题,人们提出了很多方法应用TCP拥塞控制一个UDP数据包流。在这些方法中,多媒体流媒体应用程序使用UDP套接字发送和接收数据包和“TCP友好”或“TCP-like”拥塞控制协议来控制何时到UDP套接字发送数据。因为很难证明这些方法能在任何给定的网络条件下实现真正的TCP拥塞控制,所以这些方法通常被称为“TCP友好”或“TCP-like”。
提供真正的TCP拥塞控制,但没有应对延迟敏感的流的TCP错误控制包却只有容错包，因此我们设计并实现了UDTCP套接字在FreeBSD 4.8。UDTCP套接字是一种新型的套接字。UDP和TCP套接字的属性,适用于多媒体流媒体应用而不是那些不适合UDP和TCP的应用程序。UDTCP套接字属性包括(1)数据报(即与TCP的字节流服务,应用程序数据保存的消息边界),(2)真正的TCP拥塞控制(即数据包发送下真正的TCP拥塞控制),(3)没有强制TCP错误控制(即丢失/损坏的包不需要强行转播的发送主机),和(4)没有强制TCP无序包re-sequencing(即无序的包不需要强行延迟在TCP重新组装队列)。因为这些属性,UDTCP套接字非常适合多媒体流媒体的应用。
本文的作用如下。第一个是关于协议设计。我们创建一个新类型的套接字(UDTCP)使用TCP拥塞控制,但没有TCP错误控制交通流对延迟敏感的容错数据。但是运输流是100%的TCP友好没有造成伤害的网络拥塞控制,因为默认的内核使用TCP拥塞控制。第二个作用是关于协议。我们提出一个新颖的和简单的实现UDTCP套接字。在FreeBSD 4.8,我们可以把TCP套接字实现转换成UDTCP套接字实现通过添加、修改或删除只有43行TCP套接字实现的C语句。
2 .相关工作
已经有很多关于TCP拥塞控制适用于UDP数据包流的方法被提出。在这些方法中,一个多媒体流应用程序使用UDP套接字发送应用程序数据,并实现了一个“TCP-like”或TCP友好的拥塞控制机制在用户级控制的时机发送应用程序数据。如果需要,RTP报头可以用来携带有用的控制信息与数据(如序列号),而且还有许多控制数据包可以用来发送和接收应用程序之间交换控制的信息。这些提议的方法可以分为两类,第一类是TCP或equation-based模拟，第二个是模型。
在第一类,调节发送速率的UDP数据包流,有一种方法可以安装视窗或比率。基于这种方法的窗口,如TCP,通过维护拥塞窗口大小变量(类似于BSD cwnd TCP实现)来控制当前发送UDP数据包流。我们的目标是模拟TCP的拥塞窗口更新算法使它尽可能密切。基于这种方式的比率能保持一个速度变量,并使用TCP的加法和乘法减少(AIMD)增加原则来更新它。
在第二类,建议的方法是尝试TCP拥塞控制模型的稳态行为,并使用该模型实现吞吐量之间的关系,比如一个TCP连接丢包率,和往返时间(RTT)。UDP数据包流TCP友好,这种方法会不断衡量当前的丢包率和RTT UDP数据包流,使用派生的关系来计算当前可用带宽的公平份额UDP数据包流,然后使用一个简单的计划发送UDP数据包。
这些现有方法实现和UDTCP套接字的方法之间有很大的差别。在这些现有的方法中,多媒体流媒体应用程序生成的数据传输在UDP数据包中(即使用UDP报头)。这些UDP数据包发送的时间是由用户级控制器控制,试图模拟TCP的行为。对于发送主机RTT估计和ACK序列号(这两个需要模拟TCP的行为),接收主机需要不断地发回额外的UDP数据包,用来扮演相同的角色作为TCP ACK包。由于UDP没有自动重新发送数据丢失,数据进行了UDP包不需要强行转播的。此外,由于UDP不re-sequence无序的数据接收主机,无序的数据不需要强行放到一个重组的队列和遭受不必要的延误。
相比之下,在我们UDTCP套接字的方法中,数据能在TCP数据包中被传输(即使用TCP报头)。这些TCP数据包发出真正的TCP拥塞控制,已经在内核中实现。使用TCP协议以来,为了避免强行中继数据丢失,数据从套接字发送缓冲区中删除后立即发送。避免遭受不必要的延误在接收主机数据到达时的秩序,在我们UDTCP套接字的方法中,数据到达时将绕过重组的队列。
- UDTCP套接字的设计和实现
为了使用TCP拥塞控制传输容错数据和消除对延迟敏感的流,但需要实现一个复杂的“TCP-like”或“TCP友好”在流媒体应用程序下的协议方案,我们提出一个新颖简单实现轻松地创建一个新的套接字的类型的方法来适合这样的应用程序。这种新型的套接字叫做“UDTCP套接字”,是在内核中实现的。
一种多媒体流媒体应用程序可以简单地注入其数据UDTCP套接字只要UDTCP套接字可以接受更多的数据。数据注入UDTCP套接字传输的TCP包下真正的TCP拥塞控制。虽然传输数据包是TCP数据包(如使用TCP报头),但因为我们保存应用程序数据的消息边界和不会自动重新丢失的数据,所以它们拥有UDP数据包的属性。
UDTCP套接字的设计和实现非常简单,几乎与TCP套接字相同。事实上,我们重用内核TCP套接字实现,只有四个小改变TCP套接字转换成UDTCP套接字。只有43行C语句的原始的TCP套接字实现需要修改,补充,或删除。这个数字比9708小,这是C语句的数量在FreeBSD的TCP套接字营建4.8操作系统。图1显示了四个变化,对TCP套接字实现。这三种变化(变化1、2和3)对控制路径发送TCP数据包从发送主机接收主机。一个变化(改变4)的控制路径接收TCP应答数据包的发送主机。解释这四个修改如下:
变化1是关于套接字在发送主机发送缓冲。这一改变的目的是两个褶曲。首先,我们要保存应用程序数据的消息边界。由流媒体应用程序生成的数据通常是一个音频或视频流。这样流通常是由许多帧。例如,一个MPEG视频流可能由许多我,P,和B帧。为了方便在接收端解码帧格式,通常这些帧作为单独的UDP传输消息。因此UDTCP套接字还希望能够保存消息边界。
图 1
图1的四个微小变化是实现udtcp协议到TCP套接字的过程。
第二个改变是关于对TCP在接收主机重新组装队列。产生这一变化的原因是,我们想要一个无序的包不能推迟抵达TCP重新组装队列。相反,当它到达时,我们希望它(实际上,消息由)可立即在多媒体流媒体应用程序可用。传统上,因为TCP提供了一个可靠的和依次交付服务,包丢失时,传入的无序的数据包必须放入重组的队列等待丢失的数据包是转播的到来。然而,容错流媒体应用,对延迟敏感但推迟已经到达的数据包将不必要地增加了机会,他们将错过播放时间。
为了避免延误由于数据包接收主机重排导致的问题，同时保持TCP拥塞控制,我们建议以下TCP接收主机的设计。该设计可以描述的三个步骤。只有一个小改变需要原始的TCP套接字实现的第二个和第三个步骤。
第一,继续TCP拥塞控制,和正常一样,传入无序的TCP包仍然接受默认TCP接收过程。也就是说,它是投入TCP重新组装队列并等待填充的洞(即等待丢失的数据包被重新传输,到达)。
第二,让多媒体流媒体应用程序快速访问一个已经到了包,TCP数据包到达时,我们复制的消息由它并立即排队复制到套接字接收缓冲区。
第三,当失去和转播的包终于来临,导致TCP重新组装上的洞队列满了,现在我们出列序列现在对他人予以TCP数据包从TCP重新组装队列但不排队的消息由这些TCP数据包在TCP套接字接收缓冲区。传统上的TCP设计,这些信息应该排队到套接字接收缓冲区,当他们变得有序的时候。然而,因为在第二步这些消息已经排队到套接字接收缓冲区,在第三步中,我们应该抛弃他们。
变化3是套接字在接收主机接受缓冲。这种变化保存收到的消息边界UDTCP套接字应用程序数据的接收缓冲区。如前所述,BSD UNIX的数据包缓冲区结构(mbuf)支持消息边界的选择。它很容易产生这种变化。实现复杂性:(1)使用mbuf消息添加10个C语句UDTCP套接字接收缓冲区的边界选项。
变化4是关于套接字发送缓冲区发送主机和处理接收应答包。
UDTCP套接字发送缓冲区,因为在它们传输以后它们被立即列了出来(改变1所示),我们不应该让收到确认数据包触发的操作从UDTCP退出队列消息套接字发送到缓冲区。
4 .减少排队延迟
通常的多媒体流媒体应用程序对延迟比较敏感，因此,它生成的消息不应该经历漫长的排队延迟UDTCP套接字发送缓冲区。然而,因为UDTCP套接字使用TCP拥塞控制调节应用消息来传播,漫长的排队延迟问题可能发生，如果有许多消息套接字发送到缓冲区中排队等待发送那么网络的可用带宽会突然降低。为了处理这个问题,我们使用以下方法。
在这种方法中,我们限制UDTCP套接字发送缓冲区的大小为只有一个消息。这可以保证只要TCP拥塞控制不超时,消息排队UDTCP套接字发送缓冲区内传播多媒体流RTT之一。一个多媒体流媒体应用程序可以尽可能的地尝试将其生成的消息写入UDTCP套接字。如果套接字发送缓冲区没写满，写操作会成功并且应用程序可以确保消息只是书面将发送一个RTT如果TCP不暂停。另一方面,如果UDTCP套接字发送缓冲区满了，写操作返回的，应用程序可以使用select()系统调用等到套接字发送缓冲区变得不完整。当时,应用程序可以编写当前消息UDTCP插座。如果当前消息已经变得太老了,是有用的,应用程序可以丢弃当前的信息,生成一个最近的一个,写新消息给UDTCP套接字。
图 2
图2为udtcp实例使用的套接字。
因为UDTCP套接字发送缓冲区中的消息列中移除后立即传输,限制UDTCP套接字发送缓冲区的大小只有一个消息并不减少UDTCP连接可以实现的最大吞吐量。相比之下,该属性不能通过TCP套接字完成。传统上,因为TCP提供了可靠的服务,传递应用程序数据可能需要再次,因此必须保持在TCP套接字发送缓冲区,直到相应的应答包的到来。因为应用程序数据写入后只能传输和呆在套接字发送缓冲区,一个套接字发送缓冲区的大小将限制应用程序数据的数量,可以每RTT传播(即动态)。因此,如果TCP套接字发送缓冲区的大小小于可用的网络带宽和RTT的产物,它将成为一个吞吐量限制因素。相反,因为UDTCP套接字并不打算提供一个可靠的服务,它不受吞吐量限制问题困扰，即使我们降低其套接字发送缓冲区大小只有一个消息。
5 .分析
在本节中,我们执行的一个简单的分析在数字上表明,re-sequencing无序在TCP数据包重组的队列应该取消;否则很大一部分传送数据包将不必要的重新组装队列中等待至少一个RTT。(注:因为一个RTT需要恢复丢失的数据包,如果多个数据包丢失在TCP窗口中,out-oforder包可能需要等待超过一个TCP重新组装的RTT队列)。首先,包丢失是均匀分布在传输数据包。也就是说,如果丢包率是1 = N,然后一个接一个的包丢失会发生在N成功发送和接收数据包之后。第二,对于每一个包丢失,TCP快速重新传输和恢复机制总是可以恢复丢失的数据包不会导致TCP超时。基于这些假设,当一个数据包丢失,TCP拥塞控制会减少当前拥塞窗口大小W W = 2,然后由一个增加包每个RTT,直到一个数据包丢失了。
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[505681]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
