Re: Deadlocking in the transport

[Mirja Kühlewind <[e-mail]>]

Hi all,

while I agree that we need to decide which middlebox behavior we want to 
support, I don't really think this is a middlebox issue. If the 
transport you are using is offering you an interface where you can send 
data over independent streams (which was the goal to avoid HOL blocking) 
but the application sends not-independent data over the streams, it is 
an application-layer issue to handle that.

Regarding middlebox behavior, I think we should support transport level 
proxies because especially in mobile networks where the link 
characteristics are quite different from the rest of the network this 
seems still to be the appropriate solution. However, I would wish that 
we could separate transport state from end-to-end payload encryption and 
would not need to terminate both...

Mirja



On 18.01.2018 08:21, Martin Thomson 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.
>>>
>>
>>
>