Re: [Congress] CONGRESS is about ready to go

[Matt Mathis <[e-mail]>]

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.

On Thu, Feb 23, 2023 at 1:52 PM Bob Briscoe <[e-mail]> wrote:

> 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 Briscoe                               http://bobbriscoe.net/
>
>

-- 
Thanks,
--MM--
Evil is defined by mortals who think they know "The Truth" and use force to
apply it to others.