Re: [Congress] CONGRESS is about ready to go

[Bob Briscoe <[e-mail]>]

+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.
So the Diminishing Feedback problem and the ACK thinning problem are not 
the same problem.



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