[alto] alto transport streams (Re: early reviews)

"Y. Richard Yang" <yry@cs.yale.edu> Thu, 21 July 2022 20:20 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E50C159493 for <alto@ietfa.amsl.com>; Thu, 21 Jul 2022 13:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.412
X-Spam-Level:
X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDquK82OtYlY for <alto@ietfa.amsl.com>; Thu, 21 Jul 2022 13:20:23 -0700 (PDT)
Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40267C159492 for <alto@ietf.org>; Thu, 21 Jul 2022 13:20:23 -0700 (PDT)
Received: by mail-yb1-f175.google.com with SMTP id i14so4724856yba.1 for <alto@ietf.org>; Thu, 21 Jul 2022 13:20:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=FWITjG+pp206evm3ShLZd3DwRIuAilx55zEpupb2xvs=; b=HM8dS1jMA7xmTdHB1AqPYW+EbE1naA7sgnzTIBQIImgNwzbQo+pWmQL0HYkuPrdZZL eukivLsSkXy3FruDmIXyDzz2chgYCJMssvrqFalVwRY0EeIQc1vOivIsWDPT2eN/Az1F m3HkUiFFrWhDUAnYh7jfrt0zCcO2lfaG6Hgwe/1Ty77qwp8UZbjY6D/SjHwtn2vZUZse foxLe4d6J3W5MGpCM6nqDl7MTp6E9jbOYdKjz54zGk6scNMgeO5qKqPvuviO5txevPOF frnZRfw9Dgq7XCx6kGYQXBR/x3pTmmKc0PgOQpTy6Az6x3MlZ7Sf4A6AOK4Z1FSZjiUR 9FNw==
X-Gm-Message-State: AJIora8gfxWPAxg+9DX+sQJT8RTpQp5zjxj6PfqV2oMwGTn9MwZs4Vjk ZxcjN17U8LbHCXuaqqa+jWuSQO0miBWHvczmKR4lI+RVK+M=
X-Google-Smtp-Source: AGRyM1vjwFD8hErVufMnczXIcEIABn8J6HxYcWUUCWZ14HgjF8FQXac5uHTxaEOblDvTBjsJCRHTN98ntnY/8on6ktE=
X-Received: by 2002:a25:b47:0:b0:66e:de09:71fc with SMTP id 68-20020a250b47000000b0066ede0971fcmr254051ybl.399.1658434822326; Thu, 21 Jul 2022 13:20:22 -0700 (PDT)
MIME-Version: 1.0
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Thu, 21 Jul 2022 16:20:11 -0400
Message-ID: <CANUuoLoGYYO3PczKzCyvnrNoqGUa0Zfn8rr-x+Hz2dzqLFBVww@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>, Martin Duke <martin.h.duke@gmail.com>
Cc: IETF ALTO <alto@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000077cde505e456726a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE>
Subject: [alto] alto transport streams (Re: early reviews)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2022 20:20:24 -0000

Hi Mark, Martin, Spencer,

First, thank you so much for the reviews. Sorry for the delay in responding
asap, due to summer and travel.

One common comment we see from all three of you, in different texts, is
essentially on the service model of the current document (
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/): how much
control on the ordering of the messages (Mark/Martin), in-order or not
(Spencer). Hence, after the meeting early morning today, we feel that we
should start a single thread to discuss this issue. We will send a summary
of our responses to each of your individual reviews later.

To help make clear the problem and the current design, let's start by
summarizing the transport model of ALTO/SSE (RFC8895;
https://datatracker.ietf.org/doc/html/rfc8895). We will state the problem
as abstract as possible to see the essence of the problem and the potential
design choices:
- P1: A server offers multiple resources R = {R[1], R[2], R[3], R[4], ...},
where each R[i]i is represnted by a URI;
- P2: A client can request from the server the monitoring of a subset M of
the resources: M \subset R, e.g., M = {R[1], R[2], R[3]}; for example, R[1]
is a network map, R[2] is a cost map using the network map R[1], and R[3]
is an endpoint property map; for simplicity, assume the requested resources
numbered 1 to |M|

- P3: The server can push a sequence of incremental updates to the client
for each resource in M. Denote {U[i,1], U[i,2], ...} as the update sequence
from the server to the client for R[i] in M, where U[i,1] is the first
response for the requested resource R[i], U[i,2] is an incremental update
(patch) on top of U[i,1], U[i,3] is the incremental update on top of
U[i,2], ...

- P3.1: For flexibility, each U[i,j] can choose its own encoding; for
example, U[1,1] is application/alto-networkmap+json, U[1,2]
is application/merge-patch+json; concrete examples please see the current
draft (search "Promised Stream 4" and "Promised Stream 6")

- P4: Consider the dependency among the information resources in P3:
{U[1,1], U[1,2], ...}, {U[2,1], U[2,2], ...}, and {U[3,1], ....}. There are
two types:
- P4.1 We have that U[i,j+1] depends on U[i,j] due to incremental
updates---in the general case, the client needs to have received and
processed U[i,j] to apply U[i,j+1], unless U[i,j+1] is a snapshot (not an
incremental update).
- P4.2 It is possible that U[i', j'] depends on U[i, j], where i' != i: for
example, a cost map depends on the correct version of the network map.

If one goes academic, there is a dependency graph that can describe the
dependencies.

In RFC8895, since it is a single HTTP connection, all of the {U[i,j]} are
*linearized" by the server into a single sequence, and Section 6.7 of
RFC8895 specifies the linearization (serialization) requirements (P4.1 and
P4.2). As we know from concurrency control, linearization is strong and
leaves performance on the table. One of the motivations for the new
document is to take advantage of the more relaxed concurrency model allowed
by HTTP/2 and HTTP/3.

So what are the design points that the design team has considered:

- D1 (linearization): the server pushes all {U[i,j]} in a single stream.
Due to P3.1, there must be an internal structure to separate the U[i,j]
boundaries and different U[i,j] can have different media types, leading
back to RFC8895.

- D2 (max concurrency): Each U[i,j] is sent in an independent (concurrent)
push stream (and hence can use its own media type as it is) and let the
application-layer handles dependency: ALTO has a build-in dependency check
for cross-resource (P4.2) and the sequence numbers of incremental updates
allow application (ALTO client) to figure out the same-resource
dependency (P4.1). The application (ALTO client) buffers all streams to
realize the ordering.

- D3 (max concurrency with server barrier): It is D2 but requires that the
server does not push U[i',j'] if there is a U[i,j], s.t., (1) U[i,j] is
still being sent by the server to the client and (2) U[i',j'] depends on
U[i,j].

The intention of the current document is to reflect D3. Note that for D3,
the ALTO client still needs to handle the dependency correctly, as the
streams may be only buffered at the kernel, and not processed. But the
benefit of D3 over D2 is that it implements essentially some flow control,
to avoid a faster server overwhelming a slower client.

One design point that one may consider is
- D4 (linearization of same resource and concurrency for different
resources): the U[i,j] of the same R[i] is sent in the same stream (and
hence linearized); this can be a reasonable design, but due to P3.1, it is
still not clean; see D1 discussion.

I hope that the preceding has clarified the stream control issue that the
design faced. One can see that the issue can be considered as a generic
issue--what to specify when embedding one concurrency model (P4.1/P4.2)
into a given concurrency structure (HTTP/2 or HTTP/3). We took a quick look
at DoH. It looks that the dependency model of DoH might be simpler: there
is no same-resource (DNS resource type) due to no incremental updates (DNS
update model appears to be the idempotent overwrite model) or
cross-resource dependency. Please correct us if we have missed it.

The current document tried to separate the issue into Sec. 8 (ALTO/H2
Stream Management). One way forward we can see is to (1) only specify that
each U[i,] is mapped to its own stream (to handle P3.1), and (2) not
specify the dependency among U[i,j] (i.e., specify as close as possible to
specify nothing) and let the client figure out the dependency at the
message; we add the requirement language such as "The client MUST check the
dependency ...;"

Sorry for the long email. Any comments?

Thanks,
Richard on behalf of co-authors