Re: [Congress] CONGRESS is about ready to go

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 <mattmathis@measurementlab.net>
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 <
> zaheduzzaman.sarker@ericsson.com> 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 <mattmathis@measurementlab.net>
>> 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 <
>> zaheduzzaman.sarker@ericsson.com> 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 <huitema@huitema.net>
>>> 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
>>> > Congress@ietf.org
>>> > 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.