Re: Deadlocking in the transport

[Roberto Peon <[e-mail]>]

I don’t believe that anything we specify in the protocol can solve the issue w.r.t. flow control and intermediaries (in  which the application framework itself might count as an intermediary).
At best we may mitigate the issue by offering a strategy that offers better outcomes than “try, timeout, retry.”

We have a concrete case here in compression. In particular, compression may be point-to-point and entirely within the domain of the protocol implementations, but flow-control is exerted end-to-end and beyond the domain of the protocol.
If compression/compression data is to be flow-controlled, then it is worth thinking about compression-specific mitigations which are better than ‘try, timeout, retry.’

-=R

On 1/17/18, 11:22 PM, "Martin Thomson" <[e-mail]> wrote:

    Yes, what Ian said (and more to what Jana said).  I think that we've
    some proportion of the working group who are operating on one set of
    assumptions and another on a different set of assumptions on this
    subject.  Until now, that didn't bother me much.  After all, that's
    normal for a whole range of issues.
    
    Now there's a concrete problem, so let's dig into this properly.
    
    FWIW, I don't think that we'll resolve this particular issue in
    Melbourne, but I hope that we can at least start that process.  This
    promises to be interesting.
    
    On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett <[e-mail]> wrote:
    > +1 million
    >
    > On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar <[e-mail]> wrote:
    >>
    >> 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.
    >>
    >
    >