Re: [Congress] CONGRESS is about ready to go

["Rodney W. Grimes" <[e-mail]>]

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

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