Re: [Congress] CONGRESS is about ready to go

[Matt Mathis <[e-mail]>]

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

On Sun, Feb 26, 2023 at 1:30 PM Martin Duke <[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]>
> 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]> 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]> 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]>
>>>> 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]> 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]>
>>>>> 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]
>>>>> > 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.