Roland,
On 21/03/2019 08:49, Bless, Roland (TM) wrote:
Hi,
Am 21.03.19 um 09:02 schrieb Bob Briscoe:
Just to rapidly reply,
On 21/03/2019 07:46, Jonathan Morton wrote:
The ECN field was never intended to be used as a classifier, except to
distinguish Not-ECT flows from ECT flows (which a middlebox does need
to know, to choose between mark and drop behaviours). It was intended
to be used to convey congestion information from the network to the
receiver. SCE adheres to that ideal.
Each PHB has a forwarding behaviour a DSCP re-marking behaviour and an
ECN marking behaviour. The ECN field is the claissifer for the ECN
marking behaviour.
That's exactly the reason, why using ECT(1) as classifier for L4S
behavior is not the right choice. L4S should use a DSCP for
classification, because it is actually defining a PHB.
1/ First Terminology
The definition of 'PHB' includes the drop or ECN-marking behaviour. For
instance, you see this in WRED or in PCN (Pre-Congestion Notification).
If you want to solely talk about scheduling, pls say the scheduling PHB.
2/ The architectural intent of the ECN field
For many years (long before we thought of L4S) I have been making sure
that ECN propagation through the layers supports the duality of ECN
behaviours as both a classifier (on the way down from L7/L4 to L3/2) and
as a return value (on the way back up).
The architecture of ECN is determined by the valid codepoint
transitions. They are:
1. 00->11
2. 10->11
3. 01->11
4. 10->01
The first three were in RFC3168, but it did not preclude the fourth.
The fourth was first standardized in RFC6660 (which I co-authored). This
had to be isolated from the e2e use of ECN by inclusion of a DSCP as well.
The relatively late addition of the fourth approach means that an
attempt to mark using the SCE approach (10->01) is more likely to find
that it gets reversed when the outer header is decapsulated, if the
decapsulator hasn't been updated to the latest RFC that catered for this
fourth transition (RFC6040, also co-authored by me).
L4S follows the original RFC3168 approach
SCE uses the fourth
So, SCE proposes to use /a/ correct approach, but it might not work.
Whereas L4S uses the original correct approach.
3a/ DualQ L4S AQMs
With the DualQ, the difference between the two queues is both in their
ECN marking behaviour and in their forwarding/scheduling behaviour.
However, whenever there's traffic in the classic queue the coupling
between the AQMs overrides the network scheduler. The coupling is solely
ECN behaviour not scheduling behaviour. So the primary difference
between the queues is in their ECN-marking behaviour.
What do I mean by "the coupling overrides the network scheduler"? The
network scheduler certainly does give priority to L4S packets whenever
they arrive, but the coupling makes the L4S sources control how often
packets arrive. It's tough to reason about, because we haven't had a
mechanism like this before.
2b/ FQ L4S AQMs
If the AQM is implemented with per flow queues, the picture is clearer.
The only difference between the queues is in the ECN marking behaviour
of the different AQMs.
Bob
Regards
Roland
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
