Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay
draft-briscoe-tsvwg-ecn-l4s-id-02

Document Type Replaced Internet-Draft (tsvwg WG)
Last updated 2017-05-04 (latest revision 2016-10-31)
Replaced by draft-ietf-tsvwg-ecn-l4s-id
Stream IETF
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Adopted by a WG
Document shepherd No shepherd assigned
IESG IESG state Replaced by draft-ietf-tsvwg-ecn-l4s-id
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-briscoe-tsvwg-ecn-l4s-id-02.txt

Abstract

This specification defines the identifier to be used on IP packets for a new network service called low latency, low loss and scalable throughput (L4S). It is similar to the original (or 'Classic') Explicit Congestion Notification (ECN). 'Classic' ECN marking was required to be equivalent to a drop, both when applied in the network and when responded to by a transport. Unlike 'Classic' ECN marking, for packets carrying the L4S identifier, the network applies marking more immediately and more aggressively than drop, and the transport response to each mark is reduced and smoothed relative to that for drop. The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a 'Classic' flow under the same conditions. However, the much more frequent control signals and the finer responses to them result in ultra-low queuing delay without compromising link utilization, even during high load. Examples of new active queue management (AQM) marking algorithms and examples of new transports (whether TCP-like or real- time) are specified separately. The new L4S identifier is the key piece that enables them to interwork and distinguishes them from 'Classic' traffic. It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off, but it can be prevented from degrading the ultra-low delay and loss of the new scalable transports.

Authors

Koen Schepper (koen.de_schepper@nokia.com)
Bob Briscoe (ietf@bobbriscoe.net)
Ing Tsang (ing-jyh.tsang@nokia.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)