Re: [EToSat] [Masque] Call for MASQUE use cases

Ben Schwartz <bemasc@google.com> Wed, 04 March 2020 20:58 UTC

Return-Path: <bemasc@google.com>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2590C3A08D8 for <etosat@ietfa.amsl.com>; Wed, 4 Mar 2020 12:58:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 I-Xg2kD7yZBv for <etosat@ietfa.amsl.com>; Wed, 4 Mar 2020 12:58:13 -0800 (PST)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4543A08C3 for <etosat@ietf.org>; Wed, 4 Mar 2020 12:58:12 -0800 (PST)
Received: by mail-wr1-x42f.google.com with SMTP id y17so4223034wrn.6 for <etosat@ietf.org>; Wed, 04 Mar 2020 12:58:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d7jiUaUFQ/jYWBhhhkv0HuT0X+mxsEM6V1NTpsFDH0g=; b=eUot43023GwvzftVfwsn0LwkRsjdGrDkqghnQk+o12OHmJky5bGP783UAW4VvKMkaP ZNg5vyPd0z1Bb4rvD3i8oSSyHXMtdA84rzOHPTxKBY709kVBAucDBra+Qqs16YNr3ZTe c/yQn16iAbTmRAmrJJEF0/4+JRn4QojO8a9Ll9QICQTymv4T9yyzPvxyUDhNT1WgNeJ8 Hm8HafgFsd6cxj8l/DUKx+e+6OLssJ6L6CT92bQPMsOeuwOOOiGEvl9ZPLt6Wfl7vRfR SUkqBGdYejNThxFsPduV0IfiNhJQ6yiBN2UlW2lPbrRLKKCXNvwdzANVkP2nDw9Gdqyh 3tPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d7jiUaUFQ/jYWBhhhkv0HuT0X+mxsEM6V1NTpsFDH0g=; b=ntumjGkUy/7hUXC7MxXDp4KmPXutVZ3FpcumPNeh21oReU/EXVochfX58b3CnuYUzv cyyzKHO9Laa5+6Xcn3gYbiOAzRtlbApTiPk9jTwww/qSf4okNg8E+0WzGkyUev5CMiF3 NNblSueEcjPtwfnm3JtDPIjubZB/Pid1d4Ln5w9XVT9z0kR2VYLjArpNNxNwU+0AX61Z E77QITDzxEmSciiZUCUKA7GivGUXySbFJu1K+QO4mMfSu3l6+2tyoe9SqBca4zQ0a6b4 dNCjvfTeMBWHSLLN0CpyZ52FLxnex/mmjxEbIZv8PkE4foKfbuALIFGhAqd5aYDkn7cf oq7A==
X-Gm-Message-State: ANhLgQ0vdH95ip4jkr1V35Vo8Bt44Y+1HlkDjimwGjoAjDVkqdXLVxTp DMVYmn2M/jhc1/4AvAfc+hcY0CkIFJpu7SaHmRCp0w==
X-Google-Smtp-Source: ADFU+vuVWDV7O3ouwE21GP5c7+6XwU3pLsPY/Wa50hN92/CkUUC8AHAs12b6VBj/1LokII3IJit0N9rhk7WEmnrWSGc=
X-Received: by 2002:adf:ff84:: with SMTP id j4mr5930818wrr.426.1583355491041; Wed, 04 Mar 2020 12:58:11 -0800 (PST)
MIME-Version: 1.0
References: <D46D764C-F682-472A-AFDA-32DDF5CA5F6B@heapingbits.net> <BL0PR11MB33947C669B60314160FB8BA090E40@BL0PR11MB3394.namprd11.prod.outlook.com>
In-Reply-To: <BL0PR11MB33947C669B60314160FB8BA090E40@BL0PR11MB3394.namprd11.prod.outlook.com>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 04 Mar 2020 15:57:59 -0500
Message-ID: <CAHbrMsCtu3u-Tndch6Q0A_GeTkqMQsQ6VNEZ1=+GY9H475Ay7A@mail.gmail.com>
To: "Border, John" <John.Border@hughes.com>
Cc: "masque@ietf.org" <masque@ietf.org>, "etosat@ietf.org" <etosat@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000a1b3ba05a00dad55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/nZYBZanGwRZa4QiGvMJPSM6m7Q4>
Subject: Re: [EToSat] [Masque] Call for MASQUE use cases
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2020 20:58:17 -0000

On Tue, Mar 3, 2020 at 5:43 PM Border, John <John.Border@hughes.com> wrote:

>
>      Here is another potential use case...
>
>     There is a trend towards using satellite links in a multipath
> combination with a terrestrial technology (e.g. LTE).  The two paths
> provide redundancy for each other.  But, the big selling point is using QoS
> classification to send traffic which requires low latency (i.e. truly
> interactive traffic) via the terrestrial path and traffic which requires
> high throughput (so called bulk traffic) through the satellite path.  As I
> understand the Multipath QUIC proposal, the solution requires the end host
> to select the path to use (and is also oriented towards sending the same
> connection via multiple paths).  In the use cases we see, the end hosts are
> not cognizant of the multiple paths.  The edge router classifies traffic
> (perhaps with DSCP help from the end host) and selects the path.  The
> router also knows about path failures and degradations.   With QUIC,
> traffic classification is blocked.  Perhaps we can get end hosts to opt in
> and expose traffic classification via DSCPs.  But, that ha
>  s the potential of being carried farther than necessary.  A proxy could
> be trusted with just enough information to do the classification while
> removing the evidence before forwarding the traffic.
>
>     Does this fit?
>

I think this is a good use case.  A simple deployment setup might say
"everything sent to the proxy goes over satellite", and let the client
decide which path each connection should take by whether it uses the proxy
or not.


>
>
> John
>
>
>
> -----Original Message-----
> From: Masque <masque-bounces@ietf.org> On Behalf Of Christopher Wood
> Sent: Thursday, February 20, 2020 10:13 PM
> To: masque@ietf.org
> Subject: [Masque] Call for MASQUE use cases
>
> **EXTERNAL EMAIL**
>
> The core MASQUE protocol [1] describes a simple negotiation mechanism for
> various applications. However, it omits use cases for these applications.
> MASQUE obfuscation in support of a "hidden VPN" service is one use case
> [2]. Tunneling QUIC is another [3].
>
> Given that MASQUE and the upcoming BoF will be successful insofar as it
> addresses important use cases, I think it'd be useful to discuss these
> application use cases in more detail before Vancouver. To that end, let's
> use this time before the meeting to discuss them!
>
> I'd like to ask interested parties to please surface use cases they know
> of (and care about).
>
> Thanks!
> Chris
>
> [1]
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-schinazi-masque-02__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFMXV8K-fA$
> [2]
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-schinazi-masque-obfuscation-00__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFNUKdnP3g$
> [3]
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-kuehlewind-quic-substrate-02__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFPmGZef8g$
>
> --
> Masque mailing list
> Masque@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/masque__;!!Emaut56SYw!ndHvFl_nkRo6Zz30-n2TeXuQE-xZiA76PJMJYS7TiI0jYzGhoH1idXvNrFPynOxALg$
>
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>