Subject: [tsvwg] L4S status tracking

From: Wesley Eddy <[email-masked]>
Date: Sat, 10 Aug 2019 22:03:36 -0400

I created tickets in the TSVWG "trac" tool in order to help keep track 
of the individual things that look like they should be addressed in 
progressing L4S document set:

https://trac.ietf.org/trac/tsvwg/report/1?sort=ticket&asc=1&page=1

I'll try to update these based on the ongoing discussions, updates, 
etc., but it will make it very easy if you happen to mention the ticket 
numbers or some key words in threads and messages, when significant.

---

From: Jonathan Morton <[email-masked]>
Date: Sun, 11 Aug 2019 15:05:15 +0300

> On 11 Aug, 2019, at 5:03 am, Wesley Eddy <[email-masked]> wrote:
> 
> I created tickets in the TSVWG "trac" tool in order to help keep track of the individual things that look like they should be addressed in progressing L4S document set:
> 
> I'll try to update these based on the ongoing discussions, updates, etc., but it will make it very easy if you happen to mention the ticket numbers or some key words in threads and messages, when significant.

Thanks for that; most of the issues seem to be well described and understood.  But there is one exception in the form of #17.

The issue I was trying to raise is not that L4S has any particular difficulty with FQ, that it would not have with an equivalent non-FQ qdisc.  Rather I was responding to the proposed point on the slide *about* FQ, and identifying a situation where FQ could be defeated by L4S' poor behaviour in an RFC-3168 environment.

Since this is a relatively subtle point, I'll try to expand upon it here to avoid confusion.  Fundamentally though, this is strongly related to points A, F & G, which is why I raised the four together.

First, let's define a non-issue.  If the first significant bottleneck that an L4S flow encounters is the true one, and that bottleneck is equipped with FQ, then the worst effect that L4S can have on the network is self-inflicted.  The ability of FQ to isolate badly-behaved flows from other traffic traversing the same link is well-known, and there is nothing special about L4S that would defeat that property, on its own.  This is what I meant when I described FQ as being "pretty robust".

Where the problems arise is where the true bottleneck, supporting FQ-AQM, is preceded by a dumb FIFO (or, without very much loss of generality, a single-queue RFC-3168 AQM).  This is what I might refer to as "Sebastian's topology", and reflects the current practice of placing bufferbloat mitigation in the CPE downstream of the last-mile link.  Even with current RFC-compliant traffic, managing overall latency in this topology is challenging; in practice it requires a reservation of some percentage of the last-mile link capacity to ensure the latter's dumb queue drains into the CPE's smarter queue.

For example, the IQrouter automatically measures the last-mile link capacity, using speed tests, and sets its own FQ-AQM shaper to about 95% of that measurement.  But this still means that if a sudden flood of traffic arrives, only a twentieth part of that traffic will immediately collect in the IQrouter's queue, as opposed to the dumb queue at the last-mile link.  The effectiveness of the FQ-AQM thus depends on avoiding large floods of that sort, by quickly and effectively signalling congestion to external senders; only when the dumb FIFO is kept empty do the flow isolation properties of FQ take effect.

So you can see from this why the 4-second ramp up needed for Codel to effectively control an L4S flow with a relatively short RTT is problematic.  Indeed, as the RTT gets shorter, the time needed to gain control using a Codel ramp gets longer, because the signalling frequency needs to be proportionately higher.  Luckily, there is a practical lower limit to this trend in the form of the Codel 'target' parameter, which sets a floor on the effective RTT that needs to be controlled.

Conversely, an RFC-3168 compliant flow responds to a single CE mark after 1 RTT with a Multiplicative Decrease, so its response actually gets *faster* with shorter RTTs.  This is a property that Codel relies on to make its performance less sensitive to the precise choice of 'interval' parameter relative to path RTT.

I can walk you through the maths for the Codel response if you like.  It's reasonably straightforward, but might not be obvious from a cursory reading of the raw RFC.

 - Jonathan Morton

---

From: Greg White <[email-masked]>
Date: Tue, 13 Aug 2019 00:00:54 +0000

Hi Jonathan,

I believe this is one of the scenarios that was slated for experimentation to observe the behavior.   I don't recall hearing that experiment was conducted.  

But, I'm not sure I fully see what your concern is.  The concern I have in this scenario is that the sluggish response of the RFC3168 AQM (i.e. CoDel) in the fq_codel (or Cake) will cause the L4S sender to experience poor latency and in some cases underutilize the link.   Here is the explanation that I sent Sebastian some time ago.

[Sebastian]     But let's assume I have two flows one L4S one RFC 3168, and my link is already at saturation with each flow getting 50% of the shaper's configured bandwidth (and say 47.5% of the bottleneck's bandwidth) so the next two packets of each flow will be CE marked.

 [Greg] First off, the FQ scheduler will guarantee that both flows get 50% of the shaper capacity as long as neither flow's queue drains completely.   The legacy FQ AQM (i.e. not L4S-aware) will also operate on each queue independently, calculating a marking percentage for each one that aims to keep that queue's latency at the target value.  As long as the AQM does not cause either sender to overreact and cut its congestion window below 50% of BDP, then both will maintain packets in queue.   Since the FQ AQM in this case was designed with RFC3168 senders in mind, its response to queuing delay will be most appropriate for the RFC3168 flow, and that flow will experience packet marks and a latency over time trajectory as expected.  I don't see how the RFC3168 sender would be triggered to reduce its cwnd below 50% of BDP.  The L4S flow, on the other hand will experience a more sluggish increase in marking probability than would be ideal for L4S, and thus queuing delay will grow larger than would be ideal.  Depending on how much buffer space exists, the L4S flow might reach the tail-drop limit (which would trigger a large multiplicative reduction in cwnd, like the traditional Reno response), or the AQM would have ramped up the marking rate sufficiently to bring it under control (albeit more slowly than would be ideal).  It could be possible, due to the sluggish response of the legacy AQM, that the L4S sender cwnd undershoots 50% BDP and thus temporarily yields some capacity to the RFC3168 flow.  It seems as if your concern is that, when the RFC3168 flow cuts its cwnd to drain standing queue, that the L4S sender will shut out the RFC3168 sender on the access network link, and thus force the RFC3168 flow's FQ queue to drain completely. I don't see how this is possible.   Prior to the two CE marks in your example, both senders are (due to ACK clocking) sending at 50% of the shaper rate, plus one segment per RTT (each flow will have its own RTT). When the RFC3168 flow detects the CE mark and cuts its congestion window, it will (assuming no implementation of PRR) pause sending until sufficient outstanding ACKs are received, then it will resume sending at 50% of the shaper rate plus one segment per RTT.  Meanwhile, the L4S flow will not have cut its congestion window, and so will have continued sending at 50% of the shaper rate plus one segment per RTT, due to ACK clocking. There isn't a mechanism for it to steal capacity from the access network link and shut out the RFC3168 flow, unless (as stated previously) the RFC3168 flow's queue drains completely allowing the L4S flow to be dequeued at a higher rate (resulting in a higher ACK clocking rate, and thus a higher sending rate).  Remember that a TCP sender's response to a congestion signal (CE mark) is not to reduce its sending rate, it is to reduce its cwnd.  If the link is not yet at saturation, and a CE mark were to (unexpectedly!) arrive, then this would actually result in a decrease in sending rate.  But once the link is at saturation (the normal case for a CE mark to be generated), ACK clocking limits the sending rate to be just slightly greater than the link rate, and (assuming sufficient buffer exists) a CE mark triggers only a reduction in RTT (cwnd drops to a value that is still greater than BDP), via a pause in sending.  The long term average rate of the flow (assuming queuing delay remains bounded by either AQM or tail-drop) will be exactly equal to the link rate.

-Greg

    

    

    

    
     - Jonathan Morton

---

From: Jonathan Morton <[email-masked]>
Date: Tue, 13 Aug 2019 04:30:47 +0300

> On 13 Aug, 2019, at 3:00 am, Greg White <[email-masked]> wrote:
> 

Right, the direct experiment was not conducted at Montreal, because the L4S testbed wasn't ready for it.

Accordingly, we have had to rely on extrapolations from other experiments conducted using as similar a setup as could conveniently be arranged, and our prior experience with the topology in question.  For instance, we had effectively set up such a topology in our AirBNB while were were in Montreal, simply by installing my IQrouter adjacent to the cable modem.

For the most relevant experiment for this case, we used Pete's three test boxes and my Raspberry Pi, running SCE kernels and a firewall rule to simulate TCP Prague's congestion response.

> [Sebastian]     But let's assume I have two flows one L4S one RFC 3168, and my link is already at saturation with each flow getting 50% of the shaper's configured bandwidth…

Okay, this scenario covers a steady-state case.  I'm more concerned with transient behaviour, specifically ensuring that short-term changes in the traffic conditions result in only short-term effects on other traffic.  But there are a couple of fallacies in the following wall of text that I was able to spot, and which need squashing.

> I don't see how the RFC3168 sender would be triggered to reduce its cwnd below 50% of BDP.  (by an FQ-AQM, competing with one other bulk flow)

This is trivially demonstrable as soon as you have an RTT long enough for a given sampling tool to observe the effect reliably, and in fact you can see it in the SCE slide deck (in which there is one chart showing FQ-AQM behaviour).

RFC-3168 senders respond to single CE marks with a Multiplicative Decrease, and FQ-AQMs will provide these marks very shortly after the fair share is reached.  Assuming the standard 50% decrease is employed with NewReno, that means it will be sent down to about 25% link capacity, or more precisely, half the fair share - from where it must linearly grow back again.  CUBIC reduces to 70%, which means it is sent down to about 35% briefly, and recovers more quickly with its polynomial response.

> It seems as if your concern is that, when the RFC3168 flow cuts its cwnd to drain standing queue, that the L4S sender will shut out the RFC3168 sender on the access network link, and thus force the RFC3168 flow's FQ queue to drain completely.

No, the *eventual* convergence to fair shares in steady state is not in question.

FQ enforces it to the best of its ability (which, crucially, is determined by the traffic which makes it through the preceding network elements), and Codel (at least in COBALT form, which is what we tested) does eventually ramp up its marking rate to the point where a DCTCP response function is properly controlled.  But it takes four whole seconds to get there when a new L4S flow starts up, with default settings and the short inherent RTTs that the L4S team appears to favour.  Note that I'm not claiming that four-second queues exist, only that elevated queuing latency (peaking around 125ms) persists for four seconds.

A lot can happen in those four seconds, from the user's perspective.  It's long enough to seriously disrupt online gameplay, causing the player to miss crucial shots because his timing is thrown off by an eighth of a second.  VoIP streams will be forced to switch on their jitter buffers and pause the received audio stream to catch up, and will most likely never recover from that condition to the more realtime behaviour they previously enjoyed.  And so on.

Here is a simple experiment that should verify the existence and extent of the problem:

Control:
[Sender] -> [Baseline RTT 10ms] -> [FQ_Codel, 100% BW] -> [Receiver]

Subject:
[Sender] -> [Baseline RTT 10ms] -> [Dumb FIFO, 105% BW] -> [FQ_Codel, 100% BW] -> [Receiver]

Background traffic is a sparse latency-measuring flow, essentially a surrogate for gaming or VoIP.  The instantaneous latency experienced by this flow over time is the primary measurement.

The experiment is simply to start up one L4S flow in parallel with the sparse flow, and let it run in saturation for say 60 seconds.  Repeat with an RFC-3168 flow (NewReno, CUBIC, doesn't matter which) for a further experimental control.  Flent offers a convenient method of doing this.

Correct behaviour would show a brief latency peak caused by the interaction of slow-start with the FIFO in the subject topology, or no peak at all for the control topology; you should see this for whichever RFC-3168 flow is chosen as the control.  Expected results with L4S in the subject topology, however, are a peak extending about 4 seconds before returning to baseline.

Please let me know how you get on with reproducing this result.

 - Jonathan Morton

---

From: Greg White <[email-masked]>
Date: Wed, 14 Aug 2019 23:27:46 +0000

Comments prefaced with "[GREG]" below.

    > On 13 Aug, 2019, at 3:00 am, Greg White <[email-masked]> wrote:
[snip]

    

[GREG] I don't believe that what I described was a fallacy.   To be clear, when an RFC-3168 sender responds to a CE mark with a multiplicative decrease, what it is multiplicatively decreasing is NOT its sending rate.  It is decreasing its cwnd.  When cwnd is greater than BDP, sending rate is no longer proportional to cwnd.  In an idealized case, the bottleneck link will trigger cwnd reductions such that the reduced cwnd is exactly equal to the BDP (and queuing delay is zero), which means that the cwnd reduction is triggered when cwnd = BDP/0.5 (for Reno) or cwnd = BDP/0.7 (for Cubic).  This preserves continuous 100% link utilization with the minimum queuing delay, and cwnd is always >= BDP.   The CA sender behavior when cwnd is >= BDP is (via ack clocking or pacing) that the sender sends traffic *just slightly* greater than the link bandwidth (B) causing the queue to grow.  In the case of Reno the sender rate is B + (1 MTU / RTT) (where RTT = base RTT + queue delay), and the queue grows by one MTU each RTT.   The situation where the behavior you described would happen is if there is essentially zero buffering, and so the cwnd reduction happens when cwnd = BDP.  This would reduce the cwnd to 0.5*BDP (Reno) or 0.7*BDP (Cubic) which (due to zero queuing delay) would actually equate to a sending rate of 0.5*B or 0.7*B.  If the AQM in the systems you are using causes this behavior, then I would argue that it is not CoDel.  The design of CoDel was such that the *minimum* (not maximum) sojourn time over the last window (100ms) is driven to 5ms or below (not zero).  It does happen that CoDel occasionally drops/marks excessively, such that the queue fully drains and the link is underutilized, but not to the extent you are describing (unless CoDel is implemented incorrectly or misconfigured).    The goal of AQMs has generally been to preserve (in as many scenarios as possible) near 100% link utilization, while minimizing queuing delay.   Is your AQM aiming at some other goal?

    
[GREG] Neither (in my view) is the rapid convergence to fair shares**.  But this apparently needs to be demonstrated.

    FQ enforces it to the best of its ability (which, crucially, is determined by the traffic which makes it through the preceding network elements),
    
[GREG]  FQ enforces it *precisely* as long as neither queue drains completely.

    and Codel (at least in COBALT form, which is what we tested) does eventually ramp up its marking rate to the point where a DCTCP response function is properly controlled.  But it takes four whole seconds to get there when a new L4S flow starts up, with default settings and the short inherent RTTs that the L4S team appears to favour.  Note that I'm not claiming that four-second queues exist, only that elevated queuing latency (peaking around 125ms) persists for four seconds.

[GREG]  Ok, here I think we're on the same page.  The CoDel response is too sluggish to bring latency under control as quickly as we would like.  An L4S sender is aiming to see 2 marks per RTT, and the normal CoDel ramp up of marking rate (in marks/second) over time is approx. 7 + 50*t.  So, for a 10ms RTT, where an L4S sender is wanting to see 200 marks per second, CoDel would take about 3.8 seconds to ramp up to that level.  We will need to conduct the experiments to see what the latency looks like during that period, but if it is up to 125ms of queuing delay for 3.8 seconds, then that is not what an L4S sender would be wanting to see.  (minor quibble: I'd argue that VoIP probably isn't the best example of an L4S flow, but cloud gaming certainly is.)   

    Control:
    
    Subject:

    
    
[GREG] I would not expect to see the FIFO holding a queue in either case, (i.e. I would expect this phenomenon to only affect the latency of the L4S flow) as long as BW > 24 Mbps (see ** below) but we will see.

     - Jonathan Morton

[GREG] ** In "Sebastian's Topology" the difference between the Dumb FIFO BW and the FQ_Codel BW needs to be greater than or equal to one MTU / RTT (for Reno or DCTCP/Prague) to prevent queuing from occurring in the Dumb FIFO for a single steady state flow.  I suppose it needs to be an even bigger difference to prevent FIFO queuing with Cubic.   What is the rationale for using a multiplicative factor (105%) rather than an additive one scaled based on expected CC dynamics?

---

From: Jonathan Morton <[email-masked]>
Date: Thu, 15 Aug 2019 18:55:56 +0300

> [GREG] I don't believe that what I described was a fallacy.   To be clear, when an RFC-3168 sender responds to a CE mark with a multiplicative decrease, what it is multiplicatively decreasing is NOT its sending rate.  It is decreasing its cwnd.  When cwnd is greater than BDP, sending rate is no longer proportional to cwnd.  In an idealized case, the bottleneck link will trigger cwnd reductions such that the reduced cwnd is exactly equal to the BDP (and queuing delay is zero), which means that the cwnd reduction is triggered when cwnd = BDP/0.5 (for Reno) or cwnd = BDP/0.7 (for Cubic).  This preserves continuous 100% link utilization with the minimum queuing delay, and cwnd is always >= BDP.

In other words, you expect the peak queue delay to be equal to the baseline RTT.  This is also the best-practice sizing guideline for dumb FIFOs - which should give you pause.

> The goal of AQMs has generally been to preserve (in as many scenarios as possible) near 100% link utilization, while minimizing queuing delay.   Is your AQM aiming at some other goal?

Actually, most AQMs in my experience aim to reduce latency as much as possible, while keeping link utilisation as high as is compatible with that goal.  Or, more precisely, to achieve some tunable balance between link utilisation and queue delay.  In particular, they aim to reduce latency relative to a dumb FIFO (see above).

Certainly that is the stated goal of Codel: to keep the *standing* persistent queue limited to 5ms by default, where the default settings explicitly assume an Internet-scale 100ms RTT, and to drop or mark only as many packets as is necessary to achieve that.  The "measurement window" defined by the interval parameter is only to filter out short-term bursts that have many natural causes in the Internet, effectively defining "short term" as "within one assumed RTT".

Codel actually does a better job of maintaining low queue latency than PIE does.  Please do look at the SCE slide deck and note the peak latency increments of roughly 5ms in each chart involving an RFC-3168 flow, almost exactly on Codel's target.  So if you think Codel is not designed for low latency, rather than high throughput, then you have seriously misunderstood it.

> [GREG]  FQ enforces it *precisely* as long as neither queue drains completely.

And, as I was trying to point out, it is possible for a large burst from one flow collecting in the dumb FIFO to starve the FQ of packets from the other flow, thereby inhibiting its ability to give that flow its fair share of throughput.  Simultaneously both flows suffer the increased latency caused by the dumb FIFO's depth, because the FQ is also inhibited from this aspect of its flow isolation task.

> [GREG]  Ok, here I think we're on the same page.  The CoDel response is too sluggish to bring latency under control as quickly as we would like.

Please stop making that incorrect statement.  Codel's response is very well tuned and very effective on RFC-3168 compliant flows.  The DCTCP response used by L4S is what is too sluggish, when provided with RFC-3168 compliant CE marks.  That is why DCTCP was effectively barred from use outside tightly controlled datacentre environments.

>    Here is a simple experiment that should verify the existence and extent of the problem:

(snip)

> [GREG] I would not expect to see the FIFO holding a queue in either case, (i.e. I would expect this phenomenon to only affect the latency of the L4S flow) as long as BW > 24 Mbps (see ** below) but…

That's precisely why I want you to actually perform the experiment as described.  I think you will see something you weren't expecting.

> [GREG] ** In "Sebastian's Topology" the difference between the Dumb FIFO BW and the FQ_Codel BW needs to be greater than or equal to one MTU / RTT (for Reno or DCTCP/Prague) to prevent queuing from…

Again, you are thinking primarily about the steady state, after the exit of slow-start and when the AQM has settled on the correct marking rate.  That's an important design point, but we must also consider the transient states which lead up to that point.

In particular, the last couple of RTTs of slow-start are critical and tend to involve bursts of a full BDP in excess of the correct final cwnd - and that's *if* it is handled optimally.  Slow start can be very nasty to handle.

Additionally, those four seconds in which Codel is desperately ramping up to find the correct marking rate for L4S are also important.  We saw 125ms peak delays here on a 10ms RTT.  Your question should be where that delay mostly appears - in the dumb FIFO or in the FQ-AQM?

The greater the margin between the FIFO link rate and the FQ-AQM shaper, the faster the FIFO will drain into the FQ-AQM, and the greater benefit the latter will have in these transient cases.  For RFC-3168 flows, we've found a 5% margin to be adequate, and so that's what is deployed in at least one commercial device.  Hence why I'm inviting you to directly compare RFC-3168 and L4S behaviour in this topology.

 - Jonathan Morton

---

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 23 Aug 2019 14:01:15 +0000

Hi Wes,

I’d like to add a smaller item that is mostly editorial and can hopefully be sorted just out by re-wording, albeit it may require a careful analysis of all documents.

As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY , I object to the terms „traditional TCP“ and also „classic TCP“ or „legacy“ TCP when referring to a TCP implementation according to IETF standards-track RFCs.

To me as a non-native native speaker, all these terms have a negative connotation. I also think this language is typical to marketing material.

My prefered term when referring to TCP according to standards-track specification is „standard TCP“. I would also be fine with other terms as long as they are neutral and make clear that experiments do not replace, deprecate, or outperform standards.

Similarly, I think that term such as „classic“ is not appropriate for the TCP standard congestion control („Reno“). As of today, this is the TCP congestion control algorithm on standards track that has IETF consensus. The term in the TCPM charter is „TCP standard congestion control“. I also think that terms such as „Reno-compatible“ or the like would be neutral.

Note that I do not object to the terms „classic ECN“, „legacy ECN“, „legacy AQM“ or the like, i.e., if the context is ECN and not specifically TCP or the TCP congestion control. I believe it is up to the TSVWG do decide if this term shall be used for compliance to RFC 3168. I have no strong opinion on that. As far as I can see, most use of the term „classic“ is in this context and I don’t ask for changes in those cases.

Some use of the term „Classic Service“ may also require careful review to clearly separate it from TCP Standard behavior.

Note that some use of the term „Classic TCP“ would probably also apply to „Classic QUIC“ once the QUIC standard is finished. To me as a non-native speaker, it would be really strange to use the term „classic“ in the context of a brand-new transport protocol. IMHO in that case the term „classic“ would be even more confusing.

I also add the TCPM list in CC to ensure consistency.

Thanks

Michael (with no hat)

Von: Wesley Eddy<mailto:[email-masked]>
Gesendet: Sonntag, 11. August 2019 07:08
An: [email-masked]<mailto:[email-masked]>
Betreff: [tsvwg] L4S status tracking

---

From: "Black, David" <[email-masked]>
Date: Fri, 23 Aug 2019 14:23:14 +0000

> Note that I do not object to the terms "classic ECN", "legacy ECN", "legacy AQM" or the like, i.e.,

> if the context is ECN and not specifically TCP or the TCP congestion control. I believe it is up to

> the TSVWG do decide if this term shall be used for compliance to RFC 3168. I have no strong opinion on that.

> As far as I can see, most use of the term "classic" is in this context and I don't ask for changes in those cases.

"RFC 3168 ECN" is the more precise term, whose use I would encourage.  Use of "classic ECN" seems ok, as long as the draft makes it clear that "classic" means "RFC 3168" in this context.

Thanks, --David (as an author of RFC 3168)

From: tsvwg <[email-masked]> On Behalf Of Scharf, Michael
Sent: Friday, August 23, 2019 10:01 AM
To: Wesley Eddy; [email-masked]
Cc: [email-masked]
Subject: Re: [tsvwg] L4S status tracking

[EXTERNAL EMAIL]

Hi Wes,

I'd like to add a smaller item that is mostly editorial and can hopefully be sorted just out by re-wording, albeit it may require a careful analysis of all documents.

As already noted in https://mailarchive.ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY<https://mailarchive..ietf.org/arch/msg/tsvwg/zZkYZKF-hDvWO3I5MudwpNkKyHY> , I object to the terms "traditional TCP" and also "classic TCP" or "legacy" TCP when referring to a TCP implementation according to IETF standards-track RFCs.

My prefered term when referring to TCP according to standards-track specification is "standard TCP". I would also be fine with other terms as long as they are neutral and make clear that experiments do not replace, deprecate, or outperform standards.

Similarly, I think that term such as "classic" is not appropriate for the TCP standard congestion control ("Reno"). As of today, this is the TCP congestion control algorithm on standards track that has IETF consensus. The term in the TCPM charter is "TCP standard congestion control". I also think that terms such as "Reno-compatible" or the like would be neutral.

Note that I do not object to the terms "classic ECN", "legacy ECN", "legacy AQM" or the like, i.e., if the context is ECN and not specifically TCP or the TCP congestion control. I believe it is up to the TSVWG do decide if this term shall be used for compliance to RFC 3168. I have no strong opinion on that. As far as I can see, most use of the term "classic" is in this context and I don't ask for changes in those cases.

Some use of the term "Classic Service" may also require careful review to clearly separate it from TCP Standard behavior.

Note that some use of the term "Classic TCP" would probably also apply to "Classic QUIC" once the QUIC standard is finished. To me as a non-native speaker, it would be really strange to use the term "classic" in the context of a brand-new transport protocol. IMHO in that case the term "classic" would be even more confusing.

Thanks

Michael (with no hat)