Re: [Congress] CONGRESS is about ready to go

[Martin Duke <[e-mail]>]

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