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 mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
