Re: [Congress] CONGRESS is about ready to go

[Bob Briscoe <[e-mail]>]

Matt,

On 23/02/2023 21:41, Matt Mathis wrote:
>
>>       *  Upper layer or application algorithms that implicitly or
>>         explicitly defeat transport layer algorithms intended to
>>         protect the network.  An example would be an application that
>>         aborts and restarts transport connections on a fixed interval
>>         timer, implicitly defeating the transport layer's exponential
>>         RTO backoff.
>>
>
>     [BB] Were you prompted to include this by some current
>     implementation attempting this?
>
> This class of bugs is pervasive.  For example they are likely to be 
> present in any application that does fixed timer based requests (or 
> retries), without regards to the completion or error statuses of prior 
> requests.  A few cases can be quite harmful, such as a streaming video 
> player that requests new chunks while prior chunks are still in flight 
> or stalled.
>
> Most of the time these bugs don't cause problems, but buggy code 
> deployed at scale can be very disruptive.  All examples that I can 
> think of stem from inappropriate actions on errors, where the 
> application responds to errors either by increasing the presented load 
> or wasting capacity.   For example, if git-clone fails due to a 
> network error, you have to rerun the entire operation, wasting the 
> data already delivered.
>
> The point being that CC principles really need to be applied to the 
> entire stack, not just the transport layer.
>
>     I don't think it belongs in a list of things the WG is chartered
>     to work on though (a charter isn't normally a place where you
>     would find a list of things to /not/ do). I don't think it would
>     even need to be in the ICCRG charter - we don't need any (more)
>     research to prove that this would cause congestion collapse. It is
>     surely just sthg that the proposed RFC5330bis would say is highly
>     dangerous, explain why, and say "thou SHALT NOT".
>
>
> I have met too many application designers who think that transport 
> (TCP) is fully capable of protecting the network from poorly behaving 
> applications.  We need some tools to counteract this mindset.

I don't see how a tool can make app developers write good code. Or do 
you have some idea how to do this already? Perhaps you thinking of 
library functions for error handling and retrying?

(Nonetheless, how does production of a tool follow from a bullet in an 
IETF charter?)

Cheers


Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/