Re: [Congress] CONGRESS is about ready to go

[Matt Mathis <[e-mail]>]

OK, let's go with the charter as amended.

I will try to have some pictures of excessive ACK thinning observed in the
wild...

On Tue, Feb 28, 2023 at 8:48 AM Martin Duke <[e-mail]> wrote:

>
>
> On Tue, Feb 28, 2023 at 7:59 AM Rodney W. Grimes <[e-mail]>
> wrote:
>
>> > Hi Matt,
>> >
>> > The original comment was that the charter should include handling of
>> > lower-layer ACK thinning. I believe we now agree that that is a
>> > TCP-specific problem.
>>
>> I did not see that agreement, infact I saw that it was even pointed
>> out that this issue exists for QUIC, which is not TCP-specific.
>>
>> Can you detail exactly what 'lower-layer ACK thinning' is.
>>
>> ACK or feedback, and anything that 'thins' that is a non seperable
>> item from congestion control mechanisms and should be 100% in scope
>> for this working group.  Please show me wrong with a CC that does
>> not require feedback from the receiver to the sender, other than
>> one that relies on the network to provied that feedback.
>>
>
> Lower-layer ack thinning is something below the transport, or somewhere in
> the network, that is dropping pure ACK packets because a subsequent ACK
> will do the job just as well, to save bandwidth, radio power or whatever.
> It cannot be done with QUIC because QUIC is encrypted; if you start
> dropping packets that might be ACKs, you're going to end up messing up flow
> control and who knows what else.
>
> As to whether suggestions about feedback frequency should be in scope, we
> agree per the paragraph  below.
>
>
>>
>> >
>> > Advice to transport protocols (or anything else implementing congestion
>> > control) on minimum feedback is definitely in scope. I don't know that
>> we
>> > need a specific charter bullet for it.
>> >
>> > I'm splitting hairs here but I think the current proposal will allow ADs
>> > and chairs to Do the Right Thing.
>>
>> Ok.
>>
>> > I'm going to land my PR as-is and proceed unless anyone can't live with
>> it.
>> >
>> > On Tue, Feb 28, 2023 at 1:59?AM Michael Welzl <[e-mail]>
>> wrote:
>> >
>> > >
>> > >
>> > > On 28 Feb 2023, at 09:11, Bob Briscoe <
>> > > ietf=[e-mail]> wrote:
>> > >
>> > > +1 on all 4 paras of Christian's email.
>> > >
>> > > To address the Diminishing Feedback problem when trying to get up to
>> > > speed, you need /less/ ACK thinning. {Note 1}
>> > > However, once up to speed, /more/ ACK thinning is needed in cases
>> where
>> > > the reverse path is the bottleneck.
>> > >
>> > >
>> > > Oh, that?s very true - and being dynamic in this sense seems to me to
>> be
>> > > the right way to do things.  At high rates, an ACK for every other
>> packet
>> > > can just be excessive, whereas at low rates, it can be too little.
>> > >
>> > > A dynamic ACK approach that breaks the linear tie between the sender?s
>> > > rate and the ACK frequency has been tried in this paper:
>> > > https://cs.stanford.edu/~keithw/tack-sigcomm2020.pdf
>> > > The WiFi case is interesting because, with downloads, it?s mostly the
>> ACKs
>> > > that collide.
>> > >
>> > >
>> > > So the Diminishing Feedback problem and the ACK thinning problem are
>> not
>> > > the same problem.
>> > >
>> > >
>> > > Yes.
>> > >
>> > > Cheers,
>> > > Michael
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Bob
>> > >
>> > > {Note 1}:
>> > > * A Linux TCP receiver includes a heuristic to disable delayed ACK
>> every 2
>> > > packets (quick-ACK) until it detects the end of slow-start.
>> > > * To improve on this, we were sending packets with variable
>> inter-packet
>> > > intervals to detect the onset of queuing delay without growing a
>> persistent
>> > > queue.
>> > > * This confused the Linux receiver's heuristic. But we got much better
>> > > results in tests where we manually disabled delayed ACK every 2
>> packets on
>> > > the receiver.
>> > > * That experience told me that a receiver heuristic that assumes the
>> > > sender is using slow-start has ossified the slow-start algorithm into
>> Linux
>> > > TCP.
>> > > * This motivated me to push for a protocol option so the sender can
>> ask
>> > > the receiver to alter its ACK rate - in the tcpm and quic WGs - which
>> > > Christian points to.
>> > >
>> > > On 28/02/2023 04:29, Christian Huitema wrote:
>> > >
>> > > Matt,
>> > >
>> > > It is not obvious to me that the "diminishing Feedback" problem
>> studied by
>> > > Welzl & al. is related to ACK thinning. Succinctly, they are arguing
>> that a
>> > > majority of flows are too short lived to be able to measure network
>> > > bandwidth using end to end mechanism, that this leads to under-using
>> the
>> > > network capacity, that the problem is not amenable to end to end
>> solutions,
>> > > and that any solution will have to involve signalling by the network
>> to the
>> > > transport. I don't see any direct relation between that line of
>> reasoning
>> > > and a discussion of whether we should send one ACK per RTT, or 4, or
>> one
>> > > ACK for 2 packets.
>> > >
>> > > The discussion of ACK thinning is well advanced in the QUIC WG, see:
>> > > https://www.ietf.org/archive/id/draft-ietf-quic-ack-frequency-02.html
>> .
>> > > (The authors have left the draft expire, but this is very much an
>> active
>> > > discussion.) The draft is already implemented and deployed in
>> multiple QUIC
>> > > stacks -- typically aiming for 4 ACKs per RTT, but the actual draft
>> does
>> > > not say that.
>> > >
>> > > We may discuss whether such mechanisms should be developed in
>> Congress, or
>> > > whether they belong in the respective transport groups. They impact
>> > > multiple mechanisms -- the QUIC draft mentions congestion control,
>> burst
>> > > mitigation, lost detection and connection migration. Congress could
>> > > certainly provide guidelines on the impact of delayed ACKs (or ACK
>> > > thinning) on congestion control, and probably also for burst control.
>> But
>> > > issues like loss detection or connection migration are probably better
>> > > dealt with in the specific transport group.
>> > >
>> > > I think we need some reasonable boundaries between Congress and
>> transport
>> > > specific groups like TCPM or QUIC.
>> > >
>> > > -- Christian Huitema
>> > >
>> > > On 2/27/2023 4:59 PM, Matt Mathis wrote:
>> > >
>> > > Yes, technically ACK thinning is a TCP only issue.   However the
>> > > diminishing feedback problem [1] strikes all protocols, and implicitly
>> > > defines the limits of desirable properties such as freedom from
>> starvation
>> > > and any form of fairness.    ACK decimation makes the problem much
>> worse,
>> > > and somebody in the transport area needs to give advice to link
>> designers
>> > > to put limits on ACK thinning.    We can decide that tcpm is the
>> > > right place for such a document, however doing it there will separate
>> the
>> > > discussion about TCP from any broader conversation in congress about
>> the
>> > > general problem of diminishing feedback.
>> > >
>> > > (BTW, although I agree with the problem statement, I don't agree with
>> > > their conclusion)
>> > > [1] Future Internet Congestion Control: The Diminishing Feedback
>> Problem
>> > > Michael Welzl, Peyman Teymoori, Safiqul Islam, David Hutchison, Stein
>> > > Gjessing
>> > > https://arxiv.org/abs/2206.06642 <https://arxiv.org/abs/2206.06642>
>> > >
>> > > On Sun, Feb 26, 2023 at 1:30 PM Martin Duke <[e-mail]
>> <
>> > > mailto:[e-mail] <[e-mail]>>> wrote:
>> > >
>> > >     I'm comfortable with adding these two bullets as being in-scope:
>> > >
>> > >     - Congestion control techniques that address lower-layer
>> alterations
>> > >     to packet timing or ordering.
>> > >
>> > >     - Advice to upper layers on counterproductive behaviors regarding
>> > >     retransmissions and opening of additional connections to the same
>> host.
>> > >
>> > >     As for ACK thinning, this strikes me as a TCP-only problem, and a
>> > >     standalone solution should probably be done in TCPM. That isn't to
>> > >     say that a more comprehensive algorithm couldn't touch on these
>> > >     issues as part of their design, which wouldn't require a separate
>> > >     charter bullet.
>> > >
>> > >     I'm happy to create a PR for this on Monday, when I have a decent
>> > >     text editor and github client. But I'm happy to entertain
>> feedback.
>> > >
>> > >
>> > >
>> > >     On Fri, Feb 24, 2023 at 2:45?PM Matt Mathis
>> > >     <[e-mail]
>> > >     <mailto:[e-mail] <
>> [e-mail]>>>
>> > > wrote:
>> > >
>> > >         I just realized that the charter I have is .txt only. Did I
>> > >         overlook one in kramdown?
>> > >
>> > >         On Fri, Feb 24, 2023 at 11:30 AM Matt Mathis
>> > >         <[e-mail]
>> > >         <mailto:[e-mail]
>> > > <[e-mail]>>> wrote:
>> > >
>> > >             You can't weigh fuzzy preferences in email, because the
>> > >             effort to send a message exceeds the strength of most
>> > >             people's opinion.
>> > >
>> > >             I think the chairs (+ ADs?) just need to make a decision.
>> > >               I have some meetings but I will push two separate PRs
>> laer
>> > >             today.
>> > >
>> > >             On Fri, Feb 24, 2023 at 10:31 AM Zaheduzzaman Sarker
>> > >             <[e-mail]
>> > >             <mailto:[e-mail]
>> > > <[e-mail]>>> wrote:
>> > >
>> > >                 yes, a PR would be good.
>> > >
>> > >                 However, I am not sure we have a conclusive discussion
>> > >                 here that shows what it actually means if we include
>> > >                 those two bullets. I would like to understand that
>> part
>> > >                 better.
>> > >
>> > >                 Let me remind us that right now the charter includes
>> > >                 "operational guidance" in the charter, is that not
>> good
>> > >                 enough?
>> > >
>> > >                 //Zahed
>> > >
>> > >                 On 24 Feb 2023, at 15:49, Matt Mathis
>> > >                 <[e-mail]
>> > > <mailto:[e-mail] <[e-mail]
>> >>>
>> > > wrote:
>> > >
>> > >                 I submitted two bullets that could go directly into
>> > >                 the charter.   Would you like a PR?
>> > >
>> > >                 Although it is reasonable to assume that we have views
>> > >                 up and down the stack, I hoped to make them explicit
>> > >                 for two reasons:
>> > >                 1) We tend to forget to think about some of these
>> > >                 things, and I was hoping to have permanent reminders.
>> > >                 (For example, how much has L4s and TCP Prague been
>> > >                 tested on networks that require batching, such as 600
>> > >                 Mb/s WiFi? I have yet to see any mention of potential
>> > >                 problems (Please let me know if I have missed
>> something).
>> > >                 2) I have seen good ideas ruled "out of scope" because
>> > >                 they were not explicitly in scope, and raised an
>> > >                 awkward truth that the WG didn't want to address.
>> > >
>> > >                 Of my two points, I see more risk down the stack.
>> > >
>> > >                 On Fri, Feb 24, 2023 at 2:55 AM Zaheduzzaman Sarker
>> > >                 <[e-mail]
>> > > <mailto:[e-mail]
>> > > <[e-mail]>>> wrote:
>> > >
>> > >                     First a  question, Have we reached to any
>> > >                     actionable modification to the charter text after
>> > >                     the discussion here?
>> > >
>> > >                     On my personal view, I think the relation to lower
>> > >                     layer and upper layer is always there. We have
>> > >                     applications that produces and consumes data not
>> > >                     really focusing on how a transport protocol would
>> > >                     behave or require rather focused on their own KPIs
>> > >                     or goal. We also have lower layer which try to do
>> > >                     optimization - say ordered delivery, which perhaps
>> > >                     transport protocol can handle themself. For me,
>> > >                     all these are very good topics to discuss and
>> > >                     consider while designing on congestion control
>> > >                     algorithms , but does not need to be in the
>> > >                     charter. I am not sure what else can be done other
>> > >                     than publishing BCP or guidance. The 5033bis
>> > >                     perhaps would also trigger some of these
>> discussions.
>> > >
>> > >                     //Zahed
>> > >
>> > >                     > On 24 Feb 2023, at 04:23, Christian Huitema
>> > >                     <[e-mail] <mailto:[e-mail]
>> > > <[e-mail]>>>
>> > >                     wrote:
>> > >                     >
>> > >                     >
>> > >                     >
>> > >                     > On 2/23/2023 5:14 PM, Matt Mathis wrote:
>> > >                     >> I should have used a different word.  I meant
>> > >                     tools in a BCP standards sense - a citable
>> > >                     document that can be used to scold developers and
>> > >                     corporations  who carelessly deploy large scale
>> > >                     systems that are capable of serving enough data to
>> > >                     DDOS entire countries.   I have heard rumors of at
>> > >                     least 3 such events.
>> > >                     >> It would be better if we told application
>> > >                     designers that they MUST do their part to prevent
>> > >                     congestion collapse and that transport can't fix
>> > >                     some design flaws.
>> > >                     >
>> > >                     > Of course, we have no protocol police. For
>> > >                     example, nobody asked permission from the IETF to
>> > >                     deploy Cubic and make the buffer-bloat issue even
>> > >                     bigger than it was with Reno. Nobody asked for
>> > >                     permission from the IETF before deciding that
>> > >                     running 6 TCP connections in parallel was a fine
>> > >                     way to speed up the loading of web pages.
>> > >                     >
>> > >                     > In theory, we could encourage "enforcement by
>> > >                     network effects". For example, servers could
>> > >                     (perhaps) detect that a peer is requesting way too
>> > >                     many TCP connections in parallel, or stopping and
>> > >                     resuming its QUIC connections too frequently, and
>> > >                     "do something about it". Or, Active Queue Managers
>> > >                     in the network might detect that a particular flow
>> > >                     is causing congestion or long queues at the
>> > >                     bottleneck and "do something about it".
>> > >                     >
>> > >                     > That's something worth thinking about. A BCP
>> > >                     might detail the kind of enforcement that is
>> > >                     considered legit, providing servers admin or AQM
>> > >                     system with some kind of guidelines. And then, the
>> > >                     resulting enforcement might make the Internet
>> > >                     better for everybody. Maybe.
>> > >                     >
>> > >                     > It is also a clear recipe for ossification.
>> > >                     That, and the possibility of getting it wrong,
>> > >                     make writing any such recommendation rather
>> > >                     dangerous. Not that this has ever stopped the
>> > >                     deployment of middle boxes...
>> > >                     >
>> > >                     > -- Christian Huitema
>> > >                     >
>> > >                     > --
>> > >                     > Congress mailing list
>> > >                     > [e-mail] <mailto:[e-mail]
>> > > <[e-mail]>>
>> > >                     > https://www.ietf.org/mailman/listinfo/congress
>> > > <https://www.ietf.org/mailman/listinfo/congress>
>> > >
>> > >
>> > >
>> > >                 --                 Thanks,
>> > >                 --MM--
>> > >                 Evil is defined by mortals who think they know "The
>> > >                 Truth" and use force to apply it to others.
>> > >
>> > >
>> > >
>> > >
>> > >             --             Thanks,
>> > >             --MM--
>> > >             Evil is defined by mortals who think they know "The Truth"
>> > >             and use force to apply it to others.
>> > >
>> > >
>> > >
>> > >         --         Thanks,
>> > >         --MM--
>> > >         Evil is defined by mortals who think they know "The Truth" and
>> > >         use force to apply it to others.
>> > >
>> > >
>> > >
>> > > --
>> > > Thanks,
>> > > --MM--
>> > > Evil is defined by mortals who think they know "The Truth" and use
>> force
>> > > to apply it to others.
>> > >
>> > >
>> > >
>> > > --
>> > > ________________________________________________________________
>> > > Bob Briscoe                               http://bobbriscoe.net/
>> > >
>> > > --
>> > > Congress mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/congress
>> > >
>> > >
>> > >
>>
>> > --
>> > Congress mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/congress
>>
>> --
>> Rod Grimes
>> [e-mail]
>>
>

-- 
Thanks,
--MM--
Evil is defined by mortals who think they know "The Truth" and use force to
apply it to others.