Re: Deadlocking in the transport

"Charles 'Buck' Krasic" <> Thu, 18 January 2018 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDA6912D80E for <>; Thu, 18 Jan 2018 11:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kCUf3otXkxKN for <>; Thu, 18 Jan 2018 11:28:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 512BD12D7FB for <>; Thu, 18 Jan 2018 11:28:30 -0800 (PST)
Received: by with SMTP id d11so26068272iog.5 for <>; Thu, 18 Jan 2018 11:28:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v/kqoQ6UBUloXH8k3trXWoRxm1nZKOFaRyGnGnpcGB4=; b=ZD60/d5yS5NKaj6+g4DaqCH6NRrrPHoztgFkFDtcpuLeGcaQ+qjB/ZvrpSiZo8YpNE IJQCsdGRPvVuDLnZ/l74l2wMGhcj9D8PgrafgNAF88sTx6bhXiMIu0vOb/uRSF3pOQmZ Isa6xXhl2SpjYAm/ntH4rznOLgXKWTjzKj74ZjkNZnr2jx+NFbaGV3QSKMnbWOpbTyiP slYYPZinZ5M/ddbM+buKIAyR+ikfHzu5yezLe18htN1KX9WXqmgboocYCigeUoNdeTla 7ivCUTiInoIEXnQq2Q1tYEfOdpExaJ7YrjmzIkTdBTo+GYJRFaM7gfwH5FoGoElZTYVH uSnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v/kqoQ6UBUloXH8k3trXWoRxm1nZKOFaRyGnGnpcGB4=; b=OLC0hLsq81RN9w3WNVmzb/V5Xvxpzc2LT2he+AeCQ4WXbQyacYsuQHcPVzD0dTrasW LTVI0fTwxr8BWWoMaDTuzE3f33WykKgRCDBl+fBmL7pKPnYcY+w39PbKEYPg+l0120Uq +EL0ufif/YeU7T2tU+ft7w/FTXFT2Q9iy1BYmG/llJs3ndIDsAPEof6TUK4c5EXfLzcx C8jiMHViBJScHcBMHgrCCjQgzY1ui9tixOz+yN+iGb6FptIyHPq44szlCKdIYF4kJW6o x0I6xOEE+tnAMmcxxIYYsDGtbFx6uMHHEUUJEHY2L7NpO5Ne5JlqGSYBzxoxoxTPtWP2 hL6Q==
X-Gm-Message-State: AKwxytdW1h46W0hcknV0cyrFZxm08qtp5NfQ9QnwYD+9iUmJhYCdwvrD K3ZcKaq65dqeoiw9fsBUjGEb3n1461ShVml2FpoF
X-Google-Smtp-Source: ACJfBosJLQ8+O9Th4yWZ/3rW+7Te6Ad22vBA/i5KvkuIMRmFuuMpcXoI9dP/2RPQSeVD68OCJpaQOWJ3gJ9yoq/pxn4=
X-Received: by with SMTP id k141mr46636798ioe.39.1516303709033; Thu, 18 Jan 2018 11:28:29 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 18 Jan 2018 11:28:08 -0800 (PST)
In-Reply-To: <>
References: <> <20180110194716.GA30573@ubuntu-dmitri> <> <20180110200646.GB30573@ubuntu-dmitri> <> <20180110202357.GC30573@ubuntu-dmitri> <> <> <> <> <> <> <> <> <> <> <>
From: "Charles 'Buck' Krasic" <>
Date: Thu, 18 Jan 2018 11:28:08 -0800
Message-ID: <>
Subject: Re: Deadlocking in the transport
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>
Cc: Martin Thomson <>, Ian Swett <>, Jana Iyengar <>, QUIC WG <>, Roberto Peon <>
Content-Type: multipart/alternative; boundary="001a1140fedaf3ba41056311f7a6"
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 19:28:35 -0000

[ speaking for myself only ]

On Thu, Jan 18, 2018 at 1:29 AM, Mirja Kühlewind <> wrote:

> 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.
Depending on ones perspective, the congestion level flow control in QUIC
could be seen as imposing cross-stream dependency.   It is conflict between
those transport dependencies and the application's inter-stream
dependencies that leads to trouble.    Perhaps it is a bit overly
restrictive to define a stream interface that only supports truly
independent application streams (?).

> 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...
Sorry, but this particular example smells of a bogeyman to me (?).   Isn't
partitioning of the transport encryption scheme is pretty unlikely at this
point?   If so, doesn't it follow that using 'transport only proxies'  to
adapt to wireless link characteristics  pretty infeasible, because in
practice such network devices would not have access to transport level
crypto keys?   [ Unlike CDN operated proxies, which have the certs for
their customer origins ].

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

Charles 'Buck' Krasic | Software Engineer | | +1 (408)