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

[Martin Duke <[e-mail]>]

Thanks Pete!

I wonder if the non-TCP ECN traffic is QUIC? I don't think the main
implementations are doing it, but there are a few ECN-capable
implementations in production.

On Sun, Feb 21, 2021 at 4:34 PM Bob Briscoe <[e-mail]> wrote:

> Pete,
>
> Thx for doing this. I'm afraid I won't be able to now analyse the data
> you've provided for a couple of days, 'cos I have to focus on a couple
> of deadlines tomorrow, one being the IETF draft deadline.
>
> But whatever, thx v much.
>
> Bob
>
> On 20/02/2021 13:39, Pete Heist wrote:
> > New revision posted and some comments below...
> >
> > On Sat, 2021-02-20 at 09:36 +0000, Bob Briscoe wrote:
> >> Pete,
> >>
> >> If you plan to post a revision, in the TCP table (Sec.5.3) would you
> >> pls
> >> consider including the counts of ECT packets, as in the non-TCP table
> >> in
> >> Sec.5.3? Otherwise we don't know what percentage of the total ECN
> >> traffic each count represent.
> > That's a useful addition. An ECT(0) column is now added, and the TCP
> > table's column order is now similar to the non-TCP table. ECE for the
> > opposite direction is still next to CE as that seems most readable. I
> > left out ECT(1) for TCP as there's so little of that, and then it gets
> > harder with the line length limit.
> >
> >> I'm trying to separate out the IPs known to be behind the FQ-CoDel
> >> nodes
> >> in the backhaul. I.e. separating known from unknown causes.
> > That's mentioned in Section 3.2.
> >
> >> Separately, a count of total packets, or equivalently a count of
> >> not-ECT, would be v useful too.
> > I didn't capture Not-ECT by IP address, mainly because some testing
> > made me question how at least one ipset lookup per-packet would affect
> > performance on their production gateway. I added that to the
> > Limitations section as it could be useful if available.
> >
> > Pete
> >
> >> If you can do this without losing the ECE counts, even better. Having
> >> CE
> >> and ECE together enables a rough estimate of the average window.{Note
> >> 1}
> >>
> >> Specifically,
> >>       avgWindow = ECE * delAckRatio / CE
> >>
> >> Thank you (again)
> >>
> >>
> >> Bob
> >>
> >> {Note 1} And lots of other assumptions, such as:
> >> - delayed Ack Ratio including stretch ACKs has to be guessed (e.g.
> >> 2???)
> >> - minimal additional ack coalescing in the network
> >> - minimal reordering
> >> - traffic volume dominated by elephants
> >> - the TCP protocol is working as it should
> >> - and so on.
> >>
> >>
> >> On 19/02/2021 13:06, Pete Heist wrote:
> >>> Yes, that was somewhat unexpected to us at first too, but misuse of
> >>> the
> >>> ECN field esp. on non-TCP packets seems to explain it in cases
> >>> where
> >>> there ratios don't look like AQM signaling. The data for TCP is
> >>> overall
> >>> easier to attribute to ECN when you can see feedback via ECE.
> >>>
> >>> I didn't editorialize much on the results, but I'll use this as a
> >>> chance to add what struck me:
> >>>
> >>> * While ECN negotiations were relatively small at around 1.44%,
> >>> they
> >>> were spread across 45% of the IPs, so the proportion of paths using
> >>> it
> >>> seems significant.
> >>>
> >>> * The data seem to show significant 3168 marking AQM deployment,
> >>> when
> >>> 24% of LAN IPs that negotiated ECN saw CE or ECE. The draft
> >>> mentions
> >>> how some of it is from known AQM instances and some not. Congestion
> >>> overall doesn't seem excessive, but that could be quantified
> >>> better.
> >>>
> >>> * A wider survey might help on the non-TCP data.
> >>>
> >>> Anyway thanks for taking a look...
> >>>
> >>> Pete
> >>>
> >>> On Fri, 2021-02-19 at 11:44 +0000, Mirja Kuehlewind wrote:
> >>>> Hi Pete,
> >>>>
> >>>> thanks for putting this together and sharing!
> >>>>
> >>>> I have one question on the data. Maybe I'm not readying this
> >>>> correctly but if I look at the big table at the end, then I see a
> >>>> lot
> >>>> of cases where there are much more CE marks than ECT(0) marks.
> >>>> That's
> >>>> a bit unexpected as usually an AQM should only mark a small
> >>>> portion
> >>>> of the packets. Or do I interpret the data there incorrectly?
> >>>>
> >>>> Mirja
> >>>>
> >>>>
> >>>>
> >>>> On 18.02.21, 17:38, "tsvwg on behalf of Pete Heist"
> >>>> <[e-mail] on behalf of [e-mail]> wrote:
> >>>>
> >>>>
> >>>>       > A new version of I-D, draft-heist-tsvwg-ecn-deployment-
> >>>> observations-00.txt
> >>>>       > has been successfully submitted by Peter G. Heist and
> >>>> posted to
> >>>> the
> >>>>       > IETF repository.
> >>>>       >
> >>>>       > Name:             draft-heist-tsvwg-ecn-deployment-
> >>>> observations
> >>>>       > Revision: 00
> >>>>       > Title:            Explicit Congestion Notification (ECN)
> >>>> Deployment Observations
> >>>>       > Document date:    2021-02-18
> >>>>       > Group:            Individual Submission
> >>>>       > Pages:            27
> >>>>       > URL:
> >>>>
> >>>>
> https://www.ietf.org/archive/id/draft-heist-tsvwg-ecn-deployment-observations-00.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-00.html
> >>>>       > Htmlized:
> >>>>
> >>>>
> https://tools.ietf.org/html/draft-heist-tsvwg-ecn-deployment-observations-00
> >>>>       >
> >>>>       > 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.
> >>>>
> >>>>       This draft adds some data on the current usage of ECN. It
> >>>> was
> >>>> gathered over several weeks at a cooperative ISP with around 660
> >>>> members, and looks at ECN endpoint activity, AQM deployment and
> >>>> ECN
> >>>> usage on non-TCP protocols. While this study is still relatively
> >>>> small, it’s hopefully at least a little more useful than the
> >>>> stateless counter data I posted late last year, which should set
> >>>> the
> >>>> bar suitably low… :)
> >>>>
> >>>>       Pete
> >>>>
> >>>>
> >
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
>