Page 430 - 《软件学报》2024年第4期
P. 430

2008                                                       软件学报  2024  年第  35  卷第  4  期


                 装延迟. 由公式    (1) 可知, 当  RTT min  较大时, TACK  报文可能会被过度延迟, 从而影响丢失检测, 导致代价昂贵的超
                 时重传. TACK  报文的丢失将进一步加剧这个问题. 例如, 假设            RTT min  = 200 ms,    bw max  = 10 Mb/s, L = 2, 则   f tack  = 20 Hz.
                 与经典   TCP  的确认机制相比, 发生丢包事件时, TACK          会导致反馈延迟高达       50 ms. 如果  TACK  报文丢失或重传
                 报文再次丢失, 则这个延迟将会翻倍.
                    (2) 时延评估偏差
                    图  6  所示的用例分析已经证明, 减少         ACK  的数目将导致时延评估产生偏差. 由于             TACK  的目标是最小化
                 ACK  的数目, 所以两个    TACK  报文之间的间隔时间可能较长, 期间接收方可能接收到多个数据报文, 即数据报文
                 和  ACK  是多对一的关系. 进行     RTT  评估时, 如果在多个数据报文中随机选择一个报文进行采样, 则可能引入评估
                 偏差. 具体地, 最小    RTT  可能偏大, 最大   RTT  可能偏小. 一种容易想到的方案是, 在一个            TACK  报文中携带两个
                 TACK  报文间隔时间期间的所有收到的数据报文的相应时间戳信息, 以便于发送方能够对每个报文进行采样, 实
                 现类似于   Per-packet ACK  机制的效果. 然而, 这种方法存在两个问题: (1) 带宽资源和内存资源等开销大; (2) 当数
                 据报文数目较多时, ACK      报文长度有限, 可能不足以携带时延评估所必需的完整信息.
                    (3) 流量突发
                    从图  9  的用例分析可知, 当     ACK  间隔时间较长时, 流量呈现突发的特征. TACK           报文之间的间隔时间通常是
                 比较长的, 因此一个      TACK  报文可能会确认大量的数据报文. 在这种情况下, 流量突发造成的影响将不可忽略. 如
                 果处理不当, 则可能导致瓶颈链路缓存不足、丢包率增高和排队时延增大等问题.
                    (4) 接收窗口通告延迟
                    图  11  所示的用例分析已经证明, 当       ACK  触发时间间隔较大时, 可能造成反馈延迟, 进而导致带宽利用率低
                 下. 如果  TACK  报文丢失, 则这一问题造成的后果将进一步恶化.
                  4.1.3    方案: 基于  TACK  的按需确认机制
                    (1) 总体策略
                    TACK  报文的触发频率设计, 能够最小化          ACK  的数目. 然而, 如果只是简单地应用         TACK  报文, 则可能导致传
                 输控制效率低下, 原因是减少         ACK  数目将带来丢包恢复延迟大、时延评估偏差、流量突发和接收窗口通告延迟
                 等副作用. 因此, 传输控制真正需要的, 是一个基于             TACK  的按需确认机制      (简称为  TACK  机制). TACK  机制的目
                 标是在最小化     ACK  数目的基础上, 增加少量的必要的         ACK  数目, 消除上述副作用, 从而真正体现“按需确认”的理念.
                    具体地, 相比经典      TCP  的确认机制, TACK   机制赋予了    ACK  报文更多的智能和灵活性. 其设计原理, 可以简
                 单地理解成    3  点: 1) 更多  ACK  种类适应不同场景需求; 2) ACK    按需携带更多必要的信息; 从而实现: 3) 更少但足
                 够的  ACK  数目. 值得注意的是, 需要减少       ACK  数目的场景, 如无线局域网等, 在        ACK  报文中携带更多的信息, 只
                 是增大报文长度, 并不会造成显著的频谱资源开销.
                    TACK  机制按照触发条件来分类, 包括两种           ACK  类型, 分别为   IACK (Instant ACK) 和  TACK (Tame ACK). 具
                 体来说, IACK  报文加快传输控制对即时事件           (例如丢包) 的反馈和响应, 同时, TACK        报文保证反馈的鲁棒性和可
                 靠性. IACK  基于即时事件驱动. 例如, 当接收方缓存满时, 接收方可以发送一个                  IACK  报文, 通知发送方停止发送
                 数据. 发生丢包事件时, 接收方可以发送一个             IACK  报文, 通知发送方进行重传. TACK       报文是以指定频率触发的,
                 其数量不会跟吞吐成比例, 也就不会造成“内部干扰”随着吞吐增大而增大.
                    值得注意的是, 通常情况下, IACK        报文的引入, 并不会明显地增加          ACK  报文数目. 假设正向路径上的丢包率
                   ρ , 则最坏情况下的     IACK        bw max   . 首先, IACK  的数目实际会远小于这个上界; 其次, 真实场景中的丢
                 为                     数目为    ρ
                                               L·MSS
                 包率通常较小     (例如   ρ < 10% ).
                    TACK  报文和   IACK  报文相辅相成、互相补充和高效协同, 加上基于              TACK  机制的丢包恢复、时延探测和速
                 率控制算法, 可以保证丢包恢复的鲁棒性、时延探测的准确性以及速率控制高效性. Li 等人                           [29]  详细阐述了如何基
                 于  TACK  机制设计丢包恢复算法、时延探测算法和速率控制算法. 此处不再赘述.
                    (2) TACK  报文携带的信息
                    TACK  报文除了对最新收到的数据报文进行确认以外, 还可以根据需要反馈丢包信息、带宽信息、窗口信息、
   425   426   427   428   429   430   431   432   433   434   435