[tsvwg] From L4S to SCE+DSCP and RFC-4774 Option 3

[Jonathan Morton <[e-mail]>]

In light of Koen's musings, and knowing that Low Latency DOCSIS relies on a "dual queue" structure with an explicit classifier as its lowest common denominator, here is a summary of how SCE can be combined with a DSCP to make that work.  The result is similar to DualQ-Coupled in most implementation aspects, so I think it should be feasible to adapt a device designed for the one into the other.

First, a brief review of how SCE itself works:

1: ECT(1) is a congestion signal output (renamed SCE) from the network.  It is not normally emitted by senders.  SCE flows are identified in the ECN field as ECN Capable Transports compliant with RFC-3168 (because they are) by emitting ECT(0) at origin.

2: CE marks are applied by both RFC-3168 and SCE AQMs under similar circumstances, at a relatively deep queue threshold.  They are fed back by the receiver to the sender in the normal way, using ECE and CWR in the case of TCP, and senders are expected to respond with a Multiplicative Decrease compliant to RFC-8511.  Not-ECT traffic receives packet drops instead.

3: SCE marks are applied to packets carrying ECT(0), at a shallower queue threshold.  RFC-3168 middleboxes and receivers ignore the distinction between ECT(0) and ECT(1), so they are not affected by this.  SCE receivers feed SCE marks back to the sender using a spare TCP flag renamed ESCE, or using the detailed ECN feedback mechanisms already present in SCTP, QUIC, etc.  Technically AccECN could also be used for TCP, but I consider the ACE field to be a liability since SCE doesn't need to feed back more than one CE mark per RTT.  RFC-3168 senders ignore ESCE feedback, while SCE senders respond with an Additive Decrease of some sort per ESCE.  The "two marks per RTT is steady state" function of DCTCP is acceptable here.

4: If SCE and non-SCE traffic occupy the same queue and the same SCE AQM instance simultaneously, then the SCE traffic will tend to give way to the non-SCE traffic since there is a range of queue depths where SCE signals are applied but CE signals are not.  Therefore some mechanism to distinguish between the two is needed at SCE-marking nodes in the network.  Nodes which only drop packets or are merely RFC-3168 compliant do not need this.  Nodes which do not expect to receive reliable distinguishing information are free to implement RFC-3168 marking without SCE support, as at present.

Our prototype SCE qdiscs use either FQ to distinguish flows into individual queues and AQMs, or AF to distinguish flows into individual AQMs in the same queue.  Since there is no more space in the ECN field, identifying SCE traffic explicitly to the network, which would be needed for a "dual queue" implementation without per-flow AQMs, needs to be done in some other field.  A natural choice is the Diffserv field, next door in the same byte as the ECN field.

Because Diffserv codes are often changed along paths in the Internet, some SCE-capable traffic will not be so identified, but cooperating networks can arrange to ensure that SCE-identifying DSCPs are preserved within their sphere of influence, in order to benefit from the improved service quality.  This should be the case in the environments where L4S-type service is envisaged, ie. between an ISP's subscribers and a CDN attached to that ISP.

The SCE DSCP therefore requests a PHB, at SCE dual-queue nodes, where it requests use of the L queue in which SCE marks are applied at a shallow threshold, rather than the C queue in which only CE marks are applied at a deeper threshold.  Should the L queue overflow, the spilled traffic goes to the C queue instead of being dropped.

The L and C queues SHOULD be serviced in a deficit-round-robin manner so that one type of traffic does not dominate the other.  If information about flow counts is available, this SHOULD be used to weight the servicing so that throughput is proportional to flow count.  This is the main technical difference from DualQ-Coupled, besides the details of the signalling mechanisms.

When the DSCP of SCE-capable traffic is lost before reaching a dual-queue SCE node, this traffic will go to the C queue and receive RFC-3168 signals (CE marks).  The SCE transport will correctly interpret these because the signalling in the ECN field is not ambiguous, and clearly indicates the type of congestion signal actually applied.  Thus it will compete on an equitable basis with other traffic in the C queue, and losing the DSCP does not create a hazard.

The DSCP may also be used by other SCE-marking nodes, which normally use FQ or AF, as a hint to distinguish mixed SCE and non-SCE traffic sharing the same 5-tuple.  This may be helpful when mixed traffic passes through a tunnel that intentionally hides the distinction between flows, but still reveals the TOS byte of the inner packet in the header of the outer packet.  Without this information, the SCE traffic would be disadvantaged under this specific combination of circumstances.

It is not mandatory for an SCE-capable sender to emit the SCE DSCP.  SCE receivers do not need to inspect the Diffserv field before interpreting the ECN field, nor do SCE senders need to check for a correct DSCP on acks before interpreting ECN feedback.  A negotiation to ensure both endpoints of the connection understand SCE should occur before asserting SCE capability using a DSCP, so that traffic not capable of responding to SCE signals is not inadvertently sent into the L queue.  Details of this negotiation are not yet finalised.

It is possible to assign more than one DSCP to indicate SCE capability, with different PHBs requested.  For example, one DSCP could indicate SCE capability with best-effort high-throughput service, another might indicate SCE capability with low-latency service, and a third could indicate SCE capability with low-cost service.  This should be by arrangement between the sender and the network, although an assignment of recommended DSCPs may also be desirable.

Many networks will have no distinction between these classes of service, and will be satisfied if SCE merely does its primary job of settling on a cwnd close to the true BDP - a genuine solution to the long-standing bufferbloat problem.

Because SCE is fully compatible with existing RFC-3168 compliant infrastructure, it does not require the network to be prepared as a whole in advance of endpoint deployment, but can be deployed incrementally as convenient.  This would be a key advantage of converting existing proposals to deploy L4S into proposals to deploy SCE or SCE+DSCP.

 - Jonathan Morton