Re: [Congress] CONGRESS is about ready to go

[Martin Duke <[e-mail]>]

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]
>