draft-ietf-tsvwg-aqm-dualq-coupled-13.txt		draft-ietf-tsvwg-aqm-dualq-coupled-14.txt
	Transport Area working group (tsvwg) K. De Schepper		Transport Area working group (tsvwg) K. De Schepper
	Internet-Draft Nokia Bell Labs		Internet-Draft Nokia Bell Labs
	Intended status: Experimental B. Briscoe, Ed.		Intended status: Experimental B. Briscoe, Ed.
	Expires: May 19, 2021 Independent		Expires: September 11, 2021 Independent
	G. White		G. White
	CableLabs		CableLabs
	November 15, 2020		March 10, 2021
	DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput		DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput
	(L4S)		(L4S)
	draft-ietf-tsvwg-aqm-dualq-coupled-13		draft-ietf-tsvwg-aqm-dualq-coupled-14
	Abstract		Abstract
	The Low Latency Low Loss Scalable Throughput (L4S) architecture		The Low Latency Low Loss Scalable Throughput (L4S) architecture
	allows data flows over the public Internet to achieve consistent low		allows data flows over the public Internet to achieve consistent low
	queuing latency, generally zero congestion loss and scaling of per-		queuing latency, generally zero congestion loss and scaling of per-
	flow throughput without the scaling problems of standard TCP Reno-		flow throughput without the scaling problems of standard TCP Reno-
	friendly congestion controls. To achieve this, L4S data flows have		friendly congestion controls. To achieve this, L4S data flows have
	to use one of the family of 'Scalable' congestion controls (TCP		to use one of the family of 'Scalable' congestion controls (TCP
	Prague and Data Center TCP are examples) and a form of Explicit		Prague and Data Center TCP are examples) and a form of Explicit
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 19, 2021.		This Internet-Draft will expire on September 11, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 10, line 39 ¶		skipping to change at page 10, line 39 ¶
	Classic traffic,		Classic traffic,
	The L4S queue has latency priority, but the coupling from the Classic		The L4S queue has latency priority, but the coupling from the Classic
	to the L4S AQM (explained below) ensures that it does not have		to the L4S AQM (explained below) ensures that it does not have
	bandwidth priority over the Classic queue.		bandwidth priority over the Classic queue.
	2. DualQ Coupled AQM		2. DualQ Coupled AQM
	There are two main aspects to the approach:		There are two main aspects to the approach:
	o the Coupled AQM that addresses throughput equivalence between		o The Coupled AQM that addresses throughput equivalence between
	Classic (e.g. Reno, Cubic) flows and L4S flows (that satisfy the		Classic (e.g. Reno, Cubic) flows and L4S flows (that satisfy the
	Prague L4S requirements).		Prague L4S requirements).
	o the Dual Queue structure that provides latency separation for L4S		o The Dual Queue structure that provides latency separation for L4S
	flows to isolate them from the typically large Classic queue.		flows to isolate them from the typically large Classic queue.
	2.1. Coupled AQM		2.1. Coupled AQM
	In the 1990s, the `TCP formula' was derived for the relationship		In the 1990s, the `TCP formula' was derived for the relationship
	between the steady-state congestion window, cwnd, and the drop		between the steady-state congestion window, cwnd, and the drop
	probability, p of standard Reno congestion control [RFC5681] . To a		probability, p of standard Reno congestion control [RFC5681] . To a
	first order approximation, the steady-state cwnd of Reno is inversely		first order approximation, the steady-state cwnd of Reno is inversely
	proportional to the square root of p.		proportional to the square root of p.
	skipping to change at page 15, line 43 ¶		skipping to change at page 15, line 43 ¶
	Indeed, this Base AQM with just the squared output and no L4S queue		Indeed, this Base AQM with just the squared output and no L4S queue
	can be used as a drop-in replacement for PIE [RFC8033], in which case		can be used as a drop-in replacement for PIE [RFC8033], in which case
	it is just called PI2 [PI2]. PI2 is a principled simplification of		it is just called PI2 [PI2]. PI2 is a principled simplification of
	PIE that is both more responsive and more stable in the face of		PIE that is both more responsive and more stable in the face of
	dynamically varying load.		dynamically varying load.
	Curvy RED is derived from RED [RFC2309], but its configuration		Curvy RED is derived from RED [RFC2309], but its configuration
	parameters are insensitive to link rate and it requires less		parameters are insensitive to link rate and it requires less
	operations per packet. However, DualPI2 is more responsive and		operations per packet. However, DualPI2 is more responsive and
	stable over a wider range of RTTs than Curvy RED. As a consequence,		stable over a wider range of RTTs than Curvy RED. As a consequence,
	DualPI2 has attracted more development and evaluation attention than		at the time of writing, DualPI2 has attracted more development and
	Curvy RED, leaving the Curvy RED design incomplete and not so fully		evaluation attention than Curvy RED, leaving the Curvy RED design
	evaluated.		incomplete and not so fully evaluated.
	Both AQMs regulate their queue in units of time rather than bytes.		Both AQMs regulate their queue in units of time rather than bytes.
	As already explained, this ensures configuration can be invariant for		As already explained, this ensures configuration can be invariant for
	different drain rates. With AQMs in a dualQ structure this is		different drain rates. With AQMs in a dualQ structure this is
	particularly important because the drain rate of each queue can vary		particularly important because the drain rate of each queue can vary
	rapidly as flows for the two queues arrive and depart, even if the		rapidly as flows for the two queues arrive and depart, even if the
	combined link rate is constant.		combined link rate is constant.
	It would be possible to control the queues with other alternative		It would be possible to control the queues with other alternative
	AQMs, as long as the normative requirements (those expressed in		AQMs, as long as the normative requirements (those expressed in
	capitals) in Section 2.5 are observed.		capitals) in Section 2.5 are observed.
	2.5. Normative Requirements for a DualQ Coupled AQM		2.5. Normative Requirements for a DualQ Coupled AQM
	The following requirements are intended to capture only the essential		The following requirements are intended to capture only the essential
	aspects of a DualQ Coupled AQM. They are intended to be independent		aspects of a DualQ Coupled AQM. They are intended to be independent
	of the particular AQMs used for each queue.		of the particular AQMs used for each queue.
	2.5.1. Functional Requirements		2.5.1. Functional Requirements
			A Dual Queue Coupled AQM implementation MUST comply with the
			prerequisite L4S behaviours for any L4S network node (not just a
			DualQ) as specified in section 5 of [I-D.ietf-tsvwg-ecn-l4s-id].
			These primarily concern classification and remarking as briefly
			summarized in Section 2.3 earlier. But there is also a subsection
			(5.5) giving guidance on reducing the burstiness of the link
			technology underlying any L4S AQM.
	A Dual Queue Coupled AQM implementation MUST utilize two queues, each		A Dual Queue Coupled AQM implementation MUST utilize two queues, each
	with an AQM algorithm. The two queues can be part of a larger		with an AQM algorithm. The two queues can be part of a larger
	queuing hierarchy [I-D.briscoe-tsvwg-l4s-diffserv].		queuing hierarchy [I-D.briscoe-tsvwg-l4s-diffserv].
	The AQM algorithm for the low latency (L) queue MUST be able to apply		The AQM algorithm for the low latency (L) queue MUST be able to apply
	ECN marking to ECN-capable packets.		ECN marking to ECN-capable packets.
	The scheduler draining the two queues MUST give L4S packets priority		The scheduler draining the two queues MUST give L4S packets priority
	over Classic, although priority MUST be bounded in order not to		over Classic, although priority MUST be bounded in order not to
	starve Classic traffic. The scheduler SHOULD be work-conserving.		starve Classic traffic. The scheduler SHOULD be work-conserving.
	skipping to change at page 25, line 42 ¶		skipping to change at page 25, line 46 ¶
	implementations were tested.		implementations were tested.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[I-D.ietf-tsvwg-ecn-l4s-id]		[I-D.ietf-tsvwg-ecn-l4s-id]
	Schepper, K. and B. Briscoe, "Identifying Modified		Schepper, K. and B. Briscoe, "Identifying Modified
	Explicit Congestion Notification (ECN) Semantics for		Explicit Congestion Notification (ECN) Semantics for
	Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-		Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
	id-11 (work in progress), November 2020.		id-12 (work in progress), November 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition		[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
	of Explicit Congestion Notification (ECN) to IP",		of Explicit Congestion Notification (ECN) to IP",
	RFC 3168, DOI 10.17487/RFC3168, September 2001,		RFC 3168, DOI 10.17487/RFC3168, September 2001,
	<https://www.rfc-editor.org/info/rfc3168>.		<https://www.rfc-editor.org/info/rfc3168>.
	skipping to change at page 27, line 48 ¶		skipping to change at page 27, line 48 ¶
	November 2018.		November 2018.
	[I-D.cardwell-iccrg-bbr-congestion-control]		[I-D.cardwell-iccrg-bbr-congestion-control]
	Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson,		Cardwell, N., Cheng, Y., Yeganeh, S., and V. Jacobson,
	"BBR Congestion Control", draft-cardwell-iccrg-bbr-		"BBR Congestion Control", draft-cardwell-iccrg-bbr-
	congestion-control-00 (work in progress), July 2017.		congestion-control-00 (work in progress), July 2017.
	[I-D.ietf-tsvwg-l4s-arch]		[I-D.ietf-tsvwg-l4s-arch]
	Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low		Briscoe, B., Schepper, K., Bagnulo, M., and G. White, "Low
	Latency, Low Loss, Scalable Throughput (L4S) Internet		Latency, Low Loss, Scalable Throughput (L4S) Internet
	Service: Architecture", draft-ietf-tsvwg-l4s-arch-07 (work		Service: Architecture", draft-ietf-tsvwg-l4s-arch-08 (work
	in progress), October 2020.		in progress), November 2020.
	[I-D.ietf-tsvwg-nqb]		[I-D.ietf-tsvwg-nqb]
	White, G. and T. Fossati, "A Non-Queue-Building Per-Hop		White, G. and T. Fossati, "A Non-Queue-Building Per-Hop
	Behavior (NQB PHB) for Differentiated Services", draft-		Behavior (NQB PHB) for Differentiated Services", draft-
	ietf-tsvwg-nqb-03 (work in progress), November 2020.		ietf-tsvwg-nqb-03 (work in progress), November 2020.
	[L4Sdemo16]		[L4Sdemo16]
	Bondarenko, O., De Schepper, K., Tsang, I., and B.		Bondarenko, O., De Schepper, K., Tsang, I., and B.
	Briscoe, "Ultra-Low Delay for All: Live Experience, Live		Briscoe, "Ultra-Low Delay for All: Live Experience, Live
	Analysis", Proc. MMSYS'16 pp33:1--33:4, May 2016,		Analysis", Proc. MMSYS'16 pp33:1--33:4, May 2016,
	skipping to change at page 31, line 27 ¶		skipping to change at page 31, line 27 ¶
	[DualPI2Linux]. The specification of the DualQ Coupled AQM for		[DualPI2Linux]. The specification of the DualQ Coupled AQM for
	DOCSIS cable modems and CMTSs is available in [DOCSIS3.1] and		DOCSIS cable modems and CMTSs is available in [DOCSIS3.1] and
	explained in [LLD].		explained in [LLD].
	A.1. Pass #1: Core Concepts		A.1. Pass #1: Core Concepts
	The pseudocode manipulates three main structures of variables: the		The pseudocode manipulates three main structures of variables: the
	packet (pkt), the L4S queue (lq) and the Classic queue (cq). The		packet (pkt), the L4S queue (lq) and the Classic queue (cq). The
	pseudocode consists of the following six functions:		pseudocode consists of the following six functions:
	o the initialization function dualpi2_params_init(...) (Figure 2)		o The initialization function dualpi2_params_init(...) (Figure 2)
	that sets parameter defaults (the API for setting non-default		that sets parameter defaults (the API for setting non-default
	values is omitted for brevity)		values is omitted for brevity)
	o the enqueue function dualpi2_enqueue(lq, cq, pkt) (Figure 3)		o The enqueue function dualpi2_enqueue(lq, cq, pkt) (Figure 3)
	o the dequeue function dualpi2_dequeue(lq, cq, pkt) (Figure 4)		o The dequeue function dualpi2_dequeue(lq, cq, pkt) (Figure 4)
	o recur(q, likelihood) for de-randomized ECN marking (shown at the		o The recurrence function recur(q, likelihood) for de-randomized ECN
	end of Figure 4).		marking (shown at the end of Figure 4).
	o the L4S AQM function laqm(qdelay) (Figure 5) used to calculate the		o The L4S AQM function laqm(qdelay) (Figure 5) used to calculate the
	ECN-marking probability for the L4S queue		ECN-marking probability for the L4S queue
	o the base AQM function that implements the PI algorithm		o The base AQM function that implements the PI algorithm
	dualpi2_update(lq, cq) (Figure 6) used to regularly update the		dualpi2_update(lq, cq) (Figure 6) used to regularly update the
	base probability (p'), which is squared for the Classic AQM as		base probability (p'), which is squared for the Classic AQM as
	well as being coupled across to the L4S queue.		well as being coupled across to the L4S queue.
	It also uses the following functions that are not shown in full here:		It also uses the following functions that are not shown in full here:
	o scheduler(), which selects between the head packets of the two		o scheduler(), which selects between the head packets of the two
	queues; the choice of scheduler technology is discussed later;		queues; the choice of scheduler technology is discussed later;
	o cq.len() or lq.len() returns the current length (aka. backlog) of		o cq.len() or lq.len() returns the current length (aka. backlog) of
	skipping to change at page 35, line 42 ¶		skipping to change at page 35, line 42 ¶
	signals, but it still desynchronizes the saw-teeth of the flows.		signals, but it still desynchronizes the saw-teeth of the flows.
	Line 6 calculates p_L as the maximum of the coupled L4S		Line 6 calculates p_L as the maximum of the coupled L4S
	probability p_CL and the probability from the native L4S AQM p'_L.		probability p_CL and the probability from the native L4S AQM p'_L.
	This implements the max() function shown in Figure 1 to couple the		This implements the max() function shown in Figure 1 to couple the
	outputs of the two AQMs together. Of the two probabilities input		outputs of the two AQMs together. Of the two probabilities input
	to p_L in line 6:		to p_L in line 6:
	* p'_L is calculated per packet in line 5 by the laqm() function		* p'_L is calculated per packet in line 5 by the laqm() function
	(see Figure 5),		(see Figure 5),
	* whereas p_CL is maintained by the dualpi2_update() function		* Whereas p_CL is maintained by the dualpi2_update() function
	which runs every Tupdate (Tupdate is set in line 13 of		which runs every Tupdate (Tupdate is set in line 13 of
	Figure 2. It defaults to 16 ms in the reference Linux		Figure 2. It defaults to 16 ms in the reference Linux
	implementation because it has to be rounded to a multiple of 4		implementation because it has to be rounded to a multiple of 4
	ms).		ms).
	o If a Classic packet is scheduled, lines 10 to 17 drop or mark the		o If a Classic packet is scheduled, lines 10 to 17 drop or mark the
	packet with probability p_C.		packet with probability p_C.
	The Native L4S AQM algorithm (Figure 5) is a ramp function, similar		The Native L4S AQM algorithm (Figure 5) is a ramp function, similar
	to the RED algorithm, but simplified as follows:		to the RED algorithm, but simplified as follows:
	skipping to change at page 44, line 31 ¶		skipping to change at page 44, line 31 ¶
	pseudocode (Figure 11). To aid comparison, the line numbers are kept		pseudocode (Figure 11). To aid comparison, the line numbers are kept
	in step between the two by using letter suffixes where the longer		in step between the two by using letter suffixes where the longer
	code needs extra lines.		code needs extra lines.
	B.1. Curvy RED in Pseudocode		B.1. Curvy RED in Pseudocode
	The pseudocode manipulates three main structures of variables: the		The pseudocode manipulates three main structures of variables: the
	packet (pkt), the L4S queue (lq) and the Classic queue (cq) and		packet (pkt), the L4S queue (lq) and the Classic queue (cq) and
	consists of the following five functions:		consists of the following five functions:
	o the initialization function cred_params_init(...) (Figure 2) that		o The initialization function cred_params_init(...) (Figure 2) that
	sets parameter defaults (the API for setting non-default values is		sets parameter defaults (the API for setting non-default values is
	omitted for brevity);		omitted for brevity);
	o the dequeue function cred_dequeue(lq, cq, pkt) (Figure 4);		o The dequeue function cred_dequeue(lq, cq, pkt) (Figure 4);
	o the scheduling function scheduler(), which selects between the		o The scheduling function scheduler(), which selects between the
	head packets of the two queues.		head packets of the two queues.
	It also uses the following functions that are either shown elsewhere,		It also uses the following functions that are either shown elsewhere,
	or not shown in full here:		or not shown in full here:
	o the enqueue function, which is identical to that used for DualPI2,		o The enqueue function, which is identical to that used for DualPI2,
	dualpi2_enqueue(lq, cq, pkt) in Figure 3;		dualpi2_enqueue(lq, cq, pkt) in Figure 3;
	o mark(pkt) and drop(pkt) for ECN-marking and dropping a packet;		o mark(pkt) and drop(pkt) for ECN-marking and dropping a packet;
	o cq.len() or lq.len() returns the current length (aka. backlog) of		o cq.len() or lq.len() returns the current length (aka. backlog) of
	the relevant queue in bytes;		the relevant queue in bytes;
	o cq.time() or lq.time() returns the current queuing delay		o cq.time() or lq.time() returns the current queuing delay
	(aka. sojourn time or service time) of the relevant queue in units		(aka. sojourn time or service time) of the relevant queue in units
	of time (see Note a in Appendix A.1).		of time (see Note a in Appendix A.1).
End of changes. 22 change blocks.
	25 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/