Re: [Doh] HTTP/2 and constrained environments

Patrick McManus <pmcmanus@mozilla.com> Wed, 23 May 2018 21:13 UTC

Return-Path: <pmcmanus@mozilla.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F9112D7E6 for <doh@ietfa.amsl.com>; Wed, 23 May 2018 14:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Level:
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thEmtmvbZnR5 for <doh@ietfa.amsl.com>; Wed, 23 May 2018 14:13:25 -0700 (PDT)
Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 176CE129C51 for <doh@ietf.org>; Wed, 23 May 2018 14:13:25 -0700 (PDT)
Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 47F1C3A043 for <doh@ietf.org>; Wed, 23 May 2018 17:13:24 -0400 (EDT)
Received: by mail-ot0-f175.google.com with SMTP id l22-v6so26934417otj.0 for <doh@ietf.org>; Wed, 23 May 2018 14:13:24 -0700 (PDT)
X-Gm-Message-State: ALKqPweyETjH1dkUZebOxa5fz+OHe88oXq8VE9NiRN5eSJYMt2ygVNYb z+Bh3PylNaPGLNAMITh2FCp1lFroIoOMW6sSPtc=
X-Google-Smtp-Source: AB8JxZoMgocgoukCeJ8eX812haXuc14F1TIVFjlG66mtTXnnxCcY+44Sz5htHwOi3EXNA7KUIauOx+sG8BEXkM9Uf6c=
X-Received: by 2002:a9d:4181:: with SMTP id p1-v6mr3078078ote.2.1527110004043; Wed, 23 May 2018 14:13:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:13:23 -0700 (PDT)
In-Reply-To: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl>
References: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 23 May 2018 17:13:23 -0400
X-Gmail-Original-Message-ID: <CAOdDvNpMzArPtoFUp_BtHtmZn4jgFmMT20mDFBEv+j5cF2Og9A@mail.gmail.com>
Message-ID: <CAOdDvNpMzArPtoFUp_BtHtmZn4jgFmMT20mDFBEv+j5cF2Og9A@mail.gmail.com>
To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <mat.jonczyk@o2.pl>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000052f5ed056ce601de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/CtjsdKA1lIsnD-6c2G1PiCkfaFs>
Subject: Re: [Doh] HTTP/2 and constrained environments
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 May 2018 21:13:27 -0000

On Wed, May 23, 2018 at 5:40 AM, Mateusz Jończyk <mat.jonczyk@o2.pl>; wrote:

>
> How difficult it would be to implement HTTP/2 on a home router with 8 MB of
> flash and 32 MB of RAM? Would it at all be possible?


no problem really. HTTP/2 provides a number of mechanisms for either peer
to scale things down (e.g.reducing state in the compression dictionary,
limiting the number of outstanding streams , small flow control windows,
etc ).

searching for nginx and dd-wrt yields lots of howto's
https://www.dd-wrt.com/phpBB2/viewtopic.php?t=312701&sid=dfc6638ad8a57c7d3540d4b3aae828d3
.. nginx has http/2 support.


> Would it be much more
> difficult to implement than HTTP/1.0? All of my routers support only
> HTTP/1.0 in
> the management interface.
>
>
I'm just speculating, but I suspect that has more to do with https and the
challenges of provisioning certs on that kind of device than anything else.


> Would it be beneficial to specify that DNS API clients SHOULD support DNS
> API
> servers that only talk HTTP/1.0 or HTTP/1.1?
>
>
imo we shouldn't be explicitly encouraging older protocols.