[alto] Recharter discussion thread: ALTO transport

"Y. Richard Yang" <yry@cs.yale.edu> Thu, 23 July 2020 21:14 UTC

MIME-Version: 1.0
From: "Y. Richard Yang" <yry@cs.yale.edu>
Date: Thu, 23 Jul 2020 17:14:09 -0400
Message-ID: <CANUuoLq3PjpS9HTVfo282+NaAu1jOwm4eOFOQHChDmWrqm4jPw@mail.gmail.com>
To: IETF ALTO <alto@ietf.org>, alto-weekly-meeting@googlegroups.com
Content-Type: multipart/alternative; boundary="0000000000003e716c05ab225704"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/YUc7hC2sZ12Cza4R7ORv9I5O2Hs>
Subject: [alto] Recharter discussion thread: ALTO transport
Precedence: list

Dear ALTOers,

As we get close to the discussion, many of us are conducting more regular
discussions on the related topics. Danny, Ingmar, Sebastian, Chunshan have
already started the multidomain thread.

Another topic, which can be extremely exciting, but may also raise
non-trivial issues, is the network-to-application information transport.

There have been multiple extended discussions on this topic during the side
meetings already. This evening (July 23) at 10:00-11:00 PM US ET, we will
continue the Zoom discussions and everyone is welcome:
==== bridge info ====
Join from
- PC, Mac, Linux, iOS or Android: https://yale.zoom.us/j/8423318713
- Or Telephone：203-432-9666 (2-ZOOM if on-campus) or 646 568 7788
  Meeting ID: 842 331 8713
  International numbers available: https://zoom.us/u/adcNQyMDb6

Below is a summary of the most basic thinking so that those who want to
join can get a quick background. Email discussion is welcome as well.

First terms: We consider two types of transport: inband (IB) and outband
(OB). By IB transport, we mean that the network information to the
applications is carried by the data plane packets. A simple example of IB
is ECN, which essentially carries network information in data plane packets
to the end hosts. The proposed INT approaches tend to be B as well. On the
other hand, the base ALTO 7285 is OB, using HTTP/1.x as a transport. The
incremental updates component of ALTO adds much flexibility to the
transport structure, in particular, by adding a meta stream control
protocol, but the transport is still OB.

We see two directions to substantially improve ALTO transport.

Direction 1 (Only OB): One is to still focus on OB, but revise the related
components (e.g., incremental updates) to take advantage of the newer
HTTP/2/3. This issue has been raised during SSE IESG reviews, and we feel
that we have an obligation to finish this thread.

Direction 2 (IB+OB): Some use cases, for example, the MOWIE use case in the
context of cellular networks [1], may benefit from IB transport as well.
Consider a simple initial design: an ALTO client, say an application
server, requests incremental update for some last-hop, base station
information. We extend SSE so that the control uri [2, Section 7] allows
more flexible indication of push channels. In particular, the push channel
might be a layer 3 or layer 4 optional header field, at some sample rate,
on the packets on the path back to the server. Then, the server can then
get lightweight, fast updates.

Some can see this as a quite exciting, unified design, motivated by real
use cases...

Richard

[1]
https://datatracker.ietf.org/doc/draft-huang-alto-mowie-for-network-aware-app/
[2]
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/?include_text=1

[alto] Recharter discussion thread: ALTO transport Y. Richard Yang