* Re: [Ecn-sane] simpler solution for ecn + cwnd < 2 than sub-packet windows
2019-07-29 9:22 ` Jonathan Morton
@ 2019-07-30 18:23 ` Dave Taht
0 siblings, 0 replies; 3+ messages in thread
From: Dave Taht @ 2019-07-30 18:23 UTC (permalink / raw)
To: Jonathan Morton; +Cc: ECN-Sane, Daniel Havey
On Mon, Jul 29, 2019 at 2:22 AM Jonathan Morton <chromatix99@gmail.com> wrote:
>
> No, the single easiest solution is to reduce the pacing scale factors. The packets are still full size, but appear less often, potentially less than one per RTT.
Pacing is GREAT, but unlikely to take over the universe all that
rapidly. For anything else with ecn on, a fallback to signalling it's
ok to drop me under extreme congestion seems helpful, and the further
fallbacks that regular tcp has, has have proved sufficient for the
internet.
If we successfully get away from ect1 as an identifier and instead as
a robust set of congestion indicators, senders falling back to 00 is a
possibility.
And it's simple to implement. I note that it might not just be cwnd 2
but at solid levels of SCE or CE marking.
I also like dynamically reducing the MSS to keep the signal strength
up for 1 per RTT for as long as possible.
I've also suggested on multiple occasions that webrtc use ECN for
iframes, but turn it off for deltas.
I'm not saying I don't like subpacket windows!
But not every packet's sacred, and my position paper laid out some
nuances that I need to revise some in light of the enormous
progress made on SCE so far. I rather like the SCE-enabled scavanging
transport idea, as it's kind of similar to the extreme but useful
response to ecn we put into mosh, where we drop the frame rate from
its max of 60 to 1 or 2, in response to CE. Mosh is an example of an
interactive application where going a step further to protect a packet
really helps, but dropping the rate by a large amount, doesn't hurt.
(much)
https://tools.ietf.org/html/rfc8622 lays out two conflicting goals for
a scavenging transport - one that must be low priority and another
that must be capable of being silenced for long periods of time. LE +
SCE enablement and a fallback to being 00 and thus lossy is a possible
way to achieve those goals based on the application's actual intent.
The ledbat++ preso in iccrg is also worth watching, btw, lthough I
fear they haven't actually read
https://perso.telecom-paristech.fr/drossi/paper/rossi14comnet-b.pdf
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
^ permalink raw reply [flat|nested] 3+ messages in thread