Re: [Congress] CONGRESS is about ready to go

[Zaheduzzaman Sarker <[e-mail]>]

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