Re: [Congress] CONGRESS is about ready to go

[Martin Duke <[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.

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.

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