Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jonathan Morton <chromatix99@gmail.com>
In-Reply-To: <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net>
Date: Sat, 16 Nov 2019 07:28:50 +0800
Cc: rgrimes@freebsd.org, tcpm@ietf.org, draft-grimes-tcpm-tcpsce@ietf.org,
 tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FB1D6B3-7995-473B-8055-C222BE19427A@gmail.com>
References: <201911042204.xA4M4Zob002799@gndrsh.dnsmgr.net>
 <8001dae3-0873-5ba1-d603-a9d8661b41ed@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/rLtMscCZgFUI6keOfUzy6NJEMNY>
Subject: Re: [tsvwg] [tcpm] Tech review of draft-grimes-tcpm-tcpsce-01.txt
Precedence: list

> On 16 Nov, 2019, at 1:59 am, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>=20
> Why go through all the years of pain of altering the TCP wire protocol =
for an accurate feedback scheme that isn't accurate?

Without delving into the rest of the detail right now, I'd like to =
address this point immediately.

Congestion control is, ultimately, a system with a control loop under =
negative feedback.  When designing such a control loop, one is generally =
concerned with whether it has sufficient gain to converge on the =
appropriate setpoint, and is acceptably stable.  The nature of the =
feedback path feeds into that analysis, but as long as the result meets =
acceptability criteria, a simpler control system is often preferable.  =
One fundamental property of a negative-feedback system, though, is that =
the system returns towards the setpoint after a disturbance, even that =
disturbance occurred *in* the feedback path.

Consequently, SCE can tolerate as much as 100% relative error in the SCE =
feedback path.  The case of being 100% low - no ESCE feedback received =
at all - corresponds to falling back to RFC-3168 compliant behaviour, =
ie. the MD response to CE acts as a ceiling on the positive excursion of =
the control output (cwnd).  The case of being 100% high - twice as much =
ESCE feedback received as SCE marks were applied on the forward path - =
will cause a low excursion which will drain the affected queue, after =
which SCE marking will stop, and the system will then recover.

Consequently we made the design decision that *reliable* accurate =
feedback was not necessary, nor was the associated complexity desirable. =
 We also observed that a single additional bit per received segment was =
always adequate to convey *accurate* feedback, and that usually fewer =
bits were needed, which fits well with using one spare bit per Delayed =
ACK packet - which is what we do here.  Several such bits are available =
in the TCP header for such uses, and we decided to recommend the use of =
one which had recently been freed up and whose previous use was closely =
related.

Without yet having examined your other arguments in detail, I suspect =
you are misunderstanding how some of our proposed feedback methods work =
in practice, perhaps stemming from the above fallacy.  Understand that =
we have actually implemented each of these methods in running code, and =
can demonstrate their operation at the Hackathon.

See you there.

 - Jonathan Morton