Re: Deadlocking in the transport

[Jana Iyengar <[e-mail]>]

We will discuss this at the interim, but one comment, inline.


> In part, it's the ignorance of the intermediary that causes this
> particular problem.  If the intermediary was aware of the protocol
> details then it might be able to recognize and avoid these situations,
> but that seems a little too much to expect of intermediaries. Ruling
> out the entire class of intermediary that operates purely at the
> transport layer is extremely harsh.
>
> What is more likely here is that we describe this situation, explain
> that it is impossible to prevent in the presence of intermediation,
> and explain how to kill the right streams in order to ensure forward
> progress doesn't stall indefinitely.
>

Exactly because intermediaries make things difficult, it's important to be
certain that the intermediary behavior we are discussing is one that
there's a strong argument for supporting. We have spent countless cycles on
designing around uncertain and unknown intermediary behaviors in various
parts of the IETF, and I don't want us to recreate these boogeymen. I think
it's reasonable to rule out classes of middleboxes if we don't have strong
arguments for supporting them.