rfc9330_term.txt		rfc9331_term.txt
	3. Terminology		1.2. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
			"OPTIONAL" in this document are to be interpreted as described in
			BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	Classic Congestion Control: A congestion control behaviour that can		Classic Congestion Control: A congestion control behaviour that can
	coexist with standard Reno [RFC5681] without causing significantly		coexist with standard Reno [RFC5681] without causing significantly
	negative impact on its flow rate [RFC5033]. The scaling problem		negative impact on its flow rate [RFC5033]. With Classic
	with Classic congestion control is explained, with examples, in		congestion controls, such as Reno or CUBIC, because the flow rate
	Section 5.1 and in [RFC3649].		has scaled since TCP congestion control was first designed in
			1988, it now takes hundreds of round trips (and growing) to
			recover after a congestion signal (whether a loss or an ECN mark)
			as shown in the examples in Section 5.1 of the L4S architecture
			[RFC9330] and in [RFC3649]. Therefore, control of queuing and
			utilization becomes very slack, and the slightest disturbances
			(e.g., from new flows starting) prevent a high rate from being
			attained.
	Scalable Congestion Control: A congestion control where the average		Scalable Congestion Control: A congestion control where the average
	time from one congestion signal to the next (the recovery time)		time from one congestion signal to the next (the recovery time)
	remains invariant as the flow rate scales, all other factors being		remains invariant as the flow rate scales, all other factors being
	equal. For instance, DCTCP averages 2 congestion signals per		equal. This maintains the same degree of control over queuing and
	round trip, whatever the flow rate, as do other recently developed		utilization whatever the flow rate, as well as ensuring that high
	Scalable congestion controls, e.g., Relentless TCP [RELENTLESS],		throughput is robust to disturbances. For instance, DCTCP
	TCP Prague [PRAGUE-CC] [PragueLinux], BBRv2 [BBRv2] [BBR-CC], and		averages 2 congestion signals per round trip, whatever the flow
	the L4S variant of SCReAM for real-time media [SCReAM] [RFC8298].		rate, as do other recently developed Scalable congestion controls,
	See Section 4.3 of [RFCYYY2] for more explanation.		e.g., Relentless TCP [RELENTLESS], TCP Prague [PRAGUE-CC]
			[PragueLinux], BBRv2 [BBRv2] [BBR-CC], and the L4S variant of
			SCReAM for real-time media [SCReAM] [RFC8298]. See Section 4.3
			for more explanation.
	Classic Service: The Classic service is intended for all the		Classic Service: The Classic service is intended for all the
	congestion control behaviours that coexist with Reno [RFC5681]		congestion control behaviours that coexist with Reno [RFC5681]
	(e.g., Reno itself, CUBIC [RFC8312], Compound [CTCP], and TFRC		(e.g., Reno itself, CUBIC [RFC8312], Compound [CTCP], and TFRC
	[RFC5348]). The term 'Classic queue' means a queue providing the		[RFC5348]). The term 'Classic queue' means a queue providing the
	Classic service.		Classic service.
	Low Latency, Low Loss, and Scalable throughput (L4S) service: The		Low Latency, Low Loss, and Scalable throughput (L4S) service: The
	'L4S' service is intended for traffic from Scalable congestion		'L4S' service is intended for traffic from Scalable congestion
	control algorithms, such as the Prague congestion control		control algorithms, such as the Prague congestion control
	[PRAGUE-CC], which was derived from DCTCP [RFC8257]. The L4S		[PRAGUE-CC], which was derived from DCTCP [RFC8257]. The L4S
	service is for more general traffic than just Prague -- it allows		service is for more general traffic than just Prague -- it allows
	the set of congestion controls with similar scaling properties to		the set of congestion controls with similar scaling properties to
	Prague to evolve, such as the examples listed above (Relentless		Prague to evolve, such as the examples listed above (Relentless
	and SCReAM). The term 'L4S queue' means a queue providing the L4S		and SCReAM). The term 'L4S queue' means a queue providing the L4S
	service.		service.
	The terms Classic or L4S can also qualify other nouns, such as		The terms Classic or L4S can also qualify other nouns, such as
	'queue', 'codepoint', 'identifier', 'classification', 'packet',		'queue', 'codepoint', 'identifier', 'classification', 'packet',
	and 'flow'. For example, an L4S packet means a packet with an L4S		and 'flow'. For example, an L4S packet means a packet with an L4S
	identifier sent from an L4S congestion control.		identifier sent from an L4S congestion control.
	Both Classic and L4S services can cope with a proportion of		Both Classic and L4S services can cope with a proportion of
	unresponsive or less-responsive traffic as well but, in the L4S		unresponsive or less-responsive traffic as well but, in the L4S
	case, its rate has to be smooth enough or low enough to not build		case, its rate has to be smooth enough or low enough to not build
	a queue (e.g., DNS, Voice over IP (VoIP), game sync datagrams,		a queue (e.g., DNS, Voice over IP (VoIP), game sync datagrams,
	etc.).		etc.).
	Reno-friendly: The subset of Classic traffic that is friendly to the		Reno-friendly: The subset of Classic traffic that is friendly to the
	standard Reno congestion control defined for TCP in [RFC5681].		standard Reno congestion control defined for TCP in [RFC5681].
	The TFRC spec [RFC5348] indirectly implies that 'friendly' is		The TFRC spec [RFC5348] indirectly implies that 'friendly' is
	defined as "generally within a factor of two of the sending rate		defined as "generally within a factor of two of the sending rate
	of a TCP flow under the same conditions". Reno-friendly is used		of a TCP flow under the same conditions". Reno-friendly is used
	here in place of 'TCP-friendly', given the latter has become		here in place of 'TCP-friendly', given the latter has become
	imprecise, because the TCP protocol is now used with so many		imprecise, because the TCP protocol is now used with so many
	different congestion control behaviours, and Reno is used in non-		different congestion control behaviours, and Reno is used in non-
	TCP transports, such as QUIC [RFC9000].		TCP transports, such as QUIC [RFC9000].
	Classic ECN: The original Explicit Congestion Notification (ECN)		Classic ECN: The original Explicit Congestion Notification (ECN)
	protocol [RFC3168] that requires ECN signals to be treated as		protocol [RFC3168] that requires ECN signals to be treated as
	equivalent to drops, both when generated in the network and when		equivalent to drops, both when generated in the network and when
	responded to by the sender.		responded to by the sender.
	L4S uses the ECN field as an identifier [RFCYYY2] with the names		L4S uses the ECN field as an identifier with the names for the
	for the four codepoints of the 2-bit IP-ECN field unchanged from		four codepoints of the 2-bit IP-ECN field unchanged from those
	those defined in the ECN spec [RFC3168], i.e., Not-ECT, ECT(0),		defined in the ECN spec [RFC3168], i.e., Not-ECT, ECT(0), ECT(1),
	ECT(1), and CE, where ECT stands for ECN-Capable Transport and CE		and CE, where ECT stands for ECN-Capable Transport and CE stands
	stands for Congestion Experienced. A packet marked with the CE		for Congestion Experienced. A packet marked with the CE codepoint
	codepoint is termed 'ECN-marked' or sometimes just 'marked' where		is termed 'ECN-marked' or sometimes just 'marked' where the
	the context makes ECN obvious.		context makes ECN obvious.
	Site: A home, mobile device, small enterprise, or campus where the		Site: A home, mobile device, small enterprise, or campus where the
	network bottleneck is typically the access link to the site. Not		network bottleneck is typically the access link to the site. Not
	all network arrangements fit this model, but it is a useful,		all network arrangements fit this model, but it is a useful,
	widely applicable generalization.		widely applicable generalization.
	Traffic Policing: Limiting traffic by dropping packets or shifting
	them to a lower service class (as opposed to introducing delay,
	which is termed 'traffic shaping'). Policing can involve limiting
	the average rate and/or burst size. Policing focused on limiting
	queuing but not the average flow rate is termed 'congestion
	policing', 'latency policing', 'burst policing', or 'queue
	protection' in this document. Otherwise, the term rate policing
	is used.
End of changes. 5 change blocks.
	17 lines changed or deleted		33 lines changed or added
This html diff was produced by rfcdiff 1.48.