CN110622449B - 用于处理网络编码分组的系统和技术 - Google Patents
用于处理网络编码分组的系统和技术 Download PDFInfo
- Publication number
- CN110622449B CN110622449B CN201880031064.4A CN201880031064A CN110622449B CN 110622449 B CN110622449 B CN 110622449B CN 201880031064 A CN201880031064 A CN 201880031064A CN 110622449 B CN110622449 B CN 110622449B
- Authority
- CN
- China
- Prior art keywords
- packet
- frame
- encoded
- frames
- quic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0041—Arrangements at the transmitter end
- H04L1/0042—Encoding specially adapted to other signal generation operation, e.g. in order to reduce transmit distortions, jitter, or to improve signal shape
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0041—Arrangements at the transmitter end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
- H04L1/0076—Distributed coding, e.g. network coding, involving channel coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1657—Implicit acknowledgement of correct or incorrect reception, e.g. with a moving window
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/187—Details of sliding window management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/164—Adaptation or special uses of UDP protocol
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
一种方法包括:将一个或多个QUIC帧再构造为打包帧;并且将网络编码应用于打包帧以生成编码帧。
Description
背景技术
如本领域中已知的,存在提供遍历互联网的流传输集合的协议。一种这样的协议是快速UDP互联网连接(QUIC),其可以建立在UDP(用户数据报协议)之上。
还已知的是,已经尝试将前向纠错(FEC)并入到QUIC协议中。一种QUIC FEC协议利用构建在网络的传输层中的单个XOR恢复分组方法。然而,这种方法的一个问题是分组丢失是高度相关的,因此即使发生丢失时,FEC分组的很大一部分(在某些情况下约为70%)无法恢复任何内容。对于HTTP业务,已经发现简单地重新发送最早的未决分组(即,在某一时间段之后,服务器重传未确认的分组)的方法提供了比发送XOR FEC分组更优的性能。此外,在网络传输层中的集成导致难以对FEC进行改变。因此,现有的QUIC FEC方法不足以用于实时应用,例如,利用Web实时通信(WebRTC)协议的应用。
发明内容
本文所描述的是针对网络编码(NC)快速UDP互联网连接(QUIC)协议的概念、系统、设备和技术。根据这样的技术生成的分组与QUIC兼容。这可以使用下面将要描述的两种技术中的任一种或其组合来实现。另外,本文所描述的概念、系统、设备和技术可以与前向纠错(FEC)技术以及相关的设备和系统一起使用。
在第一技术中,将网络编码应用于已经加密的(或“经密封的”)的QUIC分组。即,整个QUIC分组被编码。
在第二技术中,可以将QUIC帧再构造为所谓的“打包帧”,并且将网络编码应用于“打包帧”以用于生成所谓的“编码帧”,其中每个编码帧具有与一个QUIC分组的有效载荷相对应的大小。
总的来说,对于给定的多个QUIC帧,生成称为编码帧的新的帧。即,不是按照现有技术将这种多个帧放入QUIC分组中,而是生成所谓的编码帧。编码帧包含:原始QUIC帧,其被级联并填充(例如,零填充)到固定大小并使用网络编码编解码器进行编码;多个位,其表示(在填充之前)编码帧报头中的原始长度;以及系数向量(即,包括表示在网络编码中使用的编码系数的信息的向量)。
在实施例中,系数向量也可以被认为是编码帧报头的一部分。在可以使用所谓的显式反馈的情况下,编码帧中还包括编码帧报头中的编解码器的反馈。在使用所谓的推断反馈的情况下,编码帧报头中不包括编解码器的反馈。编码帧可以包含或不包含FEC数据。
当然,也可以将系数向量认为是尾部的一部分。将系数向量放在尾部中。
在实施例中,编解码器的反馈被提供为解码器基于已经能够对其进行解码的分组而生成的元数据。基于该反馈,编码器可以关闭/缩小其窗口。在推断方法中,基于QUIC ACK生成编解码器的反馈。
得到的编码帧的大小可以是最大QUIC分组有效载荷大小。因此,当编码帧包括在分组中时,将没有其他QUIC帧适合。该分组被提供给QUIC处理器(即,能够根据QUIC协议生成QUIC分组的处理器),该处理器将处理像任何其他分组一样的具有编码帧的如此构造的分组。
在接收侧,响应于客户端接收到包含编码帧的分组,使用网络编码编解码器对编码帧进行解码,由此恢复原始QUIC帧。然后传递原始QUIC帧以进行处理。如果尚未解码该帧,则该帧被缓冲,直到可以对其进行解码为止。
在实施例中,当不能对帧进行解码时,可以停止对整个分组的处理。在这种情况下,QUIC不会发送针对该分组的可能会触发从服务器重新发送的ACK。
在另一方面,如果帧被缓冲但是存在对接收分组的确认,则未经修改的QUIC实现方式将尝试处理后面的分组,从而可能导致数据重新排序。
应该认识到,在根据本文所描述的概念操作的实施例中,当接收到具有经编码的QUIC分组作为有效载荷的UDP分组时,必须首先对其进行解密。解密之后,可以确定数据是否可以被解码。如果仍无法完成解码,则未经加密的数据(其不再是分组,而是数据块)可以被缓冲。
本文所描述的一些概念和技术可以在QUIC内实现(即,该技术可以对QUIC而言在本地)。因此,这种技术有时在本文被称为“内部”技术,表示为了实现这样的技术,适配或修改现有的QUIC协议是必要的。然而,还应该认识到,本文所描述的一些概念和技术可以在QUIC外部实现(即,该技术不需要对QUIC而言在本地)。因此,这种技术有时被称为“外部”技术,表示不需要改变QUIC协议来利用这样的技术。应当理解,前述的内部技术和外部技术可以单独或组合使用(即,内部技术和外部技术可以针对同一分组或分组集合使用)。
附图说明
根据以下附图描述,可以更充分地理解前述特征,其中:
图1是根据现有技术QUIC协议的基线分组发送和接收生命周期的流程图;
图1A是常规QUIC分组的图;
图2是示出FEC XOR处理的缺点的分组序列的图;
图3是根据QUIC协议生成、发送和接收编码分组的过程的流程图;
图3A是由图3的过程产生的类型的说明性编码分组的图;
图3B是被配置为生成、发送和接收根据图3的过程生成的分组的系统的框图;
图4是用于生成、发送和接收编码分组的过程的另一实施例的流程图;
图4A是前向纠错(FEC)生成器过程的流程图;
图4B是具有推断反馈的说明性网络编码(NC)编码帧的图;
图4C是具有显式反馈的说明性NC编码帧的图;
图4D是被配置为生成、发送和接收根据图4的过程生成的NC编码分组的系统的框图;
图4E是被配置为生成、发送和接收根据图3和图4的过程的组合生成的编码分组的系统的框图;
图5是具有可以是与图1A的常规QUIC分组相同或相似的结构的常规QUIC分组的框图;
图5A是具有显式反馈的经编码的(或重组帧的)QUIC分组的框图;
图5B是具有推断反馈的经编码的(或重组帧的)QUIC分组的框图;
图6是示出根据现有技术FEC XOR的在服务器与客户端之间的分组流的示例的序列;
图6A是示出根据QUIC网络编码(NC)FEC协议的在服务器与客户端之间的分组流的示例的序列;
图7是用于流级别网络编码(NC)FEC的分组的图,其中示出了数据被划分为相等大小的块并且被打包到具有单个流帧的帧中;
图7A是用于流级别NC FEC的分组的图,其中示出了数据被划分为相等大小的块并且被打包到具有一对流帧的帧中;以及
图8是根据NC QUIC协议的通信系统的框图。
具体实施方式
在描述针对具有网络编码(NC)前向纠错(FEC)的快速UDP互联网连接(QUIC)协议的概念和技术以及相关设备和系统之前,先解释一些介绍性概念和术语。
如本文所使用的,术语“分组”通常指代通过网络发送的数据单元。应该认识到,存在不同类型的分组,并且每种不同类型的分组可以具有特定结构。
例如,“用户数据报协议(UDP)分组”(或更简单地为“UDP分组”)是公知的并且包括控制信息(例如,网络地址、端口号序列信息等),该控制信息典型地包括在分组的称为报头的部分中。控制信息也可以包括在尾部中。
在另一方面,“QUIC协议分组”(或更简单地为“QUIC分组”)在UDP分组的内部(即,在UDP分组的有效载荷部分内)行进。因此,QUIC分组被定义为可以由QUIC接收器解析的形式正确的UDP有效载荷。QUIC分组的大小典型地与具有MTU(最大传输单元)大小的UDP分组的有效载荷的大小相对应(参见https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include text=1)。因此,QUIC分组的结构不需要在分组报头中包括任何地址或端口号(因为该信息已经包括在UDP分组报头中)。QUIC分组的内容在https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=1处指定。QUIC分组包括有效载荷部分以及其他,该有效载荷部分包括用户或应用数据。该数据可以被组织为一个或多个自识别帧的序列。QUIC分组的有效载荷部分是经加密的。
分组可以由“帧”组成。通常,帧可以被认为是其自身的分组有效载荷的分段。在分组的有效载荷内的不同的帧可以包含不同的信息。因此,有时参考帧中包括的信息的类型来指代帧。例如,“应用数据帧”(或更简单地为“数据帧”或“流帧”)包括数据(即,流帧或数据帧是包括(或“携带”)应用数据的一个或多个区段的帧)。数据控制帧(或更简单地为“控制帧”)可以包含控制信息(例如,协议数据)。例如,“ACK帧”(其包含确认相关的信息)是一种类型的控制帧。
应该认识到,在某些实例中,帧可以部分地包括其他帧。还应该认识到,帧可以包含多种不同类型的数据/信息。因此,例如,在一些实例中,帧可以包括应用数据和控制信息两者。例如,当帧由具有完全不同的帧类型的其他帧组成时(例如,帧可以由数据帧和控制帧两者组成),就可以发生这种情况。
如本文所使用的,术语“经编码的QUIC分组”(或更简单地“编码分组”)指代已经对其至少一些部分应用了网络编码的QUIC分组。例如,并且如下面将进一步详细解释的,在一些情况下,整个QUIC分组被编码(例如,参见图3A)。在其他情况下,仅处理QUIC帧(即,QUIC分组的有效载荷部分)而不是处理整个分组(例如,参见图4B、图4C、图5B、图5A)。
因此,存在至少两种不同类型的经编码的QUIC分组,每种由不同的技术形成。
一种类型的经编码的QUIC分组被称为“外部编码的QUIC分组”,表示已经对其应用了网络编码的QUIC分组(其包括所有有效载荷报头和分组部分)。形成外部编码的QUIC分组的技术有时被称为分组级别编码,因为在这种方法中,编码是对用于形成QUIC分组的协议的输出执行的。换言之,可以说用于提供外部编码的QUIC分组的技术对UDP分组的有效载荷执行编码,其中UDP分组有效载荷是QUIC分组。
第二种类型的经编码的QUIC分组被称为“内部编码的QUIC分组”,表示具有已经对其应用了网络编码的有效载荷的QUIC分组。因此,与外部编码的QUIC分组相反,在内部编码的QUIC分组中,与对整个分组进行编码相反,使用了其中仅对QUIC分组有效载荷进行编码的技术。因此,该技术有时被称为帧级别编码。
如本文所使用的,术语“QUIC帧”指代在QUIC分组的有效载荷部分中的帧。
根据本文所描述的概念和技术,可以将QUIC帧“再构造”为所谓的“打包帧”。
可以对这样的打包帧应用网络编码技术来生成编码帧。因此,QUIC帧被一起分组到打包帧中以装填QUIC分组有效载荷,并且编码帧指代通过将网络编码应用于打包帧而生成的帧。因此,编码帧可以包含原始数据,并且是原始数据帧的网络编码组合(即,编码帧可以包括来自若干不同QUIC分组的帧中的数据——例如,编码帧=经编码的分组1帧+经编码的分组2帧)。可替代地,编码帧可以是用于前向纠错的额外帧。因此,编码帧可以包含提供给接收器的新信息,或者可以是FEC数据。
总的来说,本文公开了用于根据快速UDP互联网连接(QUIC)协议来生成和接收编码分组的两种技术。在第一技术中(下面结合图3示出并描述,其中所得到的编码分组具有例如图3A中示出的形式),编码是在QUIC外部进行的。如上面所指出的,由于该技术是在QUIC外部进行的,因此有时被称为“外部”技术;即,不一定需要对用于形成QUIC分组的现有过程进行任何改变。当然,应该认识到,如果对用于生成QUIC分组或QUIC帧的过程进行了更改,则仍然可以使用该技术。
在第二技术中(在图4中示出,其中所得到的分组具有例如图4B、图4C或图5A或图5B中任一个中示出的形式),编码是在QUIC内部进行的;即,该技术的实现要求对用于形成QUIC帧和/或分组的常规过程进行一些改变。如上面所指出的,由于该技术是在QUIC内部进行的,因此有时被称为“内部”技术。
现在参考图1,示出了根据常规QUIC协议操作的系统的基线分组发送和接收生命周期的流程图。因此,图1示出了根据具有公共报头的常规QUIC协议(例如,如图1A和图5中所示)的处理。
现在参考图1A,现有技术QUIC分组500包括公共报头501、密码签名502(其也可以被称为密码签名报头502)和有效载荷504。公共报头501可以包括字段,例如,公共标志字段、连接ID字段、版本信息字段、多样化随机数(nonce)字段以及标识分组号的字段。密码签名报头502可以包括用于解密分组的信息。有效载荷字段504可以包括分组的数据有效载荷。数据分组的有效载荷包含帧的序列。数据有效载荷504可以在传输之前被加密。在实现基于XOR的FEC的现有技术系统中,FEC组号可以包括在公共报头501中。
现在参考图2,在现有技术QUIC UDP分组910a-910d的序列之后是前向纠错(FEC)分组912。在利用基于XOR运算的FEC解决方案的常规QUIC应用中,对于分组的特定集合,计算有效载荷的异或总和,该总和在冗余FEC分组中被发送。如果单个分组丢失,则可以从XOR运算中使用的其余分组以及FEC分组中恢复其内容。
然而,如果丢失了多于一个分组,当在XOR运算中使用的其余分组中的一个由于基于帧的重传和基于分组的丢失也永久丢失时,接收器不可能重建丢失的分组。因此,多于一个的分组丢失将意味着FEC分组对于重建丢失的分组将是无用的。
与图1和图2的现有技术(其分别生成并利用图1A的分组结构)相反,本文下面所描述的技术使得能够使用任意数量的FEC分组。
例如,本文下面所描述的技术中的一种使得能够使用网络编码(NC)以生成包含用于前向纠错的信息的任意数量的分组(即,NC FEC分组)。如将根据下面的描述变得显而易见的,可以使用下面描述的图3或图4的架构/技术来生成任意数量的FEC分组。
因此,简单地说,当根据常规的QUIC FEC协议进行操作时,如果仅丢失一个分组(例如,图2中的分组910d),则系统可以恢复信息——例如,通过发送分组910a-910c的总和(即,可以经由XOR来完成恢复)。
然而,在丢失多个分组(例如,图2中的分组910b和910d)的情况下,则系统不能使用总和(即,XOR)来恢复信息,因为该方案只可以恢复一个丢失的分组。即使重传丢失的分组的内容,情况也是如此,因为重传的数据将与最初计算XOR时使用的分组不同。即,现有技术QUIC FEC系统不是重传相同的分组(这将允许恢复信息),而是发送包含可重传的帧的新的分组。因此,当多个分组被丢弃时,分组的相同混合对于FEC XOR解码操作是不可用的。
因此,可以理解,该现有技术方法的问题在于,虽然丢失发生在分组级别,但是重传发生在帧级别。由于常规QUIC永远不会两次发送相同的分组,因此如果丢失了多于一(1)个分组,则XOR FEC会由于常规QUIC的基于帧级别的重传而没有帮助。
现在参考图3,示出了具有分组级别网络编码(NC)前向纠错(FEC)的QUIC分组发送和接收生命周期的流程图。
在图3中示出的技术中,网络编码被应用于“经密封的”(即,经加密的)QUIC分组。即,在发送侧,在应用NC FEC之前,执行加密过程以生成常规QUIC分组。相反,在接收侧,首先使用NC FEC恢复分组,然后对分组进行解密。因此,可以将该技术描述为可以在QUIC的“外部”实现(即,该技术对QUIC而言不在本地)。
现在转到图3,发送侧处理根据分组级别网络编码(NC)前向纠错(FEC)来生成诸如下面图3A中示出的分组之类的编码分组(即,外部编码的QUIC分组),该处理开始于新的流帧300和新的控制帧302被组合以生成具有公共报头306a和帧306b的分组306。执行加密操作308以提供具有公共报头部分306a和经加密(或密封)的部分310b的QUIC分组310。分组310被提供给生成编码分组的网络编码FEC生成器312。
然后,提供分组(例如,具有图3A的形式的分组)以通过UDP连接进行传输。应该认识到,在每N个分组之后发送一个或多个NC FEC分组。显著地,如将在下面进一步描述的,在实施例中,N可以在传输期间改变。
还应该认识到,分组级别网络编码前向纠错使用显式反馈。在显式反馈方法中,客户端显式地发送答复从而指示接收到哪些分组。这种显式反馈出现在经编码的响应的报头中(例如,编解码器的反馈包括在编码分组的报头中)。即,当客户端向服务器发送经编码的分组时,编解码器的反馈也将包括在报头中,该反馈将由服务器在其答复中使用。服务器在它(即,服务器)生成进一步的经编码的分组时将使用该反馈。下面将结合图3A描述包括显式反馈的编码分组的示例。
应该进一步认识到,利用本文所描述的架构,任何数据修改都可以适用,包括数据/分组生成和数据丢弃。这使得可以将任何类型的FEC算法处理添加到QUIC。因此,可以保持所有可能的技术开放以用于创建与FEC兼容的编码分组。这种技术包括但不限于XOR、完整RLNC和基于滑动窗口NC的分组生成。
在接收侧,在NC FEC接收器/缓冲器322中接收UDP传输分组,该NC FEC接收器/缓冲器322利用FEC重新构建分组以提供具有公共报头部分324a和经密封的部分324b的分组324。分组的经密封的部分在326处打开,以提供具有公共报头328a和帧328b(其为与帧306b相同的帧)的分组328。该分组被提供给接收分组处理机332,该处理机332将确认帧334提供回发送方。同样在330处,将确认帧提供给发送分组处理机314,该发送分组处理机314进而将信息提供给拥塞控制模块318和重传帧336。
鉴于本文所提供的描述,本领域普通技术人员现在将认识到,根据本文结合图3所描述的技术生成的分组可以在利用QUIC协议的实际系统中使用。此外,在阅读了本文提供的公开内容之后,本领域普通技术人员还应该认识到,例如,可以应用网络编码的不同方法以生成编码分组。例如,可以使用滑动窗口、完整网络编码、稀疏网络编码、系统编码或前述技术的组合。不同的方法可以使用不同量的数据来进行编码。滑动窗口使用对其应用了网络编码的分组的窗口以生成编码分组。滑动窗口也可以对一代(即,对一组分组)应用,或者可以是无代的(generationless)。完整网络编码技术对给定代中的所有分组进行编码。稀疏网络编码技术仅使用一代中的分组中的一些。系统编码方法首先发送原始分组,然后发送编码后的分组以用于擦除/纠错。
现在参考图3A,可以利用图3的处理生成的类型的编码分组340包括分组报头342、编码报头/系数向量344和QUIC分组348。分组报头342可以包括上面所描述的反馈信息。
现在参考图3B,响应于来自NC FEC QUIC客户端358的请求,根据在图3中描述的发送侧技术,NC FEC QUIC服务器350生成N个网络编码(NC)分组352,随后是一个或多个NCFEC分组354。应该认识到,在每N个分组352之后发送一个或多个NC FEC分组354。显著地,在实施例中,N可以在传输期间的任何时间改变或者可以是恒定的。N可以(或可以不)改变的方式取决于实施例的具体实现方式(例如,考虑到包括但不限于信道特性的许多因素)。分组352、354经由UDP连接被发送到NC FEC QUIC客户端358,该NC FEC QUIC客户端358包括能够根据图3的技术进行操作并且因此能够解析编码分组(例如,图3A的包括QUIC分组的编码分组)的接收器。如结合图3所指出的,在每N个NC分组352之后发送一个或多个NC FEC分组354。在一个实施例中,经由XOR逻辑来实现FEC。
现在参考图4,示出了具有帧级别编码的分组发送和接收生命周期的另一实施例的流程图。应该认识到,虽然图4示出了滑动窗口网络编码技术,但是也可以使用其他网络编码技术。此外,虽然在使用滑动窗口技术的情况下,通常不使用显式反馈。然而,应该理解,在其他实施例中,使用其他类型的网络编码(即,除了滑动窗口技术之外的网络编码)可以是优选的(或甚至是必要的),在这种情况下,利用显示反馈可以是优选的(或甚至是必要的)。
在图4中示出的技术中,(例如,在FEC生成器中的)再构造用于将QUIC帧捆绑(或分组)到对其应用了网络编码(NC)以生成编码帧(即,NC编码帧)的一个QUIC分组有效载荷大小的帧(本文称为打包帧)中。可以认为该技术是在QUIC内部实现的(即,该技术对QUIC而言在本地)。因此,如上面所指出的,图4的技术在本文有时被称为内部技术(因为该技术在QUIC处理的内部)。
如将在下面描述的,在实施例中,图4的说明性技术生成具有编解码器报头(例如,系数向量和来自编解码器的某些其他编解码器相关的信息)的NC编码帧(图4B、图4C、图5A、图5B)。即,将系数向量构建到帧中。因此,图4的技术可以生成包括帧的分组,该帧具有图4B中示出的形式(推断反馈)或图4C中示出的形式(显式反馈)。
在反馈的情况下,当使用滑动窗口编解码器时,有必要知道在发送方一侧哪些经编码的帧由客户端接收,因为在对要发送的下一帧进行编码时要使用该信息(例如,如果先前的帧未被接收,则可以在对下一帧的编码中包括这些帧)。
为了获得这种反馈,存在两种方法。在称为显式方法的第一方法中,客户端显式地发送答复从而指示接收到哪些帧。如上面所讨论的,这种答复出现在经编码的响应的报头中。即,当客户端向原始服务器发送经编码的帧时,报头中还包括编解码器的反馈,该反馈将在服务器的答复中使用。
在称为推断方法的第二方法中,在原始发送方中,存储了在哪个分组中发出了哪个经编码的帧。然后,依赖于QUIC分组确认系统,该系统会告知是否接收到分组。如果接收到分组,则基于关于哪个分组中发出了哪个帧以及接收到了哪个分组的知识,来重新创建客户端将提供的反馈。
因此,显式方法要求客户端每次在接收到经编码的帧时向服务器发送包含反馈的响应。因为反馈在经编码的帧的报头部分中行进,所以响应必须包含一个这样的经编码的帧(其可以包含或可以不包含附加数据,即,在一些实施例中,经编码的帧可以仅包含反馈而不包括任何有意义的数据)。如果服务器到客户端和客户端到服务器的信道具有相似或基本相同的业务量(例如,在p2p文件共享应用中),则该技术很好地工作。
图3与图4的技术之间的一个不同之处在于,在图3的方法中,QUIC不了解编码分组(并且如上面所指出的,由于编码发生在密封之后,因此在QUIC外部实现)。
另一方面,在图4的技术中,生成并发送有效的QUIC帧(即,能够经由QUIC处理的帧),并且在密封之前进行编码。
如将根据下面的描述变得显而易见的,在图4的技术中,发送方要求反馈。可以以两(2)种方式生成这种反馈:1)经由使用QUIC ack帧的隐式/推断技术,并且基于生成编解码器(例如,Kodo编解码器)可以使用的反馈向量;以及2)通过显式地发送反馈向量。
如上面结合图1-图1A所解释的,应当理解,在现有技术方法中,首先对分组进行加密(或“密封”),然后利用FEC码(即,XOR FEC码)对分组进行编码。此外,在现有技术方法中,对于每个分组使用相同的码。另外,在现有技术方法中,QUIC也不知道额外的FEC分组。
然而,在图4中示出的技术中,首先使用网络编码对QUIC帧进行编码(即,在内部对分组进行编码),然后对分组进行加密(或密封)。
当然,应该认识到,利用本文所描述的架构,可以保持所有的可能性开放以用于创建编码分组,包括创建与FEC兼容的编码分组。因此,基于XOR、完整RLNC、滑动窗口NC的分组生成都是可能的。还应该认识到,虽然图4示出了滑动窗口技术,但是也可以使用其他网络编码技术。此外,虽然在使用滑动窗口技术的情况下,通常将不使用附加的FEC分组,但是应该理解,在其他实施例中,使用其他类型的网络编码(即,除了滑动窗口技术之外的网络编码)可以是优选的(或甚至是必要的),在这种情况下,利用附加的FEC分组可以是优选的(或甚至是必要的)。
现在转到图4,示出了用于生成分组的发送侧过程,该分组具有包括反馈(例如,如图4C和图5A中示出的显式反馈或如图4B和图5B中示出的隐式反馈)的NC编码帧,其中图4的特定架构/技术示出了推断反馈。该过程开始于将数据分组到流中,使用流帧来转发流,并且将新的流帧400和新的数据控制帧402提供给编码生成器(此处示出为FEC生成器404)。
编码生成器404接收一个或多个QUIC帧,以对QUIC帧404a进行再构造以提供分组帧,然后在编码器404b中将该分组帧编码为一个分组大小的编码帧406。应该认识到,编码帧406可以包含一个或若干个QUIC帧。
简要地转向图4B,说明性编码帧406包括:内部编码帧报头(“内部CFH”)452,该内部编码帧报头452包括原始长度部分(即,表示诸如帧400、402之类的原始帧(在诸如零填充之类的填充之前)的长度的多个位);外部编码帧报头(“外部CFH”)454,该外部编码帧报头454包括系数向量;以及经编码的数据部分450,该经编码的数据部分450包括一个或多个QUIC帧451。因此,每个编码帧具有至少一个内部CFH和一个外部CFH。
在替代实施例中,应该认识到,包含在内部CFH和/或外部CFH的部分内的数据可以分布在帧的其他部分中。因此,在实施例中,编码帧406可以至少包括:第一帧部分,其具有包括一个或多个QUIC帧和原始长度的经编码的数据;以及第二帧部分,其具有系数向量(即,包含在网络编码中使用的编码系数的向量)。应该认识到,原始长度必须包括在编码帧的经编码的数据部分内,否则当从多个分组重建数据时,将不可能知道将哪个原始长度应用于哪个分组。还应该认识到,在一些实施例中,可以将系数向量构建到编码帧中,并且系数向量可以是编解码器报头的一部分(或全部)。
还应该认识到,QUIC帧被再构造为打包帧。可以对这样的打包帧执行滑动窗口网络编码来生成编码帧。因此,编码帧可以包含去往接收器的新信息,或者编码帧可以是FEC(前向纠错)帧/数据。
在一些实施例中,可以使用(例如,在Kodo库中可用的类型的)滑动窗口编码器。在实施例中,滑动窗口编码器可以以以下方式操作:首先,向编码器馈送新的数据(例如,新的流帧,并且特别是已经被再构造以形成打包帧的流帧),并且响应于此而增加滑动窗口编码器的窗口大小;发送方将分组发送给接收器,并且在接收到该分组后,接收器将ACK分组发送回发送方;第二(在使用推断反馈的情况下),根据ACK生成滑动窗口反馈——例如,以二进制向量表示的ACK(当然,应该认识到,在显式反馈的情况下,由于接收器显式地发送回反馈,因此不一定需要生成反馈);第三,滑动窗口编码器接收反馈,并且响应于此可以减小滑动窗口的大小。因此,该技术被称为滑动窗口技术,因为新的分组被添加到编码器并且旧的分组被移除。
再次返回图4,应该认识到,FEC生成器404消耗数据并且异步地生成经编码的数据。如果在决策框408中确定允许发送,则形成具有公共报头部分410a和帧部分410b(例如,具有至少一个内部编码的帧)的分组410。
然后,对帧进行加密(即,“密封”)412,并且在输出处提供具有公共报头部分410a和经密封的部分414b的分组414,以用于通过UDP连接传输到客户端。发送分组处理机416接收与所发送的分组相关的信息。这样的信息可以例如是所发送的分组的副本。
可以通过图4的过程形成的分组414的示例在图5A和图5B中示出。
在接收(或客户端)侧,经由过程432接收并打开(即,解密)分组430以揭露编码帧434。在接收到的分组430与所发送的分组414相同的情况下,编码帧434将与编码帧406相同。编码帧434被提供给FEC接收器436,该FEC接收器436对帧进行缓冲436a、(例如,利用网络编码)解码436b、以及解帧436c以提供解码帧438。在接收到的分组430与所发送的分组414相同的情况下,帧438将与帧400(如果包括帧402则与帧402)相同。
接收分组处理机442将确认444提供回发送侧。确认440也被发送到发送侧发送分组处理机416。显著地,发送分组处理机416不需要发起重传帧449沿着路径447的重传。发送分组处理机416还向拥塞控制模块420提供信息,这反过来有助于决定是否允许发送。
显著地,通过消除从发送分组处理机416到重传帧过程449的反馈447的需要,系统禁用了流(数据)帧的重传,因为在图4的技术中,FEC生成器404处理丢失的分组。
这与现有技术方法相反,如上面结合图1-图2所描述的,现有技术方法对帧进行重传(即,在图1的现有技术方法中,系统发送包含可重传的帧的新的分组)。
应该认识到,滑动窗口网络编码编码器是已知的。通常,在这种编码器中使用的窗口大小可以在1到N的最大窗口大小之间变化,其中N在理论上可以是无限大的数字。本领域普通技术人员将认识到如何在实际系统中选择N的值。
在使用如图4中描述的滑动窗口网络编码技术的情况下,要求窗口大小管理策略。特定的窗口大小管理策略的选择将至少部分地取决于采用滑动窗口网络编码技术的系统的特定特性。在一些情况下,期望增加在滑动窗口编码器中使用的窗口的大小,而在其他情况下,期望减小窗口大小。
在图4的示例实施例中,可以使用以下策略。如果窗口大小小于预定义的极限Wmax,并且不期望发送具有接下来要生成的编码帧的附加FEC数据,则允许增加窗口大小。如果允许增加窗口大小并且存在可用的新的打包帧,则增加窗口大小以容纳这种新的打包帧。
通常,期望将窗口大小保持为较小的以减少计算开销所要求的时间量。因此,一旦发送方确定特定的打包帧已经到达接收器(意味着接收器能够解码提供给其的编码帧中的至少一些以便获得该打包帧),则该打包帧可以从窗口中移除,由此减小了窗口的大小。
在一些实例中,可能会将窗口大小减小到值一(即,窗口大小=1)。在实施例中,将窗口大小设置为等于值一(例如,将预定义的极限Wmax设置为一)可能是优选的或甚至是必要的。不管窗口大小如何达到一,在这种情况下,FEC生成器404仅在单个打包帧上操作。由于要求至少两(2)个帧来执行网络编码,因此这意味着FEC生成器提供不具有任何编码的帧(即,编码帧406实际上不包含任何编码)。因此,实际上,打包帧被发送而没有任何修改。
在本文结合图4所描述的说明性技术中,如果往返时间(RTT)为使得接收确认比创建新的打包帧更快(例如,RTT接近零),则滑动窗口的窗口大小可以取值一(1)。此外,如果信道上的损耗大于或等于某个预先确定的百分比(例如50%),则窗口大小可以为一(1),因为在这种情况下可能期望将所有分组重复一次或若干次。然而,应该注意的是,在这种情况下,虽然窗口大小可能达到一或被设置为一,但取决于诸如RTT值之类的其他因素,窗口大小并不需要假定为值一。
在信道上的损耗大于或等于50%,并且RTT相对较长,使得接收ACK并不比创建新的打包帧更快的情况下,可能期望利用大于一的窗口大小(即,使得编码分组被发送)。通常,窗口大小将随信道的随机性而趋于增加(不可预测的损耗数量越多,RTT越长),并且窗口大小将随着网络变得更加稳定且可预测而趋于减小。
应当理解,在上述因素或其他因素(例如,包括但不限于特定应用/系统的要求/限制、RTT、信道损耗以及其他信道和系统特性)的任意组合的情况下,窗口大小可以假定为值一(1)。如上面所指出的,也可以将窗口大小简单地设置为一(例如,在已知RTT接近于零的情况下)。
鉴于以上,应该认识到,找到优选的(或者理想的、最佳的)窗口大小管理策略是重要的。取决于特定应用的要求,可以使用不同的窗口大小调整策略(即,与上面所描述的不同),在这种情况下,窗口大小可能以与上面所描述的示例不同的方式达到(或被设置为)值一(1)。
不管窗口大小如何达到一,当存在为一的窗口大小时,不会对分组进行编码。因此,在这种情况下,系统可以生成一些或甚至所有未经编码的分组并与其一起操作。
鉴于本文所提供的描述,本领域普通技术人员现在将认识到,根据本文结合图4所描述的技术生成的(无论是编码的还是未经编码的)分组都可以在利用QUIC协议的实际系统中使用。此外,在阅读了本文所提供的公开内容之后,本领域普通技术人员还应该认识到,例如,可以应用网络编码的不同方法(即,与图4和图4A中示出的滑动窗口技术不同)来生成编码帧。例如,除了滑动窗口之外,还可以使用完整网络编码、稀疏网络编码、系统编码或前述技术中任一项的组合。不同的方法可以使用不同量的帧来进行编码。滑动窗口使用对其应用了网络编码的帧的窗口以生成编码帧。滑动窗口也可以对一代(即,对一组帧)应用,或者可以是无代的。完整网络编码对给定代中的所有帧进行编码。稀疏网络编码方法仅使用一代中的帧中的一些。系统编码方法首先发送原始帧,然后发送编码后的帧以用于擦除/纠错。
现在参考图4A,其中图4的相同元素被提供有相同附图标记,示出了由FEC生成器404执行以使用滑动窗口技术生成(例如,图4B、4C中所示的类型的)编码帧的过程。在FEC生成器404过程中,新的流帧以及可能的新的数据控制帧被提供作为QUIC帧,并且如处理块480中示出地被再构造以形成打包帧482。在一个说明性的再构造过程中,原始QUIC帧被视为字节阵列并被组合(例如,级联在一起)。如果从这种组合操作得到的数据的量不足以装填预定义的打包帧大小(在一些实施例中,该预定义的打包帧大小理想地等于QUIC分组帧的大小),则可以将数据(例如,用零)填充为达到所期望的大小。再构造过程产生打包帧482,然后将该打包帧482添加到滑动窗口缓冲器,如处理框484中示出的。
在处理框484中,将打包帧与来自反馈生成器486的信息组合,并且将一个或多个帧提供给如滑动窗口编码器488所示的滑动窗口编码器。在操作中,向滑动窗口网络编码的编码器连续馈送帧或分组,如适合于架构的。在每个新的QUIC数据400上,滑动窗口网络编码窗口增加,并且在成功递送的帧或分组上,如适合于架构的(例如,根据反馈生成器486),减少窗口(即,从缓冲器中移除递送的打包帧)。
滑动窗口编码器488将滑动窗口网络编码应用于打包帧并且生成编码帧406。因此,对滑动窗口缓冲器中的打包帧执行滑动窗口网络编码以生成编码帧406。
现在参考图4C,说明性编码帧456包括内部编码帧报头(CFH)452’和外部CFH454’。提供具有显式反馈的编码帧456,因此外部CFH包含反馈458和NC系数向量459。内部CFH 452’包含NC报头(即,与表示诸如帧400、402之类的原始帧(在零填充之前)的原始长度的多个位相对应的原始长度部分)。编码帧456还包括经编码的数据部分450’,该经编码的数据部分450’包括一个或多个QUIC帧451。应注意,原始长度必须与QUIC帧的经编码的块一起被包括,以便允许适当的解码(否则,在根据多个分组重建原始数据时,将不可能知道哪个原始长度与哪个分组相关联)。因此,每个编码帧具有一个内部CFH和一个外部CFH。
编码帧456因此在内部CFH 452’中包括编解码器的反馈。这与利用推断反馈的编码帧406(图4B)形成对比(并且因此编解码器的反馈没有包括在编码帧406的内部CFH 452中)。
原始长度系数向量和编解码器反馈可以各自包括在编码帧的单独部分或帧中。因此,在实施例中,编码帧可以包括:第一帧部分,其具有包括一个或多个QUIC帧和原始长度的经编码的数据;第二帧部分,其具有系数向量;第三帧部分,其包括编解码器反馈。
如上面所解释的,QUIC帧被再构造为打包帧。对这些打包帧执行滑动窗口网络编码以生成编码帧。因此,编码帧可以包含去往接收器的新信息,或者编码帧可以是FEC(前向纠错/擦除校正)帧/数据。
现在参考图4D,响应于来自NC FEC QUIC客户端466(即,能够接收和划分上面结合图4-图4C所描述的类型的分组/帧的客户端)的请求,NC FEC QUIC服务器460生成N个NC分组462a-462N。分组462中的每一个分组可以与上面结合图4B和/或图4C所描述的分组相同或相似(即,作为QUIC分组的一部分提供的编码帧)。NC分组462a-462N经由UDP连接从NCQUIC服务器460发送到NC QUIC客户端466。
应该认识到,在图4的滑动窗口方法中,没有显式地创建FEC分组(因为纠错是由编解码器(例如,FEC生成器404)基于提供给其的反馈来处理的)。
然而,应当理解,在帧级别编码的其他实施例(即,使用除了滑动窗口技术之外的网络编码技术的实施例)中,可以使用附加的FEC分组。
应当理解,上面结合图3和图4所描述的技术可以被单独或组合使用。
现在参考图4E,示出了利用使用上面结合图3和图4两者所描述的技术的组合生成的分组操作的系统的示例。特别地,首先使用帧级别编码技术(例如,图4中示出的内部技术)来生成(例如,图4B、图4C中示出的类型的)编码帧。然后,这样的编码帧经历分组级别编码技术(例如,图3中示出的外部技术)来生成上面结合图3A所描述的类型的帧。
当然,应该认识到,在实际系统中的流程将比图4E中示出的流程显著地更为复杂。QUIC由流组成。客户端发送请求,在客户端与服务器之间创建新的流(这是在一个UDP连接内的虚拟连接)。流正在生成流(数据)帧,该流(数据)帧被给予生成编码帧的编码生成器。编码帧在QUIC分组中行进。
响应于来自NC QUIC客户端466’的请求,NC QUIC服务器460’根据图4中描述的发送侧技术生成N个(这里为4个)分组462。因此,分组462中的每一个包括编码帧作为有效载荷,如上面在图4B中所描述的。根据图3中描述的发送侧技术,分组462之后是NC FEC分组472。分组462、472经由UDP连接被发送到NC QUIC客户端466’。如上面结合图3所指出的,在每N个分组462之后发送FEC分组472。
现在参考图5,可以与图1A的分组500相同或相似的现有技术QUIC分组500’包括公共报头501’、密码签名502’和有效载荷504’。公共报头501’可以包括字段,例如,公共标志字段、连接ID字段、版本信息字段、多样化随机数字段以及标识分组号的字段。密码签名报头502’可以包括用于解密分组的信息。有效载荷字段504’可以包括分组的数据有效载荷。数据有效载荷504’可以在传输之前被加密。
现在参考图5A,具有显式反馈的编码分组505包括公共报头506、密码签名报头508和编码帧507(即,分组505的虚线部分)。应该认识到,编码帧507可以与上面结合图4C所描述的编码帧456相同或相似。在该说明性实施例中,编码帧507包括外部编码帧报头(CFH)510、内部CFH 512和有效的有效载荷514。外部CFH 510包括反馈部分510a和系数向量510b。图5A中的分组可以例如通过诸如图4中示出的过程之类的过程来产生。
与图5A的编码分组相反,应当理解,现有技术QUIC技术使用相同的码(即,被组合的所有分组的直接总和)。因此,在现有技术QUIC技术中,QUIC分组不包括外部CFH,该外部CFH包括表示码的信息(由于在现有技术方法中码没有改变,因此在与QUIC一起使用的现有技术分组的任何报头中都没有任何要表示的内容)。
公共报头506可以与公共报头501’相同或相似,并且可以具有1到51个字节之间的长度。类似地,密码签名报头508可以与密码签名报头502相同或相似,并且可以具有12个字节的长度。当然,可以提供具有根据特定应用进行正确操作所要求的任何数量的字节的报头506、508。
外部CFH 510可以是使用网络编码算法生成的前向纠错报头。在实施例中,外部CFH 510可以包括信息,例如,关于帧的元信息(例如,类型ID)以及(在显式反馈的情况下的)反馈。内部CFH 512至少包括原始长度,该原始长度可以用于经由网络编码技术恢复分组。如上面所指出的,原始长度信息必须包括在编码帧的经编码的数据部分中。可以使用网络编码技术来例如恢复在目的地处未接收到的一个或多个QUIC分组。
外部CFH 510被提供有足以保持一定量的信息的长度。在一个说明性实施例中,外部CFH 510可以被提供有与用于生成外部CFH的分组、帧、流等的生成长度有关的长度。在任何应用中,外部CFH的特定长度均基于各种因素,包括但不限于实现网络编码的方式。在一些实施例中,可以使用无代滑动窗口技术,而在其他实施例中,可以使用其他网络编码技术。
生成长度是在一个编码器中分组在一起的分组或帧的数量。在完整NC的情况下,将编码应用于所有分组/帧,或者在稀疏NC的情况下,将编码应用于这些分组/帧的子集。例如,在将10个分组/帧分组在一起的情况下,生成长度=10。在无代滑动窗口的情况下,生成长度是未定义的,但是窗口指定了一起编码的分组或帧的组。因此,在一起编码10个分组/帧的情况下,窗口大小=10。在真正无代滑动窗口实现方式的情况下,窗口长度理论上可以在1到无穷大之间变化。
通常,考虑用于生成外部CFH的分组、帧、流等的生成长度g来选择内部CFH 512的长度。内部CFH 512可以包括关于上面所提到的网络编码方案的信息。例如,内部CFH 512可以包括诸如编码系数之类的信息,或者可以在解码中使用的其他信息。在进行网络编码的情况下,仅必须收集足够的分组以便执行解码。因此,应该认识到,在滑动窗口的情况下,接收器不需要明确地区分FEC和普通分组。
有效载荷514可以包括要由接收器接收的数据。在实施例中,有效载荷514的长度可以是QUIC有效载荷的长度减去内部CHF报头510和外部CHF报头512的长度。
现在参考图5B,可以通过诸如图4中示出的过程之类的过程产生的具有推断反馈的QUIC分组515例如包括公共报头516、密码报头518和编码帧517(即,分组515的虚线部分),该编码帧517可以与上面结合图4B所描述的编码帧406相同或相似。在该说明性实施例中,编码帧517包括外部CFH报头520、内部CFH报头522和有效的有效载荷524。
公共报头516可以与公共报头501’相同或相似。在说明性实施例中,公共报头516可以具有高达51个字节的长度(例如,在1到51个字节之间)。类似地,密码签名报头518可以与密码签名报头502’相同或相似,并且在一个实施例中可以具有高达12个字节的长度。
外部CFH报头520可以是使用网络编码技术生成的前向纠错报头。在实施例中,外部CFH报头520可以包括诸如系数之类的信息,该信息例如可以用于对网络编码算法求解。可以使用网络编码算法来例如恢复在目的地处未接收到的一个或多个QUIC分组。
在实施例中,外部CFH 510可以具有2个字节的长度。在其他实施例中,可以使用少于或多于2个字节。内部CFH 522可以具有考虑到用于生成外部CFH报头的分组、帧、流等的生成长度g而选择的长度。内部CFH522可以包括关于上面所提到的网络编码方案的信息。例如,内部CFH 522可以包括诸如编码系数之类的信息,或者可以用于执行解码的其他信息。应该认识到,在滑动窗口的情况下,接收器不需要明确地区分FEC和普通分组。
有效载荷524可以包括要由接收器接收的数据。在实施例中,有效载荷524的长度可以是QUIC有效载荷的长度减去外部CFH 520和/或内部CFH 522的长度。
图6和图6A是在客户端与服务器之间的分组流的示例,其示出了基于XOR的FEC与基于NC的FEC之间的差异。图6和图6A示出了在同一FEC组中发生多个分组丢失的情况下(可能被认为是现有技术方法的最坏情况的场景),如何利用网络编码技术来改进分组的传输。
现在转向图6,示出了根据现有技术QUIC FEC协议的一个方面示出在服务器与客户端之间的分组流的示例的序列。
现在参考图6A,示出了根据基于网络编码(NC)的QUIC协议的一个方面的示出在服务器与客户端之间的分组流的示例的序列。如从使用本文所描述的技术(即,图3和图4的技术)的图6和图6A的比较可以看出的,传输完成的比现有技术方法更快。
然而,根据本文所描述的概念、系统和技术,通过使用较大的字段大小和多个等式发送网络编码分组,即使在丢失多个分组时也可以恢复期望的信息。
现在参考图7,用于流级别FEC的示例分组(即,流级别编码的说明)包括一个或多个控制帧和流帧(流1帧)。流帧是从流中生成的。如图7中示出的,流1帧包括被划分成相等大小的块并打包到流帧中的网络编码数据。当然,应该认识到,使用相等大小的NC块不是必要的。相反,可以使用可变大小的NC块。
控制帧可以包括可以用于从流1中恢复丢失的分组的信息(例如,FEC分组和/或网络编码系数)。在该示例中,控制帧可以与单个流相关联。
现在参考图7A,用于流级别FEC的分组包括一个或多个控制帧和多个流帧,在该示例中示出了两个流(流1和流2)。每个流帧包括多个网络编码块。因此,可以将多个不同的流一起编码(即,可以使用内部流(intraflow)与简单地中间流(interflow))。
在该说明性实施例中,每个流帧包括被划分成相等大小的块并打包到流帧中的网络编码块。当然,应该认识到,使用相等大小的NC块不是必要的。相反,可以使用可变大小的NC块。
控制帧可以包括可以用于从流1和/或流2中恢复丢失的分组的信息(例如,FEC分组和/或网络编码系数)。在该示例中,FEC控制帧可以与多于一个流相关联。在实施例中,相同的FEC和网络编码系数可以用于恢复多个流中的错误。在另一实施例中,FEC控制帧块可以具有FEC和网络编码系数的多个集合。每个集合可以用于解码和恢复相应的流中的错误。
现在参考图8,多个节点1102a-1102N通过网络1110耦合。以节点1102a作为节点1102b-1102N的代表,节点1102a包括NC QUIC服务器1104a和NC QUIC客户端1106a。节点中的每一个都能够生成并接收根据上面结合图3和图4所描述的技术中的任一种或组合所生成/接收的编码分组。
已经描述了用于说明本专利主题的各种概念、结构和技术的优选实施例,对于本领域普通技术人员而言现在将变得显而易见的是,可以使用并入了这些概念、结构和技术的其他实施例。另外,本文所描述的不同实施例的元素可以被组合以形成上面未具体阐述的其他实施例。
因此,认为本专利的范围不应当限于所描述的实施例,而应该仅由所附权利要求的精神和范围来限定。
Claims (13)
1.一种用于编码数据的方法,包括:
在输入处接收多个QUIC帧;
将所述多个QUIC帧再构造为打包帧(404a);
将网络编码应用于所述打包帧以生成编码数据(450),其中,所述编码数据(450)包括内部编码帧报头(452),所述内部编码帧报头(452)包括表示所述多个QUIC帧的长度的原始长度部分;
生成包括所述编码数据和外部编码帧报头(454)的编码帧(406),所述外部编码帧报头(454)包括表示在所述网络编码中使用的编码系数的信息;
形成用户数据报协议(UDP)分组(414),所述UDP分组(414)包括公共报头(410a)和所述编码帧的表示(414b);以及
在输出处提供所述UDP分组以用于通过UDP连接传输到接收器(430)。
2.根据权利要求1所述的方法,其中,所述UDP分组包括所述编码帧的经加密的表示(414b)。
3.根据权利要求1所述的方法,其中,表示在所述网络编码中使用的所述编码系数的所述信息包括编码系数的向量。
4.根据权利要求1所述的方法,其中,将网络编码应用于所述打包帧包括:将滑动窗口网络编码应用于所述打包帧以生成编码帧。
5.根据权利要求1所述的方法,其中,所述编码帧包括去往所述接收器的新信息。
6.根据权利要求1所述的方法,其中,所述编码帧包括前向纠错(FEC)数据。
7.根据权利要求1所述的方法,还包括:
响应于从所述接收器接收确认(ACK)而向拥塞控制模块提供信息;以及
基于提供给所述拥塞控制模块的所述信息来确定发送是否被允许。
8.一种前向纠错(FEC)生成器,包括:
用于接收多个QUIC帧的输入;
用于分组所述多个QUIC帧以提供打包帧的再构造单元;
用于将网络编码应用于所述打包帧以生成编码数据(450)的编码单元,其中,所述编码数据(450)包括内部编码帧报头(452),所述内部编码帧报头(452)包括表示所述多个QUIC帧的长度的原始长度部分;
用于生成包括所述编码数据和外部编码帧报头(454)的编码帧(406)的单元,所述外部编码帧报头(454)包括表示在所述网络编码中使用的编码系数的信息;
用于形成用户数据报协议(UDP)分组(414)的单元,所述UDP分组(414)包括公共报头(410a)和所述编码帧的表示(414b);以及
输出,在所述输出处提供所述UDP分组以用于通过UDP连接传输到接收器。
9.根据权利要求8所述的生成器,其中,所述UDP分组包括所述编码帧的经加密的表示(414b)。
10.根据权利要求8所述的生成器,其中,表示在所述网络编码中使用的所述编码系数的所述信息包括编码系数的向量。
11.根据权利要求8所述的生成器,其中,所述编码单元包括用于将滑动窗口网络编码技术应用于所述打包帧的单元。
12.根据权利要求8所述的生成器,其中,所述FEC生成器被配置为以大于或等于二的窗口大小进行操作。
13.根据权利要求8所述的生成器,还包括:
用于从所述接收器接收确认(ACK)的单元;以及
用于基于所述ACK来确定发送是否被允许的拥塞控制模块。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762582006P | 2017-11-06 | 2017-11-06 | |
US62/582,006 | 2017-11-06 | ||
PCT/US2018/059340 WO2019090289A2 (en) | 2017-11-06 | 2018-11-06 | System and technique for generating, transmitting and receiving network coded (nc) quick udp internet connections (quic) packets |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110622449A CN110622449A (zh) | 2019-12-27 |
CN110622449B true CN110622449B (zh) | 2023-04-28 |
Family
ID=64453618
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201880031064.4A Active CN110622449B (zh) | 2017-11-06 | 2018-11-06 | 用于处理网络编码分组的系统和技术 |
Country Status (4)
Country | Link |
---|---|
US (1) | US11381339B2 (zh) |
EP (1) | EP3707837A2 (zh) |
CN (1) | CN110622449B (zh) |
WO (1) | WO2019090289A2 (zh) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN114979021B (zh) * | 2021-02-27 | 2024-05-14 | 华为技术有限公司 | 数据处理方法及电子设备 |
US12063282B2 (en) | 2021-09-15 | 2024-08-13 | Cisco Technology, Inc. | Policy expressions using QUIC connection identifiers |
CN118575433A (zh) * | 2022-04-07 | 2024-08-30 | 华为技术有限公司 | 编码和解码用于受保护传输的数据包的方法、数据发送器和数据接收器 |
CN117596306A (zh) * | 2022-08-04 | 2024-02-23 | 华为技术有限公司 | 编码、解码方法及其装置 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107113304A (zh) * | 2014-11-07 | 2017-08-29 | 奥兰治 | 加密数据交换上的中介委派 |
WO2017150792A1 (en) * | 2016-02-29 | 2017-09-08 | University-Industry Cooperation Group Of Kyung Hee University | Apparatus and method for providing contents using web-based virtual desktop protocol |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8135015B2 (en) * | 2009-03-27 | 2012-03-13 | Qualcomm Incorporated | System and method of transmitting and receiving data frames |
US9628542B2 (en) * | 2012-08-24 | 2017-04-18 | Akamai Technologies, Inc. | Hybrid HTTP and UDP content delivery |
US9026783B2 (en) | 2013-03-07 | 2015-05-05 | Google Inc. | Low latency server-side redirection of UDP-based transport protocols traversing a client-side NAT firewall |
US9338088B2 (en) | 2013-04-08 | 2016-05-10 | Google Inc. | Communication protocol for multiplexing data streams over UDP |
US9319329B2 (en) | 2013-10-14 | 2016-04-19 | Google Inc. | Pacing enhanced packet forwarding/switching and congestion avoidance |
US9432274B1 (en) | 2013-11-01 | 2016-08-30 | Google Inc. | Intermediary facilitated packet loss recovery |
US10069595B2 (en) * | 2014-09-26 | 2018-09-04 | Telefonaktiebolaget Lm Ericsson (Publ) | Forward error correction in cellular networks |
US10219118B2 (en) * | 2015-12-29 | 2019-02-26 | Koninklijke Kpn N.V. | Method and transmission node for providing data packets to a plurality of receivers using network coding |
US9843413B2 (en) * | 2016-03-25 | 2017-12-12 | Cisco Technology, Inc. | Forward error correction for low-delay recovery from packet loss |
-
2018
- 2018-11-06 US US16/604,200 patent/US11381339B2/en active Active
- 2018-11-06 CN CN201880031064.4A patent/CN110622449B/zh active Active
- 2018-11-06 WO PCT/US2018/059340 patent/WO2019090289A2/en unknown
- 2018-11-06 EP EP18807805.9A patent/EP3707837A2/en active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107113304A (zh) * | 2014-11-07 | 2017-08-29 | 奥兰治 | 加密数据交换上的中介委派 |
WO2017150792A1 (en) * | 2016-02-29 | 2017-09-08 | University-Industry Cooperation Group Of Kyung Hee University | Apparatus and method for providing contents using web-based virtual desktop protocol |
Non-Patent Citations (4)
Title |
---|
."3GPP TR 29.890 V0.3.0 Technical Report".《3GPP tsg_ct\WG3_interworking_ex-CN3》.2017, * |
"power-point presentation to DVB TM-IPI taskforce on adaptive streaming over IP multicast";Lucas Pardue;《BBC R&D detailed technology proposal for reference interface M》;20171031;第1-19页 * |
"QUIC Wire Layout Specification";sweibd;《QUIC Wire Layout Specification - mobibrw.com》;20150529;第1-17页 * |
3rd Generation Partnership Project * |
Also Published As
Publication number | Publication date |
---|---|
EP3707837A2 (en) | 2020-09-16 |
WO2019090289A3 (en) | 2019-06-13 |
US11381339B2 (en) | 2022-07-05 |
WO2019090289A2 (en) | 2019-05-09 |
CN110622449A (zh) | 2019-12-27 |
US20200067634A1 (en) | 2020-02-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110622449B (zh) | 用于处理网络编码分组的系统和技术 | |
EP1346578B1 (en) | Method for multimedia communication over packet channels | |
EP2556613B1 (en) | Processing transport packets | |
Li | RTP payload format for generic forward error correction | |
TWI387249B (zh) | 通訊發送器及通訊接收器及封包冗餘法及封包復原法 | |
EP2630766B1 (en) | Universal file delivery methods for providing unequal error protection and bundled file delivery services | |
US7584404B2 (en) | Method and apparatus for multimedia communication over packet channels | |
Chakareski et al. | Application layer error-correction coding for rate-distortion optimized streaming to wireless clients | |
JP2020502832A (ja) | データストリーミングの前方誤り訂正 | |
Tsai et al. | Sub-packet forward error correction mechanism for video streaming over wireless networks | |
US20020159454A1 (en) | Method of protecting data packets against errors | |
KR20130039866A (ko) | 통신 시스템에서 순방향 에러 정정 패킷을 송수신하는 방법 및 장치 | |
US7215683B2 (en) | Method and apparatus for protecting against packet losses in packet-oriented data transmission | |
EP3117546A1 (en) | Low-delay packet erasure coding | |
KR20060112287A (ko) | 유무선 통신시스템에서 비트화 데이터 청크 수신응답 방법및 장치 | |
KR20040071765A (ko) | Rs 코드들을 기초로 하여 포워드 에러 정정을 이용하는 비동등 에러 보호 | |
Zanaty et al. | RTP payload format for flexible forward error correction (FEC) | |
WO2007046903A1 (en) | Parallel processing of data using information about the data and information about a streaming network | |
WO2018109500A1 (en) | Low delay, error resilient video transport protocol over public ip transit | |
Wang et al. | Secure and Reliable Multipath Transmission Scheme Based on Interleaving Network Encoding | |
Detchart et al. | RFC 9407 Tetrys: An On-the-Fly Network Coding Protocol | |
US20210336873A1 (en) | Method and apparatus for coded multipath network communication | |
Begen et al. | PAYLOAD M. Zanaty Internet-Draft Cisco Intended status: Standards Track V. Singh Expires: November 17, 2019 callstats. io | |
Zanaty et al. | RFC 8627: RTP Payload Format for Flexible Forward Error Correction (FEC) | |
Begen et al. | PAYLOAD M. Zanaty Internet-Draft Cisco Intended status: Standards Track V. Singh Expires: September 6, 2019 callstats. io |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |