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

[Mark Nottingham]

Hi Richard,

I'm just going to give some impressions while reading this, FWIW.

> On 22 Jul 2022, at 6:20 am, Y. Richard Yang  wrote:
> 
> 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;

Good so far; that's pretty much a description of every use of HTTP.

> - 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|

So, in HTTP terms, that would be creating a new resource whose semantic is "I 
am a monitor for  _this_ set of resources". The tricky party here is how to 
realise that in terms of HTTP -- i.e., what does a GET response look like?

One answer would be a feed format like RSS or Atom. Do you support GET in this 
fashion?

> - 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], ...

Here's where I get more concerned. Server Push is unproven, and indeed has been 
shown to be an anti-pattern for its originally intended use case. Folks are 
still interested in it for API use cases (and I'd see this as one of those), 
but it's still very wild west, with no real widespread deployment experience 
that I'm aware of. See especially 
. 

The first question I'd ask here is whether polling a resource (like a feed 
document) is sufficient. That pattern works very well with HTTP, and is 
well-understood -- _much_ more so than Server Push. 

The downside, of course, is latency, but it's not unknown to deploy 
applications with very high polling frequencies (e.g., 1/s). Have you 
considered this approach? Would modifying it to long-polling (where the client 
always keeps a request 'hanging' until the server has an update) help? Keep in 
mind that with HTTP/2 and above, long-polling has very few downsides.

Another option would be to invert the relationship and have what's currently 
the server open connections to the current client and PUT / PATCH updates to 
them. Much more natural HTTP, but of course you need an identity for the client 
and a clear path to it. This approach also has considerable deployment 
experience (commonly known as 'webhooks').

> - 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")

Sure.

> - 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). 

Right. The closest things that we have for managing this sort of thing in HTTP 
today are conditional requests; e.g., If-Match.

> - 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.

That's a purely application-level semantic, correct? I.e., resource A isn't 
useful without resource B, and furthermore representation 1 of resource A 
requires representation 4 of resource B to be interpreted correctly. This is 
similar to issues that people face in caching CSS, JavaScript and the like 
today -- generally it's solved by giving representations with

Re: [alto] HTTP Review (draft-ietf-alto-new-transport)

[Y. Richard Yang]

Hi Mark,

Thank you so much for the feedback. Could you please see
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/
for an attempt to formulate a generic problem.

As soon as we have a discussion on the generic issue, we will update the
document accordingly, for example, to decide to use HTTP/1.x textual
representation---we used HTTP/1.1 textual and then found that the example
need to illustrate details such as the promised stream (see Promised Stream
4 as an example). We will update as soon as we have a discussion on the
generic thread.

Thanks again!
Richard


On Sun, Jul 17, 2022 at 4:05 AM Mark Nottingham  wrote:

> I've taken a look at this document.
>
> My high-level feedback is that in principle it's reasonable use of HTTP,
> but how it talks about HTTP versioning and a few other details isn't
> appropriate. I think that a few small editorial updates could improve
> things, and would be happy to make a pull request if you happen to be using
> a Github-based process.
>
> What raises concerns for me is referring to this as 'ALTO/h2' and similar
> things. If you're designing an application that uses HTTP, you need to
> acknowledge that you can't always control the end-to-end version of the
> protocol used, and while you can optimise for newer versions of the
> protocol, you have to be prepared for downgrading to previous ones.
>
> That means that this isn't really "ALTO/h2", it's a new version of ALTO
> that operates more smoothly under later versions of the protocol.
>
> DoH threaded this particular needle as well; rather than branding it as
> "DNS/h2", they merely said " HTTP/2 [RFC7540] is the minimum RECOMMENDED
> version of HTTP for use with DoH." and then: "Earlier versions of HTTP are
> capable of conveying the semantic requirements of DoH but may result in
> very poor performance."
>
> In this spirit, I'd recommend avoiding using the HTTP/2 textual
> representation for examples; most developers are much more familiar with
> HTTP/1.1 when consuming examples, and HTTP/2 contains details which aren't
> relevant for the purpose of conveying an example (we've settled on this
> approach in the HTTP editorial style, see <
> https://httpwg.org/admin/editors/style-guide>).
>
> Note that I haven't done a full review; these are just the things I saw
> after a quick look.
>
> Cheers,
>
>
>
> > On 11 Jul 2022, at 1:37 pm, Mark Nottingham  wrote:
> >
> > Hi folks,
> >
> > I've been asked to forward this request for early review; does anyone
> want to take a look?
> >
> > Feedback to alto@ietf.org.
> >
> > Cheers,
> >
> >
> >> Begin forwarded message:
> >>
> >> From: 
> >> Subject: HTTP Review (draft-ietf-alto-new-transport)
> >> Date: 6 July 2022 at 12:56:56 am AEST
> >> To: Mark Nottingham 
> >> Cc: Qin Wu , "
> draft-ietf-alto-new-transp...@ietf.org" <
> draft-ietf-alto-new-transp...@ietf.org>
> >>
> >> The ALTO WG is currently working on the specification available at:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/. The
> current version focuses on H2 with the intent to cover at least common
> H2/H3 functionalities.
> >>
> >> The WG is seeking for early reviews so that issues/advice are taken
> into account early in the process.
> >>
> >> We are particularly interested in comments about the handling of H3,
> especially with regards to the guidelines in RFC9250 about HTTP versioning.
> >>
> >> Of course, comments related to other considerations in the draft are
> more than welcome.
> >>
> >> Thank you.
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Fwd: HTTP Review (draft-ietf-alto-new-transport)

[Y. Richard Yang]

Hi Martin,

Sorry that I did not include you in the previous email--auto completion of
email address included a different Martin :-( My apologies.  Please kindly
see this message:
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/

Please see below for more comments.

On Mon, Jul 11, 2022 at 1:28 AM Martin Thomson  wrote:

> ALTO is very much a protocol that is defined in terms of core HTTP
> semantics (see RFC 9205, Section 4.1).  It refers to RFC 7230 (the
> then-current version) rather than RFC 7231 as perhaps it should have, but I
> couldn't see any place where the use of HTTP semantics were
> version-specific.
>
> That makes this document a little surprising.  Most protocols that use
> HTTP benefit from HTTP/2 and HTTP/3 by doing exactly nothing in
> specifications.  You just update software.  This document is a fair bit
> more than nothing.
>
>
Please see the generic discussion in the previous email (
https://mailarchive.ietf.org/arch/msg/alto/CBRGLTekers9PXQ5EE2MtMywMgE/) on
why the current version specified the additional details.

To summarize shortly, the problem is that
(1) a server needs to push a set of resources Ui to a client, there can be
dependencies among the Ui, and how to map each Ui to which stream (in
HTTP/2 or HTTP/3);
(2) each Ui already has a media type, and if multiple Ui are mapped to the
same stream, how to indicate so in the push header and what is the
container media type.

The decision in the current document is:
- Map each Ui to an independent stream (so that no container issue for (2)
-  Instruct the server to respect the dependency to optimize the
transmissions (e.g., by transmitting Ui before Uj, if Uj depends on Ui).


> The new concept of transport queues is added, but I couldn't work out what
> they do.  Maybe there is something related to server push.  I found this
> part to be poorly rationalized and the explanation concentrates on
> mechanisms to the detriment of explaining what the functions provided are
> intended to do.  I can guess based on RFC 8895 what they might do, but I
> think that this document should probably do some more explaining about that.
>
>
Good suggestion. We can add some text to explain, and here is the
high-level reasoning motivating the transport queue concept:
- Pull: Allow a client to see the possible request points;
- Push: When a client indicates an interest to receive the incremental
updates for a resource, the server can start to push incremental updates to
the client; the transport queue is a resource to tell a client the push
status and also reflect the push URI.


> Even with some guessing, I couldn't easily see how the non-push version is
> supposed to work.  How does the client know which URI to GET?  It looks
> like there is some magical URI construction going on based on examples, but
> that isn't written down.
>
>
We should update the whole workflow: The starting point is the Information
Resource Directory (IRD), which provides the entry point. We put the IRD
example in the later part and we can refer to it before the examples. How
does this sound?


> It looks like Section 8 is over-specifying, with details of stream
> dependencies and so forth.
>
>
Please see the generic email. We will try to simplify when we update. I see
two approaches to simplifying the spec: (1) let the application layer
handle it (each Ui as an independent message in the transport layer); and
(2) only specify the dependency of the resources but do not go to stream
dependency.


> I *think* there is a new resource type here, but that isn't registered in
> the IANA section.

That shouldn't be called "-h2"; a better name would describe what the
> resources are for.  There is also a new media type apparently, but I
> couldn't see where that is defined.
>
> Good catch. We have not included it yet as we are finalizing the semantics
and not the grammar yet, but it is a good point and the new version will
include the spec.

Thank you so much!

Richard



>
>
> On Mon, Jul 11, 2022, at 13:37, Mark Nottingham wrote:
> > Hi folks,
> >
> > I've been asked to forward this request for early review; does anyone
> > want to take a look?
> >
> > Feedback to alto@ietf.org.
> >
> > Cheers,
> >
> >
> >> Begin forwarded message:
> >>
> >> *From: *
> >> *Subject: **HTTP Review (draft-ietf-alto-new-transport)*
> >> *Date: *6 July 2022 at 12:56:56 am AEST
> >> *To: *Mark Nottingham 
> >> *Cc: *Qin Wu , "
> draft-ietf-alto-new-transp...@ietf.org" <
> draft-ietf-alto-new-transp...@ietf.org>
> >>
> >> The ALTO WG is currently working on the specification available at:
> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/. The
> current version focuses on H2 with the intent to cover at least common
> H2/H3 functionalities.
> >>
> >> The WG is seeking for early reviews so that issues/advice are taken
> into account early in the process.
> >>
> >> We are particularly interested in comments about the handling of H3,
> especially with regards to the guid

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

[Y. Richard Yang]

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

Re: [alto] IETF 114 ALTO Hackathon projects

[Mihai Patrascoiu]

Hello Richard,

I'll summarize my answers from the other thread.

Unfortunately, due to other arrangements, we won't be able to attend the 
hackathon this weekend.

However, we are very excited about the proposed objectives. We already 
established a way for the FTS Optimizer zero-order algorithm to make it's way 
into production. Once the feature is ready, with the help of Mario, we can 
organize a large-scale test and compare the results we get in production with 
the simulated results. 

On further ALTO and FTS integration, one aspect I see particularly promising is:
1. Use ALTO information to assess the network capability of a given RSE
2. Set a maximum limit for how much network percentage FTS can occupy. In a 
feedback loop via ALTO, FTS would find whether it may increase or should 
decrease traffic involving that RSE

This maps directly to what we see in production: FTS can hit some sites too 
hard.
Any extra knowledge FTS gets on this aspect would allow it to improve.
 
Best Regards,
Mihai for the FTS team > On 20/07/2022 03:58 Y. Richard Yang  
wrote:
> 
> 
> 
> 
> 
> Hi all,
> 
> 
> 
> During the weekly ALTO meeting today, we discussed the coming hackathon and 
> Qin suggested that we send an update to the mailing list on the FTS+ALTO 
> project, and here is the update:
> 
> 
> - In short, if you want to work on ALTO integration with production, open 
> projects, this can be a wonderful project to work on: it may help both ALTO 
> (in terms of its crucial deployment mandate) and the largest data-intensive 
> science projects at CERN.
> 
> 
> Specifically:
> - For those who have not tracked the hackathon, as Jordi said, it is a 
> continuation of the 113 Hackathon.  In particular, the 113 Hackathon focused 
> on the integration with Rucio, which is a wonderfully designed tool used 
> widely in CERN and some other projects for data movement of a large amount of 
> data (PB -> EB). In 113, the hackathon modified the manual workflow, which is 
> the workflow to select the source to download a dataset when a client issues 
> a download command. The other workflow of Rucio is the automatic workflow, 
> which selects the sources and destinations to realize user-specified 
> replication rules. In our original plan, 114 would focus on the automatic 
> workflow. However, the team realized that Rucio is built on top of FTS, which 
> is the main tool used at CERN to schedule which transfer is scheduled at what 
> time, where Rucio is at a higher layer providing the transfers for FTS to 
> schedule.
> 
> 
> - The 114 hackathon includes 2 objectives: (1) introducing resource control 
> to FTS, and (2) evaluating an alternative design of FTS core: the FTS 
> Optimizer. Hence, the work includes 3 components, integrating the FTS 
> production code and framework:
> (1/basic) allow FTS to specify resource control goal and use ALTO to map FTS 
> control state (called links in FTS, where a link is a pair consisting of a 
> source node to a destination node, where a node is called RSE) to network 
> state; 
> (2/basic) implement a full zero-order algorithm, to achieve fully efficient, 
> zero-order gradient control as FTS Optimizer; 
> (3/stretch) realize a composition framework to compose end-to-end resource 
> performance function, including both zero-order and first-order gradient, 
> covering the bottleneck structure. 
> 
> 
> The project is exciting both in terms of its technical content and also in 
> terms of its potential impacts. The hackathon project will work under the 
> guidance of the Rucio project lead (Dr. Mario Lassnig) and the FTS project 
> lead (Mihai Patrascoiu and Steven Murray); all cc'd in this email. This can 
> be a wonderful opportunity for IETF, the networked systems community and the 
> data-intensive sciences communities to work together.
> 
> 
> Please feel free to reach out to us (Jordi, Mahdi and me) if you want to join 
> the hackathon or later.
> 
> 
> Thanks,
> Richard on behalf of the IETF 114 ALTO+FTS Hackathon Team
> 
> 
> On Tue, Jul 12, 2022 at 1:14 AM Jordi Ros Giralt  > wrote:
> > 
> > Hi all,
> > 
> > 
> > I have uploaded to the IETF Hackathon Wiki the project description for 
> > ALTO. The proposed project is a natural evolution from the work done during 
> > the 113 Hackathon. I want to also thank and credit Jensen for providing the 
> > initial plan for the Hackathon.
> > 
> > 
> > https://trac.ietf.org/trac/ietf/meeting/wiki/114hackathon
> > 
> > 
> > 
> > 
> > 
> > You will also see that in addition to the ALTO hackathon, Ziyang will be 
> > leading a second project under the name "The SDN-based MPTCP-aware and 
> > MPQUIC-aware Transmission Control Model using ALTO". Many thanks Ziyang for 
> > leading this very interesting project too.
> > 
> > 
> > Jordi 
> > On behalf of ALTO Hackathon group 
> > ___
> > alto mailing list
> > alto@ietf.org 
> > https://www.ietf.org/mailm