Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <42925662-2277-92b1-2559-5d7be1a6cabb@bobbriscoe.net>
Date: Wed, 25 Mar 2020 09:48:50 +0100
Cc: tsvwg IETF list <tsvwg@ietf.org>,
 Steven Blake <slblake@petri-meat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FEEBD05-DEF1-4874-8A1D-D1A86716E5DF@gmx.de>
References: <7409b3a3-ba14-eb6d-154b-97c9d2da707b@bobbriscoe.net>
 <451679EC-B6F7-4176-B497-8189D238AF03@gmx.de>
 <dac8179d-1c39-b308-2c0a-4a6d0b43ddd6@bobbriscoe.net>
 <B3163D46-F211-4AF8-8A14-AF9AB26ADA33@gmx.de>
 <b0fdf995-964f-33cc-a7ea-3ecba803a672@bobbriscoe.net>
 <C3C0870B-1E4B-4D9C-9B77-7128CAEE938E@gmx.de>
 <42925662-2277-92b1-2559-5d7be1a6cabb@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/h8fj4NhNNljohvV-OwIPoJbuVnQ>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at
 tsvwg interim
Precedence: list

Hi Bob,

Summary: more detailed discussion about semantics and disconnects, safe =
to ignore.

> On Mar 16, 2020, at 11:32, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>=20
> Sebastian,
>=20
> There are two a very important misconceptions in this email that other =
people might be labouring under, so sorry for dredging up this week-old =
thread... inline...
>=20
> On 08/03/2020 19:52, Sebastian Moeller wrote:
>> Hi Bob,
>>=20
>> more below in-line.
>>=20
>>> On Mar 8, 2020, at 19:27, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>>=20
>>> Seabstian,
>>>=20
>>> On 08/03/2020 15:34, Sebastian Moeller wrote:
>>>> Hi Bob,
>>>>=20
>>>> More below.
>>>>=20
>>>> On March 8, 2020 3:23:39 PM GMT+01:00, Bob Briscoe =
<ietf@bobbriscoe.net> wrote:
>>>>> Sebastian,
>>>>>=20
>>>>> On 07/03/2020 19:16, Sebastian Moeller wrote:
>>>>>=20
>>> especially not for applications that might not be possible any other =
way (both low latency and capacity-seeking high bandwidth has =
traditionally been considered impossible).
>> 	[SM] The bigger point is IMHO, is greedy and low-latency =
actually a desirable combination of features?
>=20
> [BB] Not to have grocked this basic requirement is a serious =
disconnect.

	[SM] That is a tad impolite (given your own sensibilities about =
tone), no? Not accepting your premises is not the same as not =
understanding them.

>=20
> Short answer:
> Application-limited does not preclude needing to be capacity-seeking.

	[SM] "capacity-seeking high bandwidth" I was mostly referring to =
the high bandwidth part, but I did not explicitly mention that, sorry if =
that caused confusion.


> "Application-limited" is decided when the application is written, =
whereas "capacity-seeking" (a.k.a. "greedy") copes with potential =
conditions encountered at run-time. So when a flow needs to be =
capacity-seeking, you don't want the onset of queuing to ruin the low =
latency.

	[SM] You are basically trying to sell me on the idea of  =
1/p-type congestion signaling, you can stop, that part I agree with (and =
both components, lower amplitude signaling and higher temporal =
fidelityas compared to rfc3168). Where we disagree is whether L4S is a =
sensible design to deploy such a congestion signaling into the wider =
internet.

>=20
> Longer answer:
> Presumably you're not disagreeing that being able to have high =
throughput at the same time as very low latency would enable many new =
applications (natural video-based interaction, video-based remote =
control, cloud-based AR/VR, online gaming, remote desktop, etc).

	[SM] I am realist enough to understand that no low latency =
application will work robustly and reliably over the wider internet. But =
I also realize that you are arguing here for a "build it and they will =
come" approach, as you only have vage examples of use-cases that require =
low-latency-high-bandwidth, "would enable many new applications" is =
rather unspecific...

>=20
> Even if the throughput of a video flow is usually application-limited, =
the higher the throughput, the more likely it will sometimes encounter =
scenarios where it is limited by available capacity. For instance,
> a) when a path with a lower capacity bottleneck is used (e.g. I =
communicate with someone who has a lower capacity access link, or I move =
to a lower capacity access), or
> b) because enough other traffic has arrived at the existing =
bottleneck.
>=20
> Then you want the congestion control to become capacity-seeking (not =
unresponsive), without losing the low latency.

	[SM] Well adaptive streaming is an already deployed technique to =
deal with variable bandwidth paths, that works reasonably well, =
especially for pre-canned video where the real-time tolerance of users =
is relatively high... You really need an application where the =
end-user's feedback ends up in a tight control loop for the generation =
of the video before ultra-low queueing delay becomes essential. The =
roll-out of google stadia and nvidia gforce now with existing internet =
technology indicates that even without L4S the currently deployed tech =
allows sufficiently tight "real-time" control loops for interactive =
"video streaming". I am not saying that things can not be improved and =
that some of L4S components might not be great solutions, but I question =
the premise that L4S will allow anything qualitatively novel. Which IMHO =
is a big point when assessing L4S's side-effects.


>=20
>=20
> Every time L4S is presented or written about, the same high level =
requirement of high throughput and low latency is repeated.

	[SM] Well, repetition of a statement does not change its truth =
value, if at all it tells us about the persistence of the person =
repeating it.

> What did you think the whole L4S activity was about?

	[SM] This is a direct question I am not really sure you are =
interested in my answer, but here you go. As far as I see it, you are =
building a high priority high bandwidth lane onto customer access links =
that then can be monetized by ISPs by selling this high priority access =
to interested parties (on the content generating or consuming side). =
IMHO that is not a bad thing in itself, under the condition that it is =
fully opt-in and the end-user can decide whether they want that or not. =
A lot of users might be willing to spend money to improve their gaming =
quality (but that assumes that L4S will actually work well enough over =
arbitrarily long path between end-users and game-servers).

>=20
> [I've snipped the next part of the conversation, because it was =
opinion-based and going nowhere.]

	[SM] ??? Most of our discussion is opinion-based including most =
of your arguments and I have repeated asked for hard data only to be =
told data is either irrelevant or that I should go measure myself if I =
want to see data.

>=20
>> 	[SM] But here is the rub, the L4S architecture makes in unduly =
hard to separate low-latency queueing from 1/p-type congestion control, =
as I fully agree these are ORTHOGONAL to each other, so artificially =
coupling them, e.g. by making ECT(1) both denote a 1/--typre response to =
CE AND requestimg admission to the LL-queue is exactly the wrong thing =
to do. Glad that you agree.
>=20
> [BB] Another rudimentary disconnect here...
>=20
> Queuing delay is not caused by the queue, it's caused by the =
congestion-controllers that induce the queue.

	[SM] Semantics, semantics semantics. Not terribly interested in =
that discussion. IMHO it is the queue that can, by say dropping =
immediately, shed the excess packets that cause the delay, not the =
end-points that can not really affect data once in flight. Sure it is =
the traffic (initiated by endpoints) that shows up in intermediary =
queues, but in the context of an AQM misbehaving (like dualQ is) =
pointing to the end-points is IMHO not helpful.


>=20
> 1/p congestion controllers are what keeps the sawteeth small so that =
the ECN-marking threshold in the queue can be shallow without causing =
underutilization.
>=20
> The CoDel config of 'target' (min queue depth) was recommended to be =
set quite low despite leading to underutilization for higher RTTs.

	[SM] Could you please give a citation where you got that idea =
from? The "underutilization for higher RTTs" is what we called =
RTT-dependence in another thread and where we agreed that it also =
affects TCP Prague, aka 1/p type AQMs/signaling.


> However, if the congestion controllers are not scalable (1/p), even if =
they keep the sawteeth fairly small today, they will grow as link rate =
scales. Then we'll be back in the same hole in a few years time.

	[SM] IMHO the reason why L4S is (still) under consideration for =
standardization is because everybody agrees that 1/p signaling with high =
temporal fidelity is really desirable.


>=20
> Unless we sort this out properly, the problem will always stay that we =
have to remain friendly to original Reno flows still likely to be =
running over the Internet. The L4S queue is a transition mechanism that
> a) creates a clean-slate isolated from that slow-death problem.

	[SM] That green-field assumption is IMHO wish-ful thinking, =
there is no clean slate you need to coexist peacefully with the =
eExxisting internet; but that mindset effortlessly explains why you =
accept all the side-effects of the L4S design.

> b) gives immediate benefit today, which encourages adoption (it =
patently already has)

	[SM] Only that the amount of benefit is arguably not =
commensurate to its side-effects.

>=20
> Again, every time L4S is presented or written about, this explanation =
is given up-front.
>=20
> [Again I've snipped some opinion-based conversation, going nowhere...]
>=20
>> 	[SM] That seems all irrelevant to L4S though, and especially why =
gauarding L4S use of ECT(1) with a bespoke DSCP would hinder =
EXPERIMENTAL roll-out of L4S in any meaningful way. As far as I can =
tell, you seem to think about how to deploy L4S as a standards RFC, but =
how about first making sure there is a viable path to it becoming a =
standard first?
>=20
> [BB] If an experiment cannot transition to wider usage, potential =
adopters will notice and not even start.

	[SM] That is not wrong, except that dropping a DSCP requirement =
when transitioning from experimental to standards track status seems =
like a very minor modification, and one that most ISPs are already =
comfortable with. So no I do not buy the argument that requiring a =
concomitant DSCP with ECT(1) to be the straw that breaks the camel's =
back in regard to experimental roll-out. And the fact that all you offer =
are bland general principles makes me believe that you grudgingly agree.=20=


> The limits to the experiment are best put in place by the =
experimenters, not by adding inherent limits to the technology.

	[SM] That indicates, that you consider the actual =
experimentation to be somebody else's problem though; pretty much what I =
feared releasing a half-backed design into the wider internet without =
appropriate safety mechanisms and no plan what the experiment is =
supposed to achieve. I guess I am tainted by what experiment means in my =
line of research.

Sebastian

>=20
>=20
> Bob
>=20
>>=20
>> Best Regards
>> 	Sebastian
>>=20
>>>=20
>>>=20
>>> Bob
>>>=20
>>> {Note 1}: E.g. initially some might only classify ECT1 into the L =
queue for business customers, or as a product for a higher tier of =
customers, or solely for the operator's own services (if allowed in =
their jurisdiction). Other ISPs, like you say, will want to use it as a =
differentiator for their whole regular service (see =
draft-ietf-l4s-arch).
>>>=20
>>> {Note 2}: Of course, certain ISPs might pervert the ECN signal, but =
I think that's less likely, 'cos they can only access to traffic in =
their own network, which inherently hits the e2e congestion control of =
their own customers. If we think that's a possibility, L4S senders could =
cover the least significant bit of the ECN field with integrity =
protection to raise the bar against network interference, by tying it to =
the integrity failure of each whole packet.
>>>=20
>>>=20
>>>> And especially for the scope of the experimental deployment? The =
experiment is required to make sure that L4S can deployed in a safe and =
backward compatible fashion and that it can deliver it's promises under =
real-world conditions.
>>>> The experiment is NOT about how to deploy something in a fashion =
that offers the least part of resistance/the highest adoption rate. As a =
rule of thumb, I would assume the IETF be interested in the technical =
aspects and not the marketing side....
>>>>=20
>>>> Regards
>>>>         Sebastian
>>>>=20
>>>>=20
>>>>>=20
>>>>> Bob
>>> --=20
>>> ________________________________________________________________
>>> Bob Briscoe                               http://bobbriscoe.net/
>=20
> --=20
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/