Re: [tsvwg] draft-morton-tsvwg-sce: "Permitted ECN codepoint packet transitions"

[Dave Taht <[e-mail]>]

Matt Mathis <[e-mail]> writes:

> Note that the most common case would actually be two bottlenecks
> having completely different statistics: a highly aggregated short
> queue "core" device where approximately all drops are caused by bursts
> in other flows, and an edge bottleneck which is properly marking CE,
> and is in good control of its total load.
>
> In this environment, the best solution is the MIN() of independent
> loss based and ECN based controllers. All other functional combination
> of those signals will cause fairness problems where unrelated core
> losses reduce a flow's share of the well controlled edge bottleneck.

Agree. We can wave hands a little regarding other lossage on the
link(s), in an environment where we see no SCE, CE and some drop,
or in an environment where we are seeing SCE and some drop.


>
> This is one of the observations that flipped me into strongly pro BBR,
> where in principle it is trivial to run multiple independent rate
> controllers, and explicitly pick the min. (Did we mention that BBR
> isn't really done yet? - There is a lot to do...)

I'm pro-BBR as well, and looking forward to the SCE version.

>
> Going back to the original question, I would expect it to be a rare
> corner case for the losses and partial CE marks to come from the same
> bottleneck. (100% CE is a different story). Rare == bad bottleneck
> design, and not worthy of addressing in congestion control.

Regrettably that's not the measured case with pie, at least, in that
the standard (with ecn enabled) it starts dropping at 10% drop probability.

So does fq-pie.

fq-codel does not drop until queue overload, however (due to memory
constraints on consumer routers) shorter queues than desirable are often
deployed, and the bulk dropper has been observed to kick in more often
than it should, so a typical pattern is CEs with a big bulk drop
periodically in the case of overload. There's a partial cure for the non
O(1) cpu overhead of finding the fattest queue now in linux head, and a
complete removal of the non O(1) search in the fq_codel_fast (SCE)
repository that's a tad probalistic. (It's O(1) but relies on finding
the next fattest flow in under 32 packet deliveries)


https://github.com/dtaht/fq_codel_fast/commit/f00ad01168e6d4e18b2d46f3de4f12aaee2bb778


100% CE is also easy to do, given that modern TCPs cap cwnd reduction to
2 or (4 in BBR's case), and all you need to do is have enough ECN
enabled tcp flows going through the bottleneck, to get stuck there at
any X maximum queue length. This should be an easy figure to calculate,
and why sub-packet windows (and/or a MSS reduction) should be
requirements IMHO for a more fully ecn-abled internet, and why I like
RFC3168 sec 6.1.5 and other things like losing syns vs things like ECN++.

I haven't really catagorized dualpie's behaviors, not having the kind of
time for I had 2011-2014. 

as for cake, well, I think cake should revert to drop far sooner than
it does, but that's a pretty lonely opinion thus far.

And in all cases, so far as I know, the combination of CE, (or SCE) +
drop has not been explored well in any transport so it's early to dismiss
the idea entirely, and don't know how rare these corner cases actually
are. Until recently the dctcp implementation in linux had no response to
drop at all (no cwnd reduction!!), and all my data on it predates that change.

>
> Thanks,
> --MM--
> The best way to predict the future is to create it. - Alan Kay
>
> We must not tolerate intolerance;
> however our response must be carefully measured: 
> too strong would be hypocritical and risks spiraling out of control;
> too weak risks being mistaken for tacit approval.
>
> On Thu, Nov 14, 2019 at 10:38 AM Dave Taht <[e-mail]> wrote:
>
>     G Fairhurst <[e-mail]> writes:
>     
>     > I would expect loss to be an important mechanism to deal with
>     overload
>     > of a ECT(0) queue.
>     
>     I expect loss to be an important mechanism to deal with overload
>     of
>     ECT(0) *or* ECT(1).
>     
>     In fact, I'd rather like it if transports considered a mixture of
>     loss
>     and CE, in the SCE case, as an indication of grosser overload with
>     a
>     correspondingly higher rate reduction.
>     
>     This idea is not possible in the L4S case, sadly enough.
>     
>     A bit more below.
>     
>     >
>     > The observation that TCP senders received two signals - loss and
>     > CE-marking was the important step behind RFC8511 to take
>     advantage of
>     > any lower queuing delay that an ECN-capable AQM can provide,
>     while
>     > accepting that bursts and other traffic can exceed the router's
>     > buffering and induce loss. That is somewhat different in L4S
>     which
>     > seeks to keep a much lower queuing delay.
>     >
>     > Gory
>     >
>     >
>     > On 14/11/2019, 22:16, Neal Cardwell wrote:
>     >> On Thu, Nov 14, 2019 at 8:50 AM Rodney W. Grimes
>     >> <[e-mail]> wrote:
>     >>> Hello tsvwg list members,
>     >>>
>     >>> It is our intent to ask for adoption by the TSVWG of
>     draft-morton-tsvwg-sce
>     >>> (https://tools.ietf.org/html/draft-morton-tsvwg-sce-01) during
>     the IETF/106
>     >>> Singapore TSVWG session.
>     >> One random thought: the draft-morton-tsvwg-sce-01 draft
>     mentions:
>     >>
>     >> Permitted ECN codepoint packet transitions by middleboxes are:
>     >>
>     >> Not-ECT -> Not-ECT (or drop)
>     >> ECT -> ECT or SCE or CE
>     >> SCE -> SCE or CE
>     >> CE -> CE
>     >>
>     >> Presumably if the buffer space is full and an ECT-, SCE-, or
>     CE-marked
>     >> packet arrives then that packet can be dropped. So presumably
>     "drop"
>     >> is permitted from those codepoint states as well. (I see the
>     point
>     >> that hopefully this will be rare for ECT/SCE/CE packets, but
>     with
>     >> bursty connection arrivals it seems important to clarify that
>     this is
>     >> possible.)
>     >>
>     >> Since a drop is not really an "ECN codepoint packet
>     transition", and
>     >> can happen to any packet, perhaps "(or drop)" could be omitted
>     from
>     >> the table, for clarity? And as a replacement, the text could
>     mention
>     >> something about "drop" being a possibility for packets marked
>     with any
>     >> of those ECN code points?
>     
>     Good idea.
>     
>     >>
>     >> best,
>     >> neal
>     
>