John, Richard,
I do not believe an IP (v4) option or a v6 extension would be necessary.
If ECT(1) were used that would surely be sufficient alone.
I believe the main criteria for an identifier for this new service are:
1. preferably orthogonal to Diffserv classes.
2. preferably end-to-end in scope
3. preferably classic (RFC168) ECN and 'L4S' ECN would not permanently
burn two codepoints, since it seems that 'L4S' could eventually subsume
classic ECN (a fork would not be needed, because classic ECN doesn't
seem to do anything that L4S cannot do).
*ECT(1) **
*Seems a good identifier, but it has the following problems:
a) L4S traffic would need to be distinguished from classic ECN both when
unmarked (ECT0 vs ECT1) and when marked (CE vs CE???). Ie. congestion
experienced (CE) would have to be shared between the classes. It would
not be so problematic if all queues classified all CE packets as the
lowest latency class (L4S); CE packets from classic flows would then be
delivered early out of order, requiring some buffering, but probably no
more buffering than is already needed for retransmissions, and at least
they would never be late out of order. See also {Note 1}.
b) ECT(1) is the last available ECN codepoint (for both v4 & v6). Using
ECT(1) for L4S and ECT(0) for Classic ECN would burn the last codepoint
just for migration purposes (contravening my criterion #3). If we could
predict that migration might one day finish, we could foresee a time
when ECT(0) might become available again. But that's a long shot.
c) For the record, the following uses of ECT(1) have been proposed by
the IETF and by researchers:
* receiver cheat detection (the ECN nonce [RFC3540] - experimental)
* ECN path testing (ECN for RTP [RFC6679] - standards track)
* various intermediate congestion level proposals (including PCN
[RFC6660] - standards track)
* various fast-start proposals (in research, e.g. VCP)
d) PCN is defined for a controlled environment, so that's not a problem.
THe wording or RTP-ECN does not mandate the use of ECT(1), but it is not
always clear that it is optional either. So I am trying to find out
whether any implementations have used ECT(1). Even if none of the IETF
uses of ECT(1) are problematic in practice, we should think very
carefully before burning ECT(1) for L4S, because there do appear to be
new uses being proposed for it that address a new potentially important
class of problems: getting up to speed fast.
*DSCP**
*It might be better to distinguish L4S ECN from Classic ECN by using
only ECT(0) and CE, but also using a distinctive DS codepoint for L4S.
L4S could start off local-network only (e.g. for a network operator's
premium services), or a global DSCP could be burned so that hosts could
set it without needing to be configured for the network they happen to
be connected to at any one time. Then, assuming all Classic ECN might
eventually migrate to L4S ECN, a DSCP would no longer be needed as well
as ECT(0) to identify L4S. Then the ECN field alone could represent L4S
end-to-end.
We all know that DSCP has the following problems:
a) Diffserv is not orthogonal to Diffserv (obviously), so multiple DSCPs
might be needed for L4S in each DS class
b) DS is not end-to-end
c) few global DSCPs left, altho certainly there are more DS codepoints
than ECN codepoints left.
*Summary**
*Combining ECT(0) and CE with a globally assigned DSCP solely during
initial deployment of L4S seems the least worst choice.
Bob
{Note 1} I'm sure some SDN-enabled equipment could easily decide which
queue to classify CE packets into by classifying transport layer flows
or the SPI of IPsec packets based on earlier ECT(1) or ECT(0) packets.
However, we shouldn't and can't always rely on visibility of transport
flows or on availability of SDN-capable hardware.
On 28/07/15 15:50, John Leslie wrote:
Scheffenegger, Richard <[email protected]> wrote:
Regarding the identifier to differentiate legacy ECN (cc reaction on
ECN per RTT = cc reaction to loss in RTT) and the differentiated
response (proportional to the # of CEs per RTT) is an open question.
Wide open!
Perhaps we can start to gather the views of the group on this list
already; There have been other uses for ECT(1) been proposed over
time, and it has also been pointed out that repurposing a DiffServ
Codepoint may not be the easierst to do from a procedural view.
Nor (IMHO) is a repurposed DiffServ Codepoint likely to work well.
OTOH, I think the time is ripe to deprecate ECN Nonce; and reserve
ECT(1) for (currently) Experimental uses.
We could pretty easily combine that with an IP Option to define the
particular experiment, and even record data about forwarding node action.
(Admittedly, this is more difficult in IPv6, so I suggest initially
considering IPv4; and then adding an IPv6 kludge, probably hop-by-hop.)
IMHO, the only other uses for ECT(1) that have approached "traction"
relate to differentiation of forwarder action for ECN marking.
Also, I would like to encourage members of the aqm wg to review the various
versions of http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn
(the technical content did change in each version substantially).
Disclaimer, I'm one of the authors of that draft.
I believe I've reviewed them all; but is it truly reasonable to expect
all WG members to review more than the latest one?
Fundamentally, the latest version calls for three counters, to be
masked to low-order bits reporting changes in the counters. There are
three possibilities on _where_ these bits will be reported. (I'd rather
not bike-shed the virtues of each yet...)
draft-briscoe-aqm-dualq-coupled does not appear to have been posted
yet: I'll be only too happy to discuss it once it is...
Fundamentally, it proposes to identify a separate low-latency queue
which will report via ECN a near-zero-latency condition (vs. a zero
congestion in this second queue), while the default queue operates by
a legacy AQM mecanism, probably signaled by packet drop.
This strikes me as Experimental: there are a number of issues, such
as how this low-latency queue overflows and what happens when it does,
which need to be resolved before we could even consider Standards Track.
At first blush, this looks like a good match for Experimental use of
ECT(1).
--
John Leslie <[email protected]>
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
--
________________________________________________________________
Bob Briscoe http://bobbriscoe.net/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
