Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt

Ted Hardie <ted.ietf@gmail.com> Wed, 03 June 2020 17:41 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3F3A0E06 for <quic@ietfa.amsl.com>; Wed, 3 Jun 2020 10:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 dy48KKGKqGiw for <quic@ietfa.amsl.com>; Wed, 3 Jun 2020 10:41:55 -0700 (PDT)
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 0C9063A0DEF for <quic@ietf.org>; Wed, 3 Jun 2020 10:41:55 -0700 (PDT)
Received: by mail-oi1-x22b.google.com with SMTP id a137so2572262oii.3 for <quic@ietf.org>; Wed, 03 Jun 2020 10:41:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0BWwMobUT8LZegK9KT84+1ZMZGy69gLiQzfF/X2Ljv4=; b=U/i+1MCDrqZ/iU99HbZejWxwa7b/pFx+zjKpGAypuDUuWsmLDJ/4YehMwu8hk1qs18 hhLuC9GiRGLgpoIdaUBMmMHmP4Zxt749GkllXG5tMhw8yw8Xhc76x/SXUQsju/js2/F5 bo2EhJkKqlz0AdC2N+ldEWOZPO7z8SnAOYhSrjCK9++GHBMiQ2GO3TAhN3jmpsFSCex4 lQvqyeUjDsDGyU8ODJDyjVGb3mz760A4svwe+gZpqgoX0DmmQ+qTA8e2dPD9G/dM7ZB4 VHXKEZYhsvaAVVPJGRkSpE0ddT5/ou+YOsU/vLXAeeURoZsimg+98W/6yg6bAM6j2bzp lu0A==
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=0BWwMobUT8LZegK9KT84+1ZMZGy69gLiQzfF/X2Ljv4=; b=eIk8WsuwlXldEaGk/rZK7i36p0eF51MsxEK7HQ6DxW6Cx0nP3+JZl5LITA8Sm45p4f rEzFhM1IbPHdjQTrURZUXZFaEgz4sFhbdMIZ3oprQQpIh3AOX3rhckry2Oqk4yo01Mw6 6I6eWu06jmR78+/WAkHwy6/9q9YK1ybk0TkItIJARRN9U4Jo/rxJTcrT1ekySRyG1zxP 6QNHzeAUNS6sL4OzIxtrlJ8QKmiSYFrAwX+UUi+gZJxT47xOKmLjyFLo6lFu+9FA08GC tvOcP18HkOnXNGbk9S4m1Jm+k6iOA1s6WfM2vZE/g1YsFZ2k07J+dMVPWEFVlCI/n6Qk 236Q==
X-Gm-Message-State: AOAM5338JCcaax4Xp+49pEgYNjVO+sr7gZJVG+dR4hcWo9oETGisT31D HoITpeFw1VL5nGedMUO2A4OIM0EspfAn3ThqBOk=
X-Google-Smtp-Source: ABdhPJz5tFKJ7rw2lsMwOgpF27riIZAYm0DAPAdBTn9clNIXBSXW5RiaYS1NV6cjh5jvKdQMjBQhx2H+LHw6UMcsz/4=
X-Received: by 2002:a54:4795:: with SMTP id o21mr577818oic.74.1591206114376; Wed, 03 Jun 2020 10:41:54 -0700 (PDT)
MIME-Version: 1.0
References: <159084638843.27466.7915766554130545967@ietfa.amsl.com> <CAKKJt-eHQtgjc-zuO7vrGZ1Q2c7=3hetOb0FyqnEmbTDu1Uwuw@mail.gmail.com> <CADdTf+iBRLu20OH-WTEmo=e7WZ8Ce5QVP+_LWO09u6LxjCPe2g@mail.gmail.com> <D2BBDD3C-89F7-43BF-B5C3-1EC5E8C69EBE@ericsson.com> <72be8104-e738-136f-d05c-285fc49533dc@huitema.net> <e74e1342-4f54-679b-00f3-a2e2dc24c9d0@uclouvain.be> <9F66D3B3-DBD6-44CE-80EA-0F46F3D1DB9A@eggert.org>
In-Reply-To: <9F66D3B3-DBD6-44CE-80EA-0F46F3D1DB9A@eggert.org>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 3 Jun 2020 10:41:28 -0700
Message-ID: <CA+9kkMDhaxZunXxyiHdUyCB=90WQthYDCvajGXL3TEyLcmr5vA@mail.gmail.com>
Subject: Re: New Version Notification for draft-bonaventure-quic-atsss-overview-00.txt
To: Lars Eggert <lars@eggert.org>
Cc: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>, Christian Huitema <huitema@huitema.net>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Matt Joras <matt.joras@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000036410b05a7318bee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/vYXM2LSRoU3Cnbd6D0ltiX4hFiY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2020 17:41:57 -0000

Just to amplify this a bit:

On Tue, Jun 2, 2020 at 11:49 PM Lars Eggert <lars@eggert.org> wrote:

>
> Apart from the privacy aspect though, tunneling all traffic through an
> operator proxy that would otherwise not be in the path certainly can have
> performance and management aspects. It's probably going to add delay due to
> route stretch and possibly queueing, and can limit throughput due to
> processing overheads or overload.
>
>
We've been through a lot of this before with various flavors of IP-layer
mobility, and the Home Agent approaches definitely showed all the issues
Lars cites above. There have been attempts to manage that with hierarchies,
fast hand-over rather than tunneling, and even new architectures like LISP
and RINA.   I don't think we want to re-learn all of those lessons from
scratch.  At the very least, we want to start with the understanding that
if ATSSS goes with this design that other tunneling protocols running on
top of it will be very difficult to debug and very hard to keep within
usable latencies.  Another comment mentioned VPNs, which are common and may
become more so.  If you have a user that has to deal with interaction
between the triangle routing to an operator proxy and the triangle routing
to a VPN end point, it will not be quick.

Traffic steering without full knowledge can manage some local
optimization,  and I don't want to denigrate that.  But those local
optimums do not necessarily result in better performance even for single
flows when the endpoints are not clear to steering mechanism.  If that is
priority, sticking with endpoint-based approaches rather than network
steering may be both cheaper and better.

regards,

Ted Hardie