標題:
IETF主席回應New IP
來源:
https://www.edu.cn/xxh/yc/202004/t20200406_1720091.shtml
不久前，國際電聯ITU-T審議了有關“新IP，塑造未來網絡”的文案。該文案提出，
應以一種新IP的方式重新設計互聯網。
國際互聯網技術和標準組織IETF主席於3月30日發表聲明，就新IP提出的技術問題逐
一進行了回應。這份聲明表示，沒有任何證據表明，互聯網需要一個自上而下設計的獨立
的“新IP”體系結構。
聲明全文
親愛的同事們，
互聯網工程任務組（IETF）感謝有機會回應您的聯絡聲明。雖然我們了解這些意見可
能已經在電信標準化諮詢小組（TSAG）會議上考慮過，我們仍然要求這些意見在召開世界
電信標準化全會（WTSA）之前的會議流程中予以考慮。
互聯網的成功源於TCP/IP靈活的模塊化體系結構
IETF開發了TCP / IP協議棧，也將繼續維護和擴展它。我們相信，互聯網的成功源於
TCP/IP協議棧靈活和模塊化的體系結構。其中IP協議提供的基礎結構用豐富的異構應用程
序連接了豐富的異構網絡。我們希望現有的協議棧能像過去50年一樣繼續發展以滿足新網
絡和新應用的需求，我們還沒有看到任何證據表明我們需要一個自上而下設計的獨立而龐
大的“New IP”體系結構。
在審閱您的聯絡聲明所含提案時，我們發現有一些缺乏證據支持或不正確的內容。其
中第一條是：“首先，由於歷史原因，當前網絡的設計僅適用於兩種設備：電話和計算機
。”
IP協議棧的基本設計不限於電話和計算機，而是涵蓋了非常廣泛的設備，甚至包括了
提案中認為是未來工作部分的許多設備。例如提案在與“物聯網(IoT)”設備相關的工作
中提到“物聯網和工業互聯網的發展將在未來網絡中引入更多類型的設備”。而物聯網設
備在互聯網上的集成已經進行了十多年。IETF的一個與物聯網相關的工作組--Constraine
d RESTful
Environments工作組（CORE）剛剛迎來了它的十週年；在此期間，物聯網設備數量已達到
數十億。IETF已經完成了在網絡中集成和管理物聯網設備的大量工作，正如RFC8520所體
現的。有關IETF在物聯網工作方面的概述，請訪問<蕋ttps://www.ietf.org/blog/ietf1
05-iot-wrapup/?>。
提案中同樣將衛星網絡與IP地面網絡集成中的傳輸需求看成一項新的挑戰。而在1999
年公佈的RFC2488中就描述了衛星信道上的TCP協議。IETF在這方面的工作也從未停止，et
osat@ietf.org郵件列表中有一個活躍的社區，致力於將QUIC協議應用於衛星通信；QUIC
for SATCOM(<蕋ttps://datatracker.ietf.org/ doc/draft-kuhn-quic-4-sat/?>)則討\
論瞭如何在衛星通信中集成非TCP協議的問題。
提案提出的另一組問題是關於超低延遲的用例需求。消除不必要的延遲是IETF和ITU
（國際電信聯盟）長期共同關注的工程目標。IETF在這個領域的研究歷史可以追溯到上世
紀90年代，先後提出了多種技術，例如集成服務（IntServ），資源保留協議（RSVP），
多協議標籤交換（MPLS），差異化服務（DiffServ）和主動隊列管理（AQM）。在過去的
五年中，我們還看到了對這一領域的高度關注，並湧現出眾多新的進展：定向HTTP、傳輸
層安全（TLS）、QUIC、確定性網絡（DetNet），以及其他低延遲、低損耗、可擴展吞吐
量（L4S）技術。
那些對網絡抖動、延遲和吞吐量等屬性有嚴格要求的應用程序如今已部署在互聯網上
，同時並沒有使用提案中設想的緊密的跨層鏈接，而都是部署在現有協議和設計約束之下
。這些應用程序，包括會議、增強現實和遊戲，為改進Internet協議的特性提供了市場動
力。IETF正在多個領域中開展網絡組件或協議層次之間的協調工作。我們相信，這些努力
能夠提高這些性能指標，同時也認識到設計上的其他限制，包括業務需求、安全性和隱私
權。我們希望這些努力能滿足新型實時應用的需要，包括全息通信，而無需新的網絡體系
結構。我們還注意到，由於光速的限制，任何需
要亞毫秒級延遲的實時系統都不可避免地具有局限性。
互聯網讓所有用戶從“無需許可的創新”中獲益
提案還提出了一套關於新的身份識別系統的幾個期望屬性。其中一種說法是“異構地
址空間應該能夠彼此交流。” 但是，這似乎與提案中其他的描述衝突，因為提案中另一
段說法是：“如果所有技術都使用自己的協議作為內部通信語言，那麼在技術島嶼之間的
通信就必須部署複雜的'翻譯器'。”
不相交的尋址系統必須要求獨立的路由以確保每個系統的可達性。儘管這可能通過分
層路由（如RFC 8660中定義的SR-MPLS技術，是在IP路由之上層次）來解決，使用沒有公
共基礎的異構地址空間意味著在不同的域間必需使用複雜的翻譯程序才能實現互聯互通。
而這種翻譯需要維護額外的網絡狀態以實現互操作性，這可能會增加網絡的脆弱性和通信
延遲。
我們理解這與異構網絡互連互通的設計目標背道而馳。IETF相信這個設計目標（我們
通常表達為互操作性的需求）對於IP和Internet的發展至關重要（參見1996年發布的RFC
1958）。保持互操作性讓新的應用系統可以加入當前網絡，可以利用現有的網絡成果和已
經建立的基礎設施。這就是互聯網實現的所有網絡用戶可以從“無需許可的創新（permis
sionless innovation）”中獲益。
IETF一直致力於實時系統、不同地面和衛星網絡之間的集成，以及諸如QUIC等新傳輸
協議方面的工作，IETF相信，當前IP協議棧的發展將使我們能夠達到您建議書中所提出的
目標。我們很高興看到業界對這些研究的熱情日益高漲，我們也熱情地邀請大家共同參與
並作出貢獻。
迄今為止，對於您聯絡聲明中提及的擴展或替換現有IP協議棧的工作，我們在IETF中
尚未收到任何相關的正式提案。但我們將始終對討論此類提案保持開放的態度。
以自上而下的設計代替現有的IP協議棧將是有害的
近年來，IETF的工作越來越重視並行協議的實現和協議標準的開發過程，以便從初步
實施和互操作性測試中獲得經驗並反饋到標準的設計中。例如，HTTP/2，TLS 1.3和QUIC
等協議就從數十個不同的實現中獲益匪淺，這些實現是在標準制定過程中開發的，並在整
個互聯網的規模上進行了測試。未來標準化工作的成功很大程度上取決於現實中不同供應
商的實現經驗能反饋到標準制定過程中，而不是試圖預測無法在互聯網規模上進行測試的
需求和要求。
提案中沒有清楚表達其意圖，是要擴展或發展現有的IETF協議（例如IP協議），還是
完全取代它們。IETF為了保障全球互操作性的權益，對IP協議棧的規範保有版權和更改控
制權。如果提案的目的是擴展IETF的協議，我們希望提醒您注意IETF先前發布的IETF最新
最佳實踐文件“Procedures for Protocol Extensions and Variations（協議擴展和變
更過程，RFC 4775，BCP
125），其中描述了擴展或修改IETF規範的通用流程。在與包括ITU-T在內的其他標准開發
組織討論前，對IETF技術的擴展或修改的要求是必須先與IETF進行交流和討論。我們要求
ITU-T鼓勵那些ITU-T社區中想要更改或擴展IETF技術的人們，將他們的需求和提案帶到IE
TF來，並且在IETF有機會討論這些提案前，ITU-T拒絕接受它們。IETF也會對擴展ITU- T
技術的提案和建議進行同樣的處理。
總之，我們相信以這種自上而下的設計代替現有的IP協議棧的工作將是有害的。這樣
做將很可能會創建出網絡孤島，破壞網絡互連，並危害網絡的互操作性。自上而下的方法
將無法滿足不斷發展的應用生態系統。我們更信任現有網絡持續的模塊化和彈性的進化方
案，我們歡迎與所有有興趣的各方進行合作以提供服務。我們看不出有任何證據表明，提
案中所描述的挑戰不能通過現有IP協議套件的不斷發展而獲得解決。
回應聲明英文原文如下：
Dear Colleagues,
The Internet Engineering Task Force (IETF) appreciates the opportunity to resp
ond to your liaison statement. While we understand the Telecommunication Stand
ardization Advisory Group (TSAG) meeting at which these comments might have be
en considered is past, we request that they be considered in the process leadi
ng up to the World Telecommunication Standardization Assembly (WTSA).
The IETF developed the TCP/IP protocol stack and we continue to maintain and e
xtend it. We believe the Internet's success has resulted from its flexible,mod
ular architecture, with IP providing the fabric that connects an incredible we
alth of heterogeneous networks with an incredible wealth of heterogeneous appl
ications. We expect the existing protocol stack to continue to evolve to meet
the needs of new networks and applications, just as it has for more than 50 ye
ars. We have not seen any evidence of
the need for a monolithic "New IP"designed from the top down.
In reviewing the proposals included with your liaison statement, we find that
there are several statements that are unsupported or incorrect. The first of t
hese is: "Firstly, due to historical reasons, the current network is designed
for only two kinds of devices: telephones and computers."
The fundamental design of the IP protocol stack is not limited to telephones a
nd computers, but encompasses a very broad range of devices, including many th
at the proposals consider as future work. Work related to "Internet of Things"
(IoT) devices is, for example, noted as "the development of IoT and the indus
trial internet will introduce more types of devices into the future network."
Yet the integration of IoT devices on the Internet has been taking place for o
ver a decade. One of the relevant
working groups in the IETF,Constrained RESTful Environments (CORE), just passe
d its tenth anniversary;during this period IoT devices have come to number in
the billions. Much work has already been done to integrate and manage these de
vices on the current network, eg, in RFC 8520.A useful overview of IETF work o
n IoT is available at <https://www.ietf.org/blog/ietf105-iot-wrapup/?>.
The proposals similarly treat the transport requirements associated with the i
ntegration of satellite networks with IP terrestrial networks as a new challen
ge. Yet RFC 2488, which describes TCP over satellite channels, was published i
n 1999. Nor did the IETF's work on this stop at that point ; the蓚tosat@ietf.
org覉ailing list has an active community working on QUIC's application to sat
ellite communications; QUIC for SATCOM <蕋ttps://datatracker.ietf.org/doc/dra
ft-kuhn-quic-4-sat/?> is one
contribution to that discussion which touches particularly on the question of
a non-TCP protocol's integration with satellite communications.
Another set of issues raised by the proposals were for use cases which are ass
erted to require extremely low latency. Eliminating needless latency is, of co
urse, a useful engineering objective that both the IETF and the International
Telecommunication Union (ITU) have worked on extensively. The IETF's work in t
his area dates back to the 1990s and spans the development of such technologie
s as Integrated Services (IntServ), Resource ReSerVation Protocol (RSVP), Mult
iprotocol Label Switching (MPLS),
Differentiated Services (DiffServ), and Active Queue Management ( AQM). Over t
he last five years we have seen an intense focus in this area targeting HTTP;
Transport Layer Security (TLS); QUIC; Deterministic Networking (DetNet); and L
ow Latency, Low Loss, Scalable Throughput (L4S), among others .
Applications that are regarded as having tight requirements from the network w
ith respect to properties like jitter, latency, and throughput are being deplo
yed on the Internet today without requiring the type of tight cross-layer link
age that the proposals envision. This occurs within the constraints of existin
g protocols and designs. These applications -- which include conferencing, aug
mented reality, and gaming -- produce market pressure to improve these charact
eristics for Internet protocols. Efforts
to improve coordination between network components or layers are ongoing in se
veral areas in the IETF. We believe that the efforts most likely to improve pe
rformance on these metrics also recognize other constraints on design includin
g business imperatives, security, and privacy.We expect those efforts to conti
nue to meet the needs of newer real-time applications, including holographic c
ommunications, without the need for a new network architecture. We also note t
hat any real-time systems requiring
sub-millisecond latency inevitably have limited scope because of the constrain
ts of the speed of light.
The proposals also presented several desired aspects of a new set of identifie
r systems. One such statement was "Heterogeneous address space should be able
to communicate with each other." This appears, however, to run counter to a de
sire expressed elsewhere in the proposals: "If all technologies use their own
protocols as language to communicate internally, complex "translators" must be
employed for communication between islands."
Disjoint addressing systems necessarily require independent routing to ensure
reachability in each system. While these may be layered (as SR-MPLS, documente
d in RFC 8660, is layered on IP routing), using heterogeneous address spaces w
ithout a common substrate implies complex translation to achieve interchange a
mong the different domains. Such translation likely increases fragility and la
tency while requiring additional network state to achieve interoperability.
We understand this to be contrary to the design goal of interconnectivity acro
ss heterogeneous networks. The IETF believes this design goal, which we would
commonly express as a requirement for interoperability, is critical to the evo
lution of IP and the Internet (see RFC 1958 published in 1996). Maintaining in
teroperability ensures that these new use cases are addressed in a way that al
lows the envisioned systems to participate in the current network, building on
existing network effects and
capitalizing on the investments in infrastructure that have already been made.
This is how all users of the network come to reap the benefits of the "permis
sionless innovation" that the Internet facilitates.
Based on the ongoing work at the IETF on real-time systems, on integration amo
ng different terrestrial and satellite networks, and on new transports like QU
IC, the IETF believes that extensions of the current IP stack will allow us to
reach the goals set forth in the proposals you provided. We are happy to see
increased enthusiasm for these efforts, and we invite others to participate an
d contribute to the ongoing efforts. To date we have received no formal submis
sions for new work in the IETF that
would extend or replace IP in line with the proposals included in your liaison
statement, but we are always available to discuss the development of such sub
missions.
In recent years, IETF efforts have put an ever-increasing emphasis on developi
ng implementations and protocol standards in parallel such that the experience
gained with initial implementations and interoperability testing gets fed bac
k into the design of the standards. For example, the designs of HTTP/ 2, TLS 1
.3, and QUIC have benefitted immensely from dozens of implementations that wer
e developed alongside the standards development efforts and tested at Internet
scale. The success of future
standardization efforts will be highly dependent on how well real-world, multi
-vendor implementation experience can be fed back into the standards developme
nt process, as opposed to attempting to anticipate needs and requirements so f
ar into the future that Internet-scale testing is infeasible.
It is not entirely clear from the proposals whether their intent is to extend
or evolve existing IETF protocols such as IP, or to replace them entirely. The
IETF maintains copyright and change control for the IP specifications in the
interests of global interoperability. If the intent is to extend IETF protocol
s, we would like to draw your attention to the previously published IETF Best
Current Practice document "Procedures for Protocol Extensions and
Variations" (RFC 4775, BCP 125) which describes the general procedures to be f
ollowed in extending or modifying IETF specifications. Requirements for extens
ions or modifications to IETF technologies must be discussed with the IETF bef
ore any are worked on in other SDOs, including the ITU -T. We request that the
ITU-T encourage people in the ITU-T community who want to propose changes or
extensions to IETF technologies to bring their requirements or proposals to th
e IETF and that the ITU-T not accept
such proposals before the IETF gets a chance to discuss them. The IETF will do
the same for requirements or proposals to extend ITU-T technologies.
In conclusion, we believe the creation of a top-down design effort to replace
the existing IP protocol stack wholesale would be harmful. Doing so would most
assuredly create network islands, damage interconnection, and jeopardize inte
roperability. A top-down approach would fail to match the diverse needs of the
continuously evolving application ecosystem. We believe in the continued modu
lar, flexible evolution of the network and we welcome the opportunity to work
with all interested parties in service
of it. We see no evidence that the challenges described in the proposals canno
t be met by continuing to evolve the existing IP protocol suite.
備註：
這篇可以與上篇一起看。WHO與ITU這兩個同是UN的跨國機構，所面臨的問題幾無差異。決
策過程不透明，政治凌駕專業造成畸形的行動。排拒非會員的組織或國家，沒有會員身份
便無法取得相關資訊，甚至連無法得知決策結果、無法就問題進行回報等等。
New IP一事就是最佳的證明。在IETF的規範下，任何提案、討論、決策與請求都必須透過
RFC文件與mailing list留下記錄，並公告於網路上。這讓世界所有人都可以監督其決策
過程，並了解最新的進度。而不是像中共可以偷偷摸摸在ITU內閉門黑箱出一個New IP，
然後再讓ITU出來放話，但是對於技術細節全世界卻一無所知，任何提出的質疑也無處表
達。
ITU與ITEF充分反映了聯合國組織的無能與困境，以及可行的解決方法。
※每日每人發文、上限量為十篇，超過會劣文請注意
⊕標題選用"新聞"，請確切在標題與新聞來源處填入，否則可無條件移除(本行可移除)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.141.149.90 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/IA/M.1586585565.A.C56.html
※ 編輯: cangming (223.141.149.90 臺灣), 04/11/2020 14:14:14