Re: [Congress] CONGRESS is about ready to go

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.