Re: [tsvwg] Fwd: New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

[Pete Heist <[e-mail]>]

Hi Bob, comment below...

On Tue, 2021-03-09 at 00:25 +0000, Bob Briscoe wrote:
> Pete,
> 
> Thanks for the updated draft a fortnight ago, with the extra columns
> I 
> asked for.
> 
> I've been excluding the rows with obvious pathologies.
> 
> Of the 90 IPs in your TCP results, 74 have at least one obvious 
> pathology, leaving only 16 clean.
> And actually, there was a pathology suggested in your slides today
> that 
> isn't in the above,
>      If I check for that too, 83 IPs have at least one pathology, 
> leaving only 7 clean.
> 
> Any idea what is going on?
> 
> 
> 
> ==Details==
> 
> In the TCP results, unlike with QUIC, the reverse feedback is
> visible. 
> So I can check for more pathologies.
> 
> I checked for this obvious pathology, that wasn't directly mentioned
> in 
> the slides today:
> experienced (ECE) feedback in the other.
> * Or conversely, echo congestion experienced (ECE) feedback in one 
> direction but no congestion experienced (CE) in the other.

I believe I've got your question right, but let's see. From the vantage
point of the gateway, we don't always get to see CE in one direction
and ECE in the other. In fact, it seems a lot of the time we don't.

Say downstream traffic passes through the gateway as ECT(0) and gets
marked in an AQM later with CE, before arriving at the user endpoint.
We haven't seen that CE at the gateway, but we still see the ECEs in
the opposite direction. The same can happen upstream, if CE is marked
somewhere after packets leave the gateway. That's why we don't require
the presence of CE marks to mark an entry "possible AQM", but we use
them if they're present.

Pete

> and 38 from the LAN
> (taking the direction as that of the data)
> Only 16 IPs, don't have this pathology in either direction.
> 
> I would have thought you guys would have picked up these when
> checking 
> for the ECE/CE >= 2
> (and/or zeros).
> 
> If I include the pathology you mention where ECE/CE < 2
> In all, of the 90 IPs in the TCP results, after I exclude any IP with
> a 
> pathology, I only have 7 IPs left.
> 
> 
> 
> Bob
> 
> PS. I agree it's v strange for an ISP to share capacity between its 
> members by how many flows they are using.
> 
> On 08/03/2021 22:19, Pete Heist wrote:
> > I'm following up in this thread to one question that's come up- why
> > is
> > an ISP deploying fq_codel in its backhaul?
> > 
> > In short, this ISP encourages research and experiments by its
> > members,
> > and this was a way to both see how much congestion exists, and
> > attempt
> > to manage it with AQM when needed. Experiments with fq_codel were
> > started a couple of years ago, and I helped add support for it to
> > their
> > custom router interface early last year. However, it's only
> > actually
> > been enabled on a couple of routers, because:
> > - it takes a while to update routers in this environment
> > - some of the routers run kernels prior to fq_codel support
> > - congestion doesn't usually last long enough to give it much
> > urgency,
> > and sometimes it's fixed by just adding capacity
> > 
> > IMO, fq_codel isn't ideal in this situation. When there actually is
> > congestion to manage, flow-fairness means that one user can
> > dominate
> > the queue with many flows, which is exactly one of the problems
> > we'd
> > like to avoid. Host fairness could improve on this, or better yet,
> > member fairness using the member database, as members can have more
> > than one IP/MAC. But, fq_codel is what's available now, and
> > generally
> > usable enough in this case to get started with AQM.
> > 
> > On Mon, 2021-03-08 at 11:09 +0100, Pete Heist wrote:
> > > -------- Forwarded Message --------
> > > Subject: New Version Notification for draft-heist-tsvwg-ecn-
> > > deployment-
> > > observations-02.txt
> > > Date: Mon, 08 Mar 2021 01:57:07 -0800
> > > 
> > > > A new version of I-D, draft-heist-tsvwg-ecn-deployment-
> > > > observations-
> > > > 02.txt
> > > > has been successfully submitted by Peter G. Heist and posted to
> > > > the
> > > > IETF repository.
> > > > 
> > > > Name:           draft-heist-tsvwg-ecn-deployment-observations
> > > > Revision:       02
> > > > Title:          Explicit Congestion Notification (ECN)
> > > > Deployment
> > > > Observations
> > > > Document date:  2021-03-08
> > > > Group:          Individual Submission
> > > > Pages:          30
> > > > URL:
> > > > https://www.ietf.org/archive/id/draft-heist-tsvwg-ecn-deployment-observations-02.txt
> > > > Status:
> > > > https://datatracker.ietf.org/doc/draft-heist-tsvwg-ecn-deployment-observations/
> > > > Html:
> > > > https://www.ietf.org/archive/id/draft-heist-tsvwg-ecn-deployment-observations-02.html
> > > > Htmlized:
> > > > https://tools.ietf.org/html/draft-heist-tsvwg-ecn-deployment-observations-02
> > > > Diff:
> > > > https://www.ietf.org/rfcdiff?url2=draft-heist-tsvwg-ecn-deployment-observations-02
> > > > 
> > > > Abstract:
> > > >     This note presents data gathered at an Internet Service
> > > > Provider's
> > > >     gateway on the observed deployment and usage of ECN. 
> > > > Relevant
> > > > IP
> > > >     counter and flow tracking data was collected and analyzed
> > > > for
> > > > TCP
> > > > and other protocols.
> > > A few updates in this version:
> > > 
> > > * Improved statistics for the separated "known" and "unknown"
> > > AQMs.
> > > 
> > > * Clarified the detection method for possible AQMs.
> > > 
> > > * Added possibility of QUIC-ECN traffic in non-TCP data.
> > > 
> > > Pete
> > > 
> > > 
> > 
>