【每日文稿】2025-01-14
今日共有13篇文稿更新，涉及5个area里的10个WG
INT
dtn
- Title: BPv7 Secure Advertisement and Neighborhood Discovery (SAND)
- Authors: Brian Sipos(brian.sipos+ietf@gmail.com), Joshua Deaton(joshua.e.deaton@nasa.gov)
- Summary: 这篇文稿是关于建立一个在延迟容许网络中的安全广告和邻居发现协议(BPv7 Secure Advertisement and Neighborhood Discovery, SAND).它定义了如何在一个延迟容许网络中发现多个节点之间的安全身份、能力以及彼此的连接。本文总结了这个协议的基本概念、架构、消息类型及结构等。文档使用了CDDL数据定义语言（CDDL）来描述协议，避免了冗余，并且遵循了曼网和邻接发现（MANET-NHDP）的标准模式。 主要特点包括： 1. 使用包层（BPv7）作为信息基础，而不是需要提前配置的信息。 2. 包含一组可扩展性特性，如消息类型和消息模式的定义。 3. 配合无状态的零配置UDP CL（UDPCLv4），以提供对任何来源的多播支持。 4. 沿用了BPSec的安全机制。 5. 包含用于传递安全身份、拓扑信息和资源信息的消息类型。 6. 定义了各种信息基和时间间隔，以便在各个节点之间传递数据。 总的来说，SAND是一种基于BPv7的协议，旨在满足在延迟容许网络中的低延时通信需求，同时保护网络安全。
OPS
anima
- Title: JWS signed Voucher Artifacts for Bootstrapping Protocols
- Authors: Thomas Werner(thomas-werner@siemens.com), Michael Richardson(mcr+ietf@sandelman.ca)
- Summary: （JWS-voucher）是针对物联网安全接入和零接触部署的一种新的数字凭证格式。它使用JSON Web Token (JWT)机制替代当前常用的加密签名技术，如密钥交换扩展（COSE），以提供更好的安全性。 该文档主要包含以下几部分： 1. 引言：介绍JWS-voucher的概念、目的以及与现有方案的对比。 2. 基本术语：定义了相关的技术和概念，包括JSON Voucher Data、JWS Voucher、Voucher等。 3. JWS Voucher Artifact with JSON Web Signature：描述了如何将这些基本概念封装成一种可以用于零接触部署的证书形式。 4. 隐私考虑：讨论了JWS保护头可能泄露的问题，并提供了相应的安全措施。 5. 安全性考虑：分析了这种新协议的安全性和互操作性问题。 6. IANA考虑：注册了应用媒体类型，使不同平台可以识别并利用JWS-voucher。 7. 结论：总结了JWS-voucher的优点和局限性，并指出了未来的发展方向。 总的来说，《互联网标准草案》为零接触部署提供了新的解决方案，但同时也带来了一些新的隐私和安全挑战需要解决。随着技术的发展，我们需要持续关注这些新标准的影响并制定相应对策。
- Diff: 该标准文档提供了新的Voucher格式——基于JSON Web Signature（JWS）的VoucherArtifact，并使用了JSON和JOSE机制来替代现有的Cryptographic Message Syntax（CMS）机制。与之前的版本相比，主要区别在于： 1. 使用了JSON作为数据表示形式，允许更灵活地编码不同的Voucher数据结构。 2. 使用了JSON Web Signatures（JWS）作为签名技术，支持多签，使得证书管理更加简单。 3. 增加了一个媒体类型注册项，定义了一个名为“application/voucher-jws+json”的媒体类型，用于识别这种新的Voucher格式。 总的来说，这个修订版为开发者提供了一种更易于扩展和理解的新Voucher格式，同时保持了对现有协议的支持。
netmod
- Title: Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
- Authors: Andy Bierman(andy@yumaworks.com), Mohamed Boucadair(mohamed.boucadair@orange.com), Qin Wu(bill.wu@huawei.com)
- Summary: 本文是关于网络配置协议（Netconf）和RESTCONF协议中使用YANG数据模型的一些建议。它定义了对YANG模块使用的指南，包括在IANA备案的模块、RFC文档等。文稿还讨论了如何正确引用相关的RFC文档。 总结来说，本文主要介绍了关于YANG模块命名规则、标识符命名规范、数据类型声明、条件语句、XPath语法以及如何合理使用这些指导原则来提高网络配置管理协议的兼容性和易用性。
- Diff: 该文档是关于网络配置协议（NETCONF）和RESTCONF协议的数据模型规范的一份官方文档。它定义了一套指导性建议，用于YANG数据模型的编写、审查和使用。 与旧版相比，新版的主要区别有： 1. 对术语进行了更详细的说明和解释。 2. 提供了更多关于如何使用模块和子模块的指南。 3. 强调了模块分类的重要性。 4. 更明确了对安全和认证的规定。 5. 更新了关于YANG 1.1和1.0语法的描述。 6. 添加了新的章节，如"定义标准标签"，以呼应RFC8819中的指导原则。 总的来说，新版更加详细地规定了YANG数据模型的使用方法，并增加了更多的实践性和指导性的信息。这将有助于读者更好地理解和使用这些模型，提高其可读性和可用性。
RTG
bfd
- Title: BFD Path Consistency over SR
- Authors: Changwang Lin(linchangwang.04414@h3c.com), Weiqiang Cheng(chengweiqiang@chinamobile.com), Jiang Wenying(jiangwenying@chinamobile.com), Ran Chen(chen.ran@zte.com.cn)
- Summary: 本文讨论了在SR网络中使用双向检测（BFD）来监控SR路径的方法。BFD可以用于监测SR路径，当一个头端节点使用BFD检测SR策略时，其前向路径和回返路径可能会不一致，从而影响检测结果。如果前向路径是正常的，而回返路径是不可达的，那么BFD会断开连接。在这种情况下，需要保证前向和回返路径的一致性。 本文提出了通过路径段（Path Segment）保持前向和回返路径一致的方法。使用这种方法，可以在SR网络中的两个方向上建立映射表，利用这个映射表，后端节点可以通过路径段获取反向路径，并且这些路径会在同一个中间节点或链路上使用相同的中间节点或链路。 该方法能够确保前后向路径的一致性，使得SR策略的检测更加稳定可靠。
- Diff: 该新版本的英文标准文稿详细描述了如何在使用BFD检测SR策略时保持前向路径和反向路径的一致性。主要内容包括： 1. 简化的方法通过路径段来监控SR策略（S-BFD）。 2. 当节点A作为发起者时，创建用于列表1和列表2的S-BFD会话。当接收节点D接收到S-BFD控制包时，响应控制包应该沿着相同路径返回以避免因前向和反向路径不一致而导致的错误检测。 3. 使用SRv6和SR-MPLS时，节点A将路径段添加到SRH中，并设置SRH.P-Flag属性。 4. 在SR-MPLS中，使用SR Policy中的路径段来封装回声包并指导从远程系统引导数据包沿同一路径。 总的来说，本版本着重于引入路径段的概念，使前向和反向路径更易于一致性和可预测性。同时简化了协议处理过程，提高了设备的利用率和可靠性。
lsr
- Title: IGP Reverse Prefix Metric
- Authors: Dan Li(tolidan@tsinghua.edu.cn), Libin Liu(liu.libin@outlook.com), Changwang Lin(linchangwang.04414@h3c.com), Xueyan Song(song.xueyan2@zte.com.cn), Yuanxiang Qiu(qiuyuanxiang@h3c.com)
- Summary: 本文定义了一个方法来计算反向路径，通过发布反向前缀成本。这个方法旨在解决多区域IGP场景下由于双向路径成本不匹配导致严格RPF检查失败的问题。 本文主要解决了两个问题： 1. 解决了在多区域IGP场景下，由于反向路径成本与前向路径成本不一致而导致的严格RPF检查失败的问题。 2. 提供了一种扩展协议的方法，使ABR能够同时广告反向前缀成本和前向路径成本，从而提供更准确的RPF检查结果。 此外，本文还提出了一些安全性和IANA考虑，并提供了参考文献。
- Diff: 新的文档定义了一种方法来计算路由逆路径，通过在广告反前缀成本的方法解决多区域IGP场景下严格RPF（反向路径转发检查）失败的问题。 与旧版相比，最大的不同在于： 1. 在协议扩展方面，新增了对OSPFv2和OSPFv3反前缀成本的支持，并允许在扩展的协议类型下同时发布反前缀成本。 2. 在安全考虑部分，没有引入新的安全性措施。 3. 在IANA考虑部分，没有具体说明具体的参数值，但未提及是遗留还是新添加。 总的来说，新的文档提供了一种更高效、通用的方式来处理多区域网络中的严格RPF问题，并且在协议扩展方面提供了更多选择。
- Title: Purge Originator Identification for OSPF
- Authors: Zhenqiang Li(lizhenqiang@chinamobile.com), Changwang Lin(linchangwang.04414@h3c.com)
- Summary: 这篇英文标准文档主要讨论了在IP路由协议中添加源标识信息的需求，特别是针对OSPF（开放最短路径优先）协议。它提出了一种新的格式，即Purge Originator Identification（POI）来记录发出PURGE LSA的路由器ID。这种新格式可以在发送PURGE LSA时同时生成POI LSA，从而提供一种更简单的方法来定位来源路由器。 文稿还提出了如何实现这个功能，并详细描述了POI LSA的基本结构和格式。此外，还对部署、安全性和IANA注册等进行了讨论。总体而言，该文档旨在解决当前OSPF协议中没有明确指示源路由器的问题，通过增加额外的信息来满足这一需求。
- Diff: 该文档的主要区别在于引入了新的扩展选项（Extended Options）TLV和协议级别的POI LSA来记录路由器生成的删除（purge）LSA的路由ID。旧版文档仅在IS-IS中定义了一个PURGE TLV用于标识生成清除LSA的路由器。 新版文档提出了使用两个不同的扩展选项TLV（Extended Options TLV）和协议级别的POI LSA来记录路由器生成的清除LSA的路由ID。这样可以更方便地定位清除LSA的源头，从而更容易确定清除LSA的原因。同时，也考虑到了安全性和可伸缩性的问题，提出了一套规范性的注册机制以管理这些新增的TLV和结构化数据。
- Title: Prefix Flag Extension for OSPFv2 and OSPFv3
- Authors: Ran Chen(chen.ran@zte.com.cn), Detao Zhao(zhao.detao@zte.com.cn), Peter Psenak(ppsenak@cisco.com), Ketan Talaulikar(ketant.ietf@gmail.com), Liyan Gong(gongliyan@chinamobile.com)
- Summary: 本文主要讨论了OSPF协议中的前缀标志扩展。在OSPFv2和OSPFv3版本中，虽然都存在前缀选项字段，但前者仅剩下了4个未使用的位，而后者已经将所有位分配完毕。因此，为了满足需求，定义了一个用于标识额外属性的变量长度前缀标志子TLV（Sub-TLV）。这些子TLV包括OSPFv2和OSPFv3的前缀标志子TLV，并且具有不同的格式和描述。此外，还提到了如何处理这些子TLV以及它们的背向兼容性。 总结：本文详细介绍了关于OSPf协议中前缀标志扩展的相关概念和技术细节。通过定义新的前缀标志子TLV，解决了现有前缀标志位不足的问题，为OSPFv2和OSPFv3提供了更多的选择和灵活性。同时，也提出了相关的安全考虑和处理方法。
- Diff: 本文档的主要区别在于它定义了针对OSPFv2和OSPFv3的新变量长度Prefix Attribute Flags Sub-TLV（简称PAFF）。这两种类型的Sub-TLV分别用于扩展标志字段，解决了现有标志不足的问题。在处理方面，子TLV长度依赖于包含的Prefix Attribute Flags，且必须为4的倍数。此外，未传输的标志位将被忽略。 在回溯兼容性方面，PAFF子TLV不引入任何回溯兼容性问题。如果设备不理解或支持这些标志，则应忽略该TLV。对于新增的标志位，它们将在未来由IANA分配，并跟踪其品质，如编号、描述和引用等。 总体来说，新版文档增加了对OSPFv2和OSPFv3的特殊扩展标志的支持，并定义了新的子TLV来补充现有的标志字段。
lsvr
- Title: BGP Link-State Shortest Path First (SPF) Routing
- Authors: Keyur Patel(keyur@arrcus.com), Acee Lindem(acee.ietf@gmail.com), Shawn Zandi(szandi@linkedin.com), Wim Henderickx(wim.henderickx@gmail.com)
- Summary: 本文主要讨论了BGP（Border Gateway Protocol）和BGP Link-State Shortest Path First（BGP-LS SPF）路由协议之间的关系。BGP-LS是一种用于收集网络层可达信息并共享给外部实体的工具，它可以使用BGP-LS扩展族进行交换。BGP-LS-SPF是一种在BGP-LS扩展族上定义的新BGP安全属性。 BGP-LS-SPF通过引入新的BGP-LS-SPF扩展族来支持BGP-LS协议。它使BGP-LS能够描述网络层可达性信息，并将其作为BGP-LS-SPF SAFI的一部分发布。这种新特性允许BGP-LS协议成为BGP的底层协议以及BGP的上层协议。 此外，BGP-LS-SPF还可以支持多种BGP-SPF相关模型，包括直接连接、间接连接和多路反射器等。这些模型的不同组合提供了不同的部署选项和可靠性需求。文稿还讨论了如何使用BGP-LS-SPF和BGP SPF算法来计算最短路径，以支持BGP-LS SPF的安全性和快速收敛。 总的来说，BGP-LS SPF提供了一种灵活的方式来利用BGP和BGP SPF的优势，可以在大规模数据中心中实现高效的路由管理。
- Diff: 新版本的英文标准文稿主要介绍了两种不同的BGP部署模型：一种是使用标准的BGP协议和路径矢量路由（SPF）算法来完成路由计算；另一种则是将BGP协议和SPF算法结合在一起，通过引入BGP-LS网络层可达信息（NLRI）和短路径优先（SPF）算法实现。 相比于旧版，新版本的主要区别在于： 1. 增加了对BGP-LS协议的支持，使得BGP能够处理与IPv4和IPv6相同的IP流量工程（TE）信息。 2. 支持多种BGP-LS扩展，包括但不限于增加新的BGP-LS属性类型、改进BGP-LS-SPF端点标志等。 3. 实现了BGP SPF算法，取代了原来的基于SPF算法的决策过程。 4. 在错误处理方面，增加了更详细的信息，并且描述了如何在不同场景下正确处理错误消息。 总的来说，新版本的文稿提供了更多的灵活性，允许BGP更好地适应大规模数据中心的复杂需求。同时，它也简化了BGP的工作流程，使BGP能够在不依赖其他路由协议的情况下提供高效的路由服务。
pce
- Title: Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths
- Authors: Mike Koldychev(mkoldych@proton.me), Siva Sivabalan(msiva282@gmail.com), Samuel Sidor(ssidor@cisco.com), Colby Barth(cbarth@juniper.net), Shuping Peng(pengshuping@huawei.com), Hooman Bidgoli(hooman.bidgoli@nokia.com)
- Summary: 本文主要介绍了一种新的协议，用于在路径计算元素（PCE）协议中表示和管理SR（Segment Routing）政策候选路径。该协议扩展了PCEP标准，支持在SR Policy上下文中使用PCEP LSP来建立、更新和删除标签交换路径（LSP）。同时，也对一些与SR Policy相关的概念进行了说明，如SR Policy标识符、SR Policy候选路径标识符等。 总的来说，本文提出了一套新的协议架构，使SR Policy可以作为PCEP的一部分，与其他LSP一起形成一个关系组。通过这种方式，不仅可以简化PCEP协议的消息交互，还可以提高实现效率。这对于网络设计者来说是一个重要的技术进步。
- Diff: 摘要 本文档详细说明了在Path Computation Element（PCE）协议（PCEP）扩展中支持信号SR Policy候选路径为PCEP LSP和表示候选路径在SR Policy中的成员身份的机制。此外，它还更新了RFC 8231以允许对包含特定约束和优化指标的段路由（SR）标签交换路径（LSP）进行带状态的操作，无需使用路径计算请求和回复消息。这些修改适用于Segment Routing（SR）通过MPLS（SR-MPLS）和Segment Routing（SRv6）。本文档不涉及SR Policy与绑定到TE隧道的BSID的关系，但基于该关系定义了SR Policy的属性。本文还提供了关于SR Policy能力、计算优先级等信息的新TLV，以及一个独立的能力协商过程来配置和取消SR Policy能力。 新版本的主要区别在于： - 支持SR Policy候选路径作为PCEP LSP，并表示候选路径在SR Policy中的成员身份。 - 更新了RFC 8231，允许对包含特定约束和优化指标的SR Label Switched Path（LSP）进行带状态的操作，无需使用路径计算请求和回复消息。 - 提供了用于SR Policy能力、计算优先级和其他相关信息的新TLV。 - 增加了一个新的SR Policy协会类型，即SR Policy Association，用于封装候选路径集合。 由于引入了新的PCEP对象和特性，需要一个新的能力协商过程来管理和控制SR Policy的能力，而不是依赖于现有方法。
spring
- Title: Considerations for SRv6 across Untrusted Domain
- Authors: Changwang Lin(linchangwang.04414@h3c.com), Ce Zhou(zhouce@gd.chinamobile.com), Mengxiao Chen(mengxiao.ietf@outlook.com)
- Summary: 本文讨论了在不信任域内部署Segment Routing (SRv6)时，如何使用IPSec技术来保护SRv6数据包。文稿首先介绍了SRv6在企业网络中的应用场景（例如，分支机构与中心站点之间的通信），以及SD-WAN到云数据中心之间的连接场景。然后，提出了一种解决方案，即通过IPSec隧道将两个不信任域内的SRv6数据包进行封装，并加密整个数据包以防止中间不信任域的风险。最后，对这个方案的安全性进行了简要讨论，并给出了相关的参考文献。总的来说，本文提供了一个有效的解决方案来解决SRv6跨不信任域的问题，同时确保数据包的安全性和隐私。
- Diff: 摘要 在一个信任域内运行的段路由（SR）可以应用于数据平面中的IPv6数据包，并通过Segment Routing Header（SRH）执行源路由。由于安全考虑，[RFC8402]指出SR在信任域内运行，且必须对端点进行过滤。[RFC8754]描述了确保SRv6信任域部署的安全模型： - SRv6信任域内的边缘节点：任何进入SR域并指向SR域内部SID的IPv6数据包都会被丢弃。 - SRv6信任域内的每个节点：将从外部地址发送到SR域的SIDs的IPV6数据包丢弃。 存在一个问题，即整个SRv6信任域与不受信任的域隔离时，需要跨越这个中间域的SRv6数据包。图1显示了两个受信任的域和另一个未信任的域之间的连接。在图2中，分支机构网络和中心网络是SRv6兼容的，但中间网络是一个互联网，不是信任的。 当分支网络的主机H1需要访问数据中心SC时，它会携带带有SRH的SRv6 SIDs的IPv6数据包，包括分支和中心网络的转发路径中的SIDs。该数据包被转发到R2后，需要穿越互联网到达R3。然后，它沿着剩余的SRv6 SIDs在中心网络的路径被转发到SC。 ------------ ------------ / / / / / H1 ... R2 / --- Internet --- / R3 ... SC / / / / / ------------ ------------ 分支 中心 图2：跨互联网的SRv6企业网络 图3显示了一个SD-WAN到云数据中心（DC）的情况。CPE1直接连接到PE1，但CPE2通过第三方ISP连接到PE1。当客户需要访问云服务时，CPE会封装外层IPv6头和SRH。SRv6 SIDs在SRH中可能包含PE1的绑定SID、GW和云服务的Service SID。尽管CPE2被服务提供商信任，但由于是从第三方ISP，因此其数据包需要穿过一个不信任的域。 --------------------- / 服务商 / +------+ /+-----+ +-----+ / +-----+ | CPE1 |---/-| PE1 |----| PE2 |-/---| GW | +------+ / +-----+ +-----+/ +-----+ / | / DC --------------------- | --------- +------+ / 第三方 ISP / | CPE2 |---/ 跨接ISP / +------+ / 介于ISP / --------- 图3：SDWAN到云数据中心跨第三方提供者 这个文档描述了一些跨不受信任域的SRv6使用IPSec技术的情况。边界的SRv6域应通过IPSec隧道将SRv6数据包引导至另一端的SRv6域。可以通过以下方法配置静态路由或分配终点X SID来实现： - 配置来自外部接口的SRv6 SIDs或相反端点的地址，目的地为SRv6信任域内的SID。 - 将终点X SID分配给IPSec隧道并在SR Policy中包含。 从SRv6的信任域的角度来看，外部接口面向不受信任域的边界的边缘节点是外部接口。根据[RFC8754]，任何进入SRv6信任域的外部接口并将SID传递给SRv6信任域的数据包会被丢弃。当边缘节点收到IPSec隧道传输的包时，外层IPv6头的目标将是其隧道地址，而不是SID。因此，所提出的解决方案符合SRv6信任域的安全部署。此外，内部数据包的SRH由ESP加密，从而避免了在不受信任域内传输的SRv6数据包暴露源路由信息，这有助于降低中间不受信任域的风险。 请注意，所提出解决方案的安全性依赖于IPSec机制。如果IPSec隧道被攻击，则SRv6信任域可能会暴露给攻击。然而，由于IPSec隧道的使用，内部数据包的SRH已加密，因此在不受信任域内传输的SRv6数据包不会暴露源路由信息，从而降低了中间不受信任域的风险。 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005,
SEC
lamps
- Title: Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA
- Authors: Jake Massimo(jakemas@amazon.com), Panos Kampanakis(kpanos@amazon.com), Sean Turner(sean@sn3rd.com), Bas Westerbaan(bas@westerbaan.name)
- Summary: 本文主要讨论了模块型基于数字签名算法（ML-DSA）在X.509证书和证书撤销列表(CRL)中的使用。ML-DSA是一种量子安全的数字签名标准，其安全性依赖于模块型拉普拉斯问题模态的困难度。本文详细介绍了ML-DSA的使用，包括标识符、公钥和私钥格式等，并描述了相应的算法特性。此外，还定义了与ML-DSA相关的参数，以及如何使用这些参数来创建和验证数字签名。最后，对本文进行了总结并提到了一些未来的工作方向。
- Diff: 以上新版本的英文标准文稿相对于旧版，做了以下主要修改和改进： 1. 更改了文档标题，从原来的《Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-Digital Signature Algorithms》更改为现在的《Internet X.509 Public Key Infrastructure: Algorithm Identifiers for ML-DSA》，以避免与之前已有的ML-Digital Signature Algorithms名称冲突。 2. 修改了对ML-DSA的定义，将之前的"Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages."更改为"Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages."，强调了其使用场景和作用。 3. 对ML-DSA签名在PKIX中的使用进行了详细描述，包括算法标识、公共密钥、私钥等细节，并指出如何编码和验证这些信息。 4. 提出了针对ML-DSA的私钥格式，即通过32位随机种子进行计算，从而解决了传统公钥加密方法容易泄露信息的问题。 5. 强调了ML-DSA的安全性考虑，如非否认性、独家所有权和消息绑定等特性，并解释了它们是如何基于SHAKE-256散列函数实现的。 6. 将ML-DSA的安全级别分为2, 3和5三个等级，并说明了每个级别的安全性要求。 7. 在安全属性方面，提出了ML-DSA具备三重安全特性，分别对应于独家拥有、消息绑定和不可撤销性。 8. 对ML-DSA的性能问题进行了讨论，如可能的泄漏以及对实现的影响。 总的来说，本版本的主要区别在于对ML-DSA的介绍更加全面深入，对具体实现细节进行了详细阐述，同时加强了对ML-DSA安全性方面的讨论和分析。
WIT
ccwg
- Title: SEARCH -- a New Slow Start Algorithm for TCP and QUIC
- Authors: Jae Won Chung(jaewon.chung@viasat.com), Maryam Ataei Kachooei(mataeikachooei@wpi.edu), Feng Li(funglee@gmail.com), Mark Claypool(claypool@cs.wpi.edu)
- Summary: 这篇文档是关于改进TCP和QUIC协议中的慢启动算法(Search)的文稿。主要提出了一种新的慢启动算法(Search)，旨在提高TCP和QUIC协议在网络拥堵点处快速切换到低速率阶段的能力，减少网络拥塞并避免不必要的数据丢失。 Search算法的核心思想是在慢启动期间，每发送一个数据段都会增加大约两个最大窗口大小(MSS)，以达到双倍的数据传输率。当网络超过拥挤点时，当前发送的字节数目不应该翻倍，因为这意味着该网络已经达到了其能力极限。相反，需要检查是否前一次发送的字节数目是当前发送字节数目的两倍或更多，如果满足这个条件，则认为快启动应该退出。 Search算法在Linux内核中实现为一个模块，并在多个无线网络（包括GPS和地球同步轨道卫星）上进行了测试，结果表明它可靠地在达到拥堵点后但之前导致包丢失的情况下退出了快启动状态。
- Diff: 以上新版本的英文标准文稿描述了TCP慢启动算法(Search)的概念和工作原理，该算法用于在TCP网络连接中检测和处理链接拥塞点，并防止不必要的数据丢失。与之前的旧版本相比，新的Search算法添加了以下改进： 1. 使用滑动窗口（Sliding Window）来减少内存使用。 2. 对ACK包中的数据进行更精确的计算以避免早期退出。 3. 改进了阈值设置，使搜索能够在接近网络拥堵点时迅速退出。 总的来说，新版本的Search算法提供了更好的性能，特别是在无线链路上，可以更好地控制流量并防止不必要的丢包。
Unknown
Unknown
- Title: The Multicast Application Port
- Authors: Nathan Karstens(nate.karstens@garmin.com), Stuart Cheshire(cheshire@apple.com), Mike McBride(mmcbride7@gmail.com)
- Summary: 本文讨论了当前为每个多播应用分配UDP端口号的问题。这种做法存在冗余，因为多播地址本身就是唯一标识应用的数据。本文提出为多播应用程序专门分配一个UDP端口号，并列出了使用该端口的要求。 此外，文稿还提到了在多播网络中使用多播端口号的一些潜在问题，如其他应用程序可能会声称对特定端口号拥有专用访问权，导致安全威胁。然而，如果开发人员能够确保他们的应用不会与已经使用的端口号发生冲突，那么多播端口号就可能是一个更好的选择。 总之，本文提供了一个关于如何管理和利用多播端口号的新视角，同时也指出了存在的风险和挑战。