Re: Deadlocking in the transport

Mirja Kühlewind <> Thu, 18 January 2018 09:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1FFB12EB21 for <>; Thu, 18 Jan 2018 01:29:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rGGKvA9FDM7d for <>; Thu, 18 Jan 2018 01:29:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B81DE12EB19 for <>; Thu, 18 Jan 2018 01:29:17 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3zMdvJ0KkgzMnwY; Thu, 18 Jan 2018 10:29:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ir6TjVZi3-Ql; Thu, 18 Jan 2018 10:29:15 +0100 (CET)
X-MtScore: NO score=0
Received: from [] ( []) by (Postfix) with ESMTPSA; Thu, 18 Jan 2018 10:29:14 +0100 (CET)
Subject: Re: Deadlocking in the transport
To: Martin Thomson <>, Ian Swett <>
Cc: Jana Iyengar <>, QUIC WG <>, Roberto Peon <>
References: <> <20180110194716.GA30573@ubuntu-dmitri> <> <20180110200646.GB30573@ubuntu-dmitri> <> <20180110202357.GC30573@ubuntu-dmitri> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <>
Message-ID: <>
Date: Thu, 18 Jan 2018 10:29:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/mixed; boundary="------------9698D8E6ECEB2E76900D3EB9"
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Jan 2018 09:29:20 -0000

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...


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 <> wrote:
>> +1 million
>> On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar <> 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.