Subject: Re: [tsvwg] L4S Issue #26: Q Protection: mandatory to Implement?

From: Bob Briscoe <[email-masked]>
Date: Sun, 15 Nov 2020 22:33:24 +0000

David,

I recently promised (in response to your offlist request) to summarise 
the core argument against making some form of "Latency Protection" 
mandatory to implement (offlist, we coined the phrase in quotes, to 
avoid confusion with making the specific DOCSIS Queue Protection 
algorithm mandatory).

a) When one source sends more bandwidth, others get less bandwidth 
(win-lose)
b) When one source sends lower latency traffic (e.g. scalable congestion 
control, or NQB) it also reduces latency for others (win-win)

a) The IETF has has never made per-flow rate policing mandatory to 
implement for general Internet traffic, even though there are clear 
win-lose incentives for one party to harm others.
b) So it would be perverse if the IETF made per-flow Latency Protection 
mandatory to implement for general Internet traffic, given there are not 
even win-lose incentives for anyone to harm others.

In the field of traffic protection, incentives are not the only factor 
to consider - there are three:
1) incentives
2) malice
3) accidents

Incentives are by far the most important factor, because they determine 
the /typical/ behaviour of companies and individuals. Whereas malice and 
accidents are about /anomalous/ behaviour.
Even then, despite the Internet being littered with malice and 
screw-ups, the IETF has never made per-flow rate policing mandatory. So, 
before mandating Latency Protection, think carefully about why this is, 
and why the Internet has been successful without the IETF intervening.

The whole idea of the DualQ Coupled AQM was to be lightweight enough 
that it could be added to all sorts of queues. After initial deployments 
at access link bottlenecks, the architecture says further nodes could 
follow, e.g. interconnection points, particularly peerings, and nodes 
that are not typically bottlenecks, but might be, e.g. CDN access, etc. 
We have produced a modular design for a reason. Making latency 
protection mandatory to implement jams two architecturally separate 
modules into one by administrative dictat. I would go so far as to say 
that would be architectural vandalism.

Part of the L4S experiment is to determine whether Latency Protection is 
necessary (that's been stated in the architecture from the initial 
draft). If latency protection proves to be unnecessary (as I believe it 
will, mainly because incentives are aligned), the Internet will have a 
nice low cost solution for low latency. If the IETF makes it mandatory 
to implement from the start, the market will never be able to decide.

I understand that many operators are risk-averse (I have worked in and 
among them all my career). So after Greg had hired me to work on Low 
Latency DOCSIS and to design its QProt, Greg and I proposed that QProt 
should be mandatory to implement, possible to disable, but on by 
default. And that's what was agreed for *DOCSIS*. That's the right level 
of industry forum to decide whether a security mechanism will be 
mandatory to implement. It's focused on a particular deployment 
scenario. ISPs can make latency protection mandatory in their 
invitations to tender. Other bodies, like the Broadband forum can too, 
for their particular deployment scenarios.

Here we're doing what the IETF does well - producing component 
technologies. If the IETF does NOT mandate latency protection, it does 
NOT mean it will NOT be mandated - but only where it's appropriate by 
the appropriate bodies. The IETF is not the appropriate body.

_____________________
Finally, if what you really mean is that ECN and priority queuing can be 
exploited to attack *bandwidth* more effectively than with a drop tail 
FIFO, then I (and co-authors) would be very willing to make the current 
'SHOULD's in the two L4S docs below into 'MUST's.

1) CURRENT from 
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-5.1

    Under persistent overload an L4S marking treatment SHOULD begin using
    Classic drop until the overload episode has subsided, as recommended
    for all AQM methods in [RFC7567  <https://tools.ietf.org/html/rfc7567>] (Section 4.2.1  <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-4.2.1>), which follows the
    similar advice inRFC 3168  <https://tools.ietf.org/html/rfc3168>  (Section 7  <https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-7>).

PROPOSED:
     s/SHOULD/MUST/

2) CURRENT from 
https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-12#section-2.5.1.1 

    If the DualQ Coupled AQM has detected overload, it SHOULD signal
    congestion solely using drop, irrespective of the ECN field.

PROPOSED:

    If the DualQ Coupled AQM has detected overload, it MUST
    begin using Classic drop, and continue until the overload episode
    has subsided.

Cheers

Bob

On 28/10/2020 23:28, Bob Briscoe wrote:
> David,
>
> You will recall that I and others have argued against QProt being 
> mandatory to implement using arguments about incentives. That is still 
> the main argument, which I can summarize if necessary, but that's not 
> the purpose of this email.
>
> Here. I want to add another argument that is about modularity. In the 
> latest revision of the l4s architecture you will find seven examples 
> listed of how queue protection could be implemented (eight if you 
> count the null case of no protection):
> https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-8.2
> Only two have the queue protection integrated with the AQM. Five use 
> distributed arrangements, with characterization of the traffic 
> congestion located remote from the bottleneck queues that are being 
> protected.
>
> For a distributed solution, when a developer implements an L4S AQM in 
> one box, it doesn't even make sense for the IETF to mandate that she 
> must implement queue protection with it. In a distributed approach, 
> queue protection would be an independent module running on a different 
> box.
>
> The only way that would make sense would be if the IETF was writing a 
> normative standard for a complete traffic control system. Then we 
> would be telling operators what to do, not implementers. System 
> standards are usually the territory of the ITU, or the broadband 
> forum, etc. The IETF is usually expected to specify component parts - 
> protocols, algorithms - "Do one thing and do it well".
>
> Regards
>
>
> Bob
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: "Black, David" <[email-masked]>
Date: Mon, 16 Nov 2020 21:52:27 +0000

Bob,
[writing as an individual, not as a WG chair]

> I recently promised (in response to your offlist request) to summarise the core argument against making some form of "Latency Protection"
> mandatory to implement (offlist, we coined the phrase in quotes, to avoid confusion with making the specific DOCSIS Queue Protection algorithm mandatory).

I suggest an initial focus on the NQB (Non-Queue-Building) PHB, for which not building queues is a defining characteristic ;-) and which has an analogous mandatory-to-implement issue for queue protection.  Conclusions from that discussion are likely to provide insight on how to deal with the analogous (but more involved/complex) L4S issue.  In order to deliver the NQB PHB behavior, it is necessary to ensure that packet queues aren’t built in network node queues for NQB traffic.  That is what I understand “Traffic Latency Protection” to mean – it’s the behavior that network node packet queues aren’t built in a fashion that significantly impacts NQB traffic latency.  In that context, queue latency protection (e.g., the DOCSIS queue protection mechanism) would then refer to specific implementation mechanisms for providing that behavior.

> a) When one source sends more bandwidth, others get less bandwidth (win-lose)
> b) When one source sends lower latency traffic (e.g. scalable congestion control, or NQB) it also reduces latency for others (win-win)
>
> a) The IETF has has never made per-flow rate policing mandatory to implement for general Internet traffic, even though there are clear win-lose incentives for one party to harm others.
> b) So it would be perverse if the IETF made per-flow Latency Protection mandatory to implement for general Internet traffic, given there are not even win-lose incentives for anyone to harm others.

This appears to have confused the end (traffic latency protection) with the means (per-flow queue latency protection) and more importantly to have overlooked the win-lose phenomenon of non-NQB traffic building packet queues in the low-latency NQB network node queues.  The latter is a win for the queue-building traffic that has bypassed the Default queues and a lose for NQB traffic that is delayed by the resulting packet queues.

Rather than dive into this further, I suggest starting from something that Ingemar wrote at the start of earlier discussion on this topic:

>> If one take 5G access as example, the bearer concept and the scheduling mechanism will

>> for the vast majority of use cases prevent that one “user” cause harm to others.

>> Thus it should not be mandatory to implement queue protection.

For 5G networks, I agree - I am confident that (if asked) Ingemar will be able to write a paragraph explaining how 5G bearers and scheduling mechanisms can assure that packet queues are never built in 5G NQB network node queues.  Moreover, I view this sort of pro-active prevention approach as preferable to reactive consequences approaches such as by the DOCSIS queue protection mechanism.  That mechanism reacts to increasing NQB queue delay on a network node by identifying the responsible traffic flows and evicting those flows to the Default queue.  Taking this up a level, I’d suggest the following overall structure:

Network node implementation of reactive queue latency protection mechanisms for NQB traffic (e.g., DOCSIS queue protection) is not necessary for traffic latency protection under the following circumstances:
i)                    5G network nodes, because ... (with trust that Ingemar will be able to supply a longer explanation)
ii)                   ...

The task at hand is to fill out that list with a goal of covering all the circumstances/cases/situations that matter, e.g., I don’t care about low latency for avian carrier networks (see RFC 1149 and take note of its publication date), and suspect that you don’t either ;-).  If that goal can be achieved, then there should no need for a queue latency protection mechanism to be mandatory to implement.  The comment below on other industry forums strikes me as relevant to this task, although perhaps at a higher level than appropriate for this list.

The reason for proposing that task is that the rationale for a potential mandatory-to-implement requirement for a queue latency protection mechanism is analogous to a number of mandatory-to-implement requirements for security mechanisms.  The rationale commonality is not that the mechanism will always be used or even that it will be used much/most of the time.  Instead, implementation is mandatory so that the mechanism is available in circumstances where it is needed, especially if that need is discovered as operational problems arise.  This is a deliberate choice to avoid potentially severe “need but don’t have” situations by erring on the side of “have but don’t need” for implementations whose applicability includes important circumstances/cases/situations where the mechanism is likely to be needed.

Finally, I should return to per-flow rate policing in the second a)-b) list above:

> a) The IETF has has never made per-flow rate policing mandatory to implement for general Internet traffic, even though there are clear win-lose incentives for one party to harm others.
> b) So it would be perverse if the IETF made per-flow Latency Protection mandatory to implement for general Internet traffic, given there are not even win-lose incentives for anyone to harm others.

Per-flow rate policing is an implementation choice for queue latency protection mechanisms, e.g., DOCSIS queue protection.  If the above proposed task achieves its goal, then there should be no need for a mandatory-to-implement requirement for queue latency protection based on per-flow rate policing.
Thanks, --David

From: Bob Briscoe <[email-masked]>
Sent: Sunday, November 15, 2020 5:33 PM
To: Black, David
Cc: tsvwg IETF list
Subject: Re: L4S Issue #26: Q Protection: mandatory to Implement?

[EXTERNAL EMAIL]
David,

I recently promised (in response to your offlist request) to summarise the core argument against making some form of "Latency Protection" mandatory to implement (offlist, we coined the phrase in quotes, to avoid confusion with making the specific DOCSIS Queue Protection algorithm mandatory).

a) When one source sends more bandwidth, others get less bandwidth (win-lose)
b) When one source sends lower latency traffic (e.g. scalable congestion control, or NQB) it also reduces latency for others (win-win)

a) The IETF has has never made per-flow rate policing mandatory to implement for general Internet traffic, even though there are clear win-lose incentives for one party to harm others.
b) So it would be perverse if the IETF made per-flow Latency Protection mandatory to implement for general Internet traffic, given there are not even win-lose incentives for anyone to harm others.

In the field of traffic protection, incentives are not the only factor to consider - there are three:
1) incentives
2) malice
3) accidents

Incentives are by far the most important factor, because they determine the /typical/ behaviour of companies and individuals. Whereas malice and accidents are about /anomalous/ behaviour.
Even then, despite the Internet being littered with malice and screw-ups, the IETF has never made per-flow rate policing mandatory. So, before mandating Latency Protection, think carefully about why this is, and why the Internet has been successful without the IETF intervening.

The whole idea of the DualQ Coupled AQM was to be lightweight enough that it could be added to all sorts of queues. After initial deployments at access link bottlenecks, the architecture says further nodes could follow, e.g. interconnection points, particularly peerings, and nodes that are not typically bottlenecks, but might be, e.g. CDN access, etc. We have produced a modular design for a reason. Making latency protection mandatory to implement jams two architecturally separate modules into one by administrative dictat. I would go so far as to say that would be architectural vandalism.

Part of the L4S experiment is to determine whether Latency Protection is necessary (that's been stated in the architecture from the initial draft). If latency protection proves to be unnecessary (as I believe it will, mainly because incentives are aligned), the Internet will have a nice low cost solution for low latency. If the IETF makes it mandatory to implement from the start, the market will never be able to decide.

I understand that many operators are risk-averse (I have worked in and among them all my career). So after Greg had hired me to work on Low Latency DOCSIS and to design its QProt, Greg and I proposed that QProt should be mandatory to implement, possible to disable, but on by default. And that's what was agreed for *DOCSIS*. That's the right level of industry forum to decide whether a security mechanism will be mandatory to implement. It's focused on a particular deployment scenario. ISPs can make latency protection mandatory in their invitations to tender. Other bodies, like the Broadband forum can too, for their particular deployment scenarios.

Here we're doing what the IETF does well - producing component technologies. If the IETF does NOT mandate latency protection, it does NOT mean it will NOT be mandated - but only where it's appropriate by the appropriate bodies. The IETF is not the appropriate body.

_____________________
Finally, if what you really mean is that ECN and priority queuing can be exploited to attack *bandwidth* more effectively than with a drop tail FIFO, then I (and co-authors) would be very willing to make the current 'SHOULD's in the two L4S docs below into 'MUST's.

1) CURRENT from https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-5.1

   for all AQM methods in [RFC7567<https://tools.ietf.org/html/rfc7567>] (Section 4.2.1<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-4.2.1>), which follows the

   similar advice in RFC 3168<https://tools.ietf.org/html/rfc3168> (Section 7<https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-11#section-7>).
PROPOSED:
    s/SHOULD/MUST/

2) CURRENT from https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-12#section-2.5.1.1

Cheers

Bob

You will recall that I and others have argued against QProt being mandatory to implement using arguments about incentives. That is still the main argument, which I can summarize if necessary, but that's not the purpose of this email.

Here. I want to add another argument that is about modularity. In the latest revision of the l4s architecture you will find seven examples listed of how queue protection could be implemented (eight if you count the null case of no protection):
https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-07#section-8.2
Only two have the queue protection integrated with the AQM. Five use distributed arrangements, with characterization of the traffic congestion located remote from the bottleneck queues that are being protected.

For a distributed solution, when a developer implements an L4S AQM in one box, it doesn't even make sense for the IETF to mandate that she must implement queue protection with it. In a distributed approach, queue protection would be an independent module running on a different box.

The only way that would make sense would be if the IETF was writing a normative standard for a complete traffic control system. Then we would be telling operators what to do, not implementers. System standards are usually the territory of the ITU, or the broadband forum, etc. The IETF is usually expected to specify component parts - protocols, algorithms - "Do one thing and do it well".

Regards

Bob

--