Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

[Martin Duke]

Two comments:

On Tue, Nov 21, 2023 at 7:09 AM Kai GAO  wrote:

> - I didn't find any explanation of how the "Concurrent, non-blocking update
>>
> transmission" requirement is meet by the new transport. is this solved by
>> the
>> use of HTTP/3 with uses QUIC and does not have HOL blocking within a
>> connection? Or is this addressed by multiple concurrent HTTP connection
>> to the
>> ALTO server? This need to be understood better and we should define what
>> actually "Concurrent, non-blocking update transmission" means in this
>> context
>> of fetching updates.
>>
>>
HTTP/2 was of course intended to be non-blocking at the application layer.
Resources can be delivered whenever they are ready, instead of in order of
request. That's pretty important for update use cases like this one.

Of course, it doesn't solve blocking related to packet loss -- that's what
QUIC is for. But it's totally accurate to say that this transport provides
non-blocking transmission under either version of HTTP.



>
> [KAI] The requirement basically requires that incremental updates can be
> transmitted
> at the same time (concurrent) and the transmission of one update will not
> be blocked
> by the transmission of another update. This can be realized by 1) multiple
> HTTP
> connections, or 2) HTTP/3 using multiple streams. This is compared with
> RFC 8895
> where SSE multiplexes the updates in a single sequence. You make a good
> point that
> we should clarify how this can be done with new transport. We will add a
> paragraph to
> Sec 2.1 and upload a revision soon.
>

I don't see a new paragraph in Sec 2.1 in draft-18. Please post a new draft
with the change, or update this thread with your changed intent.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] PCE

[Martin Duke]

Hi ALTO,

In my email announcing the impending closure of ALTO, I mentioned a number
of potential outlets for future work. I neglected to mention PCE
, which to me seems to covering
a similar problem area. If they haven't already, I would encourage ALTO
practitioners to investigate PCE's activities and see where ALTO solves
their problems, or PCE work solves current ALTO problems.

Similarly, people working on PCE probably have issues with assembling a
topology database, and would probably be fruitful partners for those
working on assembling the ALTO database.

Thanks,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Note to draft authors

[Martin Duke]

Please make sure that there has been a reply to all of the Last Call
reviews.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

[Martin Duke]

Sounds good to me.

On Wed, Oct 18, 2023 at 10:34 PM  wrote:

> Hi Martin,
>
> I would like to change the wording a bit to make sure they guidelines are
> interpreted as applicable only when the resources are sufficient:
>
>
> OLD:
>
> If resources allow, servers SHOULD avoid closing TIPS views that have
> active polling edge requests. Servers also SHOULD avoid closing TIPS views
> that have recently served responses, until clients have had a reasonable
> interval to request the next update.
>
> NEW:
>
> If resources allow, servers SHOULD avoid closing TIPS views that have
> active polling edge requests or have recently served responses
> until clients have had a reasonable interval to request the next update.
>
>
> I will update the document in my evening and post if you think it's OK.
>
>
> Best,
>
> Kai
>
>
> -Original Messages-
> *From:* "Martin Duke" 
> *Send time:* Thursday, 10/19/2023 00:46:46
> *To:* kai...@scu.edu.cn
> *Cc:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
> m...@lowentropy.net>, "IETF ALTO" 
> *Subject:* Re: Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15
>
> Sounds good. I'm going to move this forward, but here are some nits for
> the next iteration. If you can post an update in the next few days, that
> would be ideal.
>
> (S4.1) I think this change is clearer about the intent here:
> OLD
> It must be noted that a server may close a TIPS view, e.g., under high
> system load or due to inactivity. It is RECOMMENDED that a client detects
> the liveness and declares interests of the TIPS view by sending a polling
> edge request. For example, as long as the polling request to
> /ug// does not receive error code 404, the TIPS view
> is still alive.
>
> NEW
> A server MAY close a TIPS view at any time, e.g., under high system load
> or due to client inactivity. In the event that a TIPS view is closed, an
> edge request will receive error code 404 in response, and the client will
> have to request a new TIPS view URI.
>
> If resources allow, servers SHOULD avoid closing TIPS views that have
> active polling edge requests. Servers also SHOULD avoid closing TIPS views
> that have recently served responses, until clients have had a reasonable
> interval to request the next update.
>
> (S8.7)
> OLD
> the ALTO server maintains the set of clients that have sent a polling
> request to the TIPS view, and only removes the view from the storage when
> the set becomes empty.
>
> NEW
> the ALTO server maintains the set of clients that have sent a polling
> request to the TIPS view, and only removes the view from the storage when
> the set becomes empty and no client immediately issues a new edge request
>
> Let me know if you have issues with those changes.
> Martin
>
>
>
> On Tue, Oct 17, 2023 at 6:23 PM  wrote:
>
>>
>>
>>
>> -Original Messages-
>> *From:* "Martin Duke" 
>> *Send time:* Tuesday, 10/17/2023 22:45:05
>> *To:* kai...@scu.edu.cn
>> *Cc:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
>> m...@lowentropy.net>, "IETF ALTO" 
>> *Subject:* Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15
>>
>>
>>
>> On Sat, Oct 14, 2023 at 8:15 PM  wrote:
>>
>>> I do agree that this could create a behavior where the client doesn't
>>> actually need 102/103 but puts in the request just to keep the TIPS view
>>> alive.  From your previous reply, it seems like not having an open edge
>>> request on a resource is an edge case. I think I would prefer that we
>>> recommend that a client that doesn't need an update right away just be
>>> prepared for the TIPS view to go away.
>>>
>>>
>>> [KAI] My previous reply is arguing that guideline <2>, i.e., TIPS views
>>> with recent responses, may lead to unintended client behavior, which may
>>> increase the server complexity to mitigate.
>>>
>>
>> The point of "tracking recent responses" is that you don't want to
>> respond to an open request and then close the TIPS view because there are
>> no open requests -- the server needs to give the client a few RTTs to
>> request the new edge. What unintended client behavior arises from this?
>>
>>  [KAI] OK, I get it. I thought the recent response would apply to not
>> only the open request but to previous request as well. The unintended
>> behavior is that clients compete by sending unnecessary requests to refresh
>> the time of recent response, which I mentioned in previous replies. If 

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

[Martin Duke]

Sounds good. I'm going to move this forward, but here are some nits for the
next iteration. If you can post an update in the next few days, that would
be ideal.

(S4.1) I think this change is clearer about the intent here:
OLD
It must be noted that a server may close a TIPS view, e.g., under high
system load or due to inactivity. It is RECOMMENDED that a client detects
the liveness and declares interests of the TIPS view by sending a polling
edge request. For example, as long as the polling request to
/ug// does not receive error code 404, the TIPS view
is still alive.

NEW
A server MAY close a TIPS view at any time, e.g., under high system load or
due to client inactivity. In the event that a TIPS view is closed, an edge
request will receive error code 404 in response, and the client will have
to request a new TIPS view URI.

If resources allow, servers SHOULD avoid closing TIPS views that have
active polling edge requests. Servers also SHOULD avoid closing TIPS views
that have recently served responses, until clients have had a reasonable
interval to request the next update.

(S8.7)
OLD
the ALTO server maintains the set of clients that have sent a polling
request to the TIPS view, and only removes the view from the storage when
the set becomes empty.

NEW
the ALTO server maintains the set of clients that have sent a polling
request to the TIPS view, and only removes the view from the storage when
the set becomes empty and no client immediately issues a new edge request

Let me know if you have issues with those changes.
Martin



On Tue, Oct 17, 2023 at 6:23 PM  wrote:

>
>
>
> -Original Messages-
> *From:* "Martin Duke" 
> *Send time:* Tuesday, 10/17/2023 22:45:05
> *To:* kai...@scu.edu.cn
> *Cc:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
> m...@lowentropy.net>, "IETF ALTO" 
> *Subject:* Re: Re: Re: AD comments on draft-ietf-alto-new-transport-15
>
>
>
> On Sat, Oct 14, 2023 at 8:15 PM  wrote:
>
>> I do agree that this could create a behavior where the client doesn't
>> actually need 102/103 but puts in the request just to keep the TIPS view
>> alive.  From your previous reply, it seems like not having an open edge
>> request on a resource is an edge case. I think I would prefer that we
>> recommend that a client that doesn't need an update right away just be
>> prepared for the TIPS view to go away.
>>
>>
>> [KAI] My previous reply is arguing that guideline <2>, i.e., TIPS views
>> with recent responses, may lead to unintended client behavior, which may
>> increase the server complexity to mitigate.
>>
>
> The point of "tracking recent responses" is that you don't want to respond
> to an open request and then close the TIPS view because there are no open
> requests -- the server needs to give the client a few RTTs to request
> the new edge. What unintended client behavior arises from this?
>
>  [KAI] OK, I get it. I thought the recent response would apply to not only
> the open request but to previous request as well. The unintended behavior
> is that clients compete by sending unnecessary requests to refresh the time
> of recent response, which I mentioned in previous replies. If we restrict
> guideline <2> to open requests, then there is no problem.
>
>
>>> Another potential issue is that creating new TIPS views with customized
>>> filters (unshareable) is likely to be more computationally expensive than
>>> computing the incremental updates. If there is a resource concern, I would
>>> anticipate that allocating the resources to a steady set of TIPS views is
>>> more efficient. While this may be addressed by using a smarter scheduler,
>>> the client developers cannot know that and may also program defensively,
>>> e.g., by making frequent queries to detect liveness of the view and try
>>> recreating the view before new updates arrive -- otherwise a complete fetch
>>> might be needed.
>>>
>> If custom filters are a big issue, another way to implement this is to
>> have a sequence number space for the base (unfiltered) resource. All
>> filtered requests would use this TIPS view, but many of the updates would
>> be null if they didn't affect filtered elements. This is noisier but
>> reduces state at the server. The noise could be mitigated by the next edge
>> request in Sec 7.4. It's all tradeoffs.
>>
>> [KAI] I would rather not have this complexity. This puts too many
>> constraints on server implementation and some resources (e.g., endpoint
>> cost service) may not have a dependent base resource.
>>
>
> I would certainly not require this, but it is a way one could implement a
> server.
>
>
&

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

[Martin Duke]

On Sat, Oct 14, 2023 at 8:15 PM  wrote:

> I do agree that this could create a behavior where the client doesn't
> actually need 102/103 but puts in the request just to keep the TIPS view
> alive.  From your previous reply, it seems like not having an open edge
> request on a resource is an edge case. I think I would prefer that we
> recommend that a client that doesn't need an update right away just be
> prepared for the TIPS view to go away.
>
>
> [KAI] My previous reply is arguing that guideline <2>, i.e., TIPS views
> with recent responses, may lead to unintended client behavior, which may
> increase the server complexity to mitigate.
>

The point of "tracking recent responses" is that you don't want to respond
to an open request and then close the TIPS view because there are no open
requests -- the server needs to give the client a few RTTs to request
the new edge. What unintended client behavior arises from this?


>
>> Another potential issue is that creating new TIPS views with customized
>> filters (unshareable) is likely to be more computationally expensive than
>> computing the incremental updates. If there is a resource concern, I would
>> anticipate that allocating the resources to a steady set of TIPS views is
>> more efficient. While this may be addressed by using a smarter scheduler,
>> the client developers cannot know that and may also program defensively,
>> e.g., by making frequent queries to detect liveness of the view and try
>> recreating the view before new updates arrive -- otherwise a complete fetch
>> might be needed.
>>
> If custom filters are a big issue, another way to implement this is to
> have a sequence number space for the base (unfiltered) resource. All
> filtered requests would use this TIPS view, but many of the updates would
> be null if they didn't affect filtered elements. This is noisier but
> reduces state at the server. The noise could be mitigated by the next edge
> request in Sec 7.4. It's all tradeoffs.
>
> [KAI] I would rather not have this complexity. This puts too many
> constraints on server implementation and some resources (e.g., endpoint
> cost service) may not have a dependent base resource.
>

I would certainly not require this, but it is a way one could implement a
server.


>
> One potential solution is:
>
> 1. Remove heartbeat and close, and state that a client 1) must not expect
> the view to be permanent unless instructed by the service operator or
> further extensions and 2) should send an open request to detect liveness of
> the view if necessary.
> 2. Add a subsection such as "Considerations for Resource Contention" and
> leave the choice of handling contentions to the implementation, with
> suggestions such as that usage-based solution may lead to unintended client
> behavior.
>
> Personally I think deletion is still needed. Consider the case where the
> server is charging clients based on usages such as number of concurrent
> TIPS views and number of requests, removing deletion makes is impossible
> for a client to actively control the TIPS views that remain open. I would
> anticipate that we submit a new I-D enabling that feature :D
>

This solution works for me, although there's already a section on resource
management that's pretty good. I don't like the idea of DELETE being used
as some sort of pricing signal -- that seems like abuse of the protocol.


>
>
>> Those are the thoughts that I have at this point. Any comments or
>> suggestions are appreciated!
>>
>> Best,
>>
>> Kai
>>
>> -Original Messages-
>> *From:* "Martin Duke" 
>> *Send time:* Thursday, 10/12/2023 22:54:32
>> *To:* kai...@scu.edu.cn
>> *Cc:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
>> m...@lowentropy.net>, "IETF ALTO" 
>> *Subject:* Re: AD comments on draft-ietf-alto-new-transport-15
>>
>> Kai,
>>
>> Adding the ALTO list for proper archiving of this thread.
>>
>> I don't see that the fact that it's a proxy matters here; if there is
>> *any* open request from anywhere, that's an indication that someone is
>> still interested in the TIPS view.
>>
>> If I understand MT's comments correctly, he would prefer somewhat looser
>> requirements on the server here. This has some friction with my AD review,
>> but maybe we can synthesize something better here.
>>
>> I see two ways forward:
>> 1) This Heartbeat/DELETE design with the discussed changes. It's clever
>> but a little complicated, and I have concerns about the scalability of
>> Heartbeats.
>>
>> 2) A set of rules that sets reasonable expectations 

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

[Martin Duke]

On Fri, Oct 13, 2023 at 12:36 AM  wrote:

> Hi Martin,
>
> Thanks for the summary. I like the simplicity of approach 2 but here are
> some concerns.
>
> The previous service model is more like First-Come First-Serve, so that
> the server keeps the resources for views that already exist and reject
> requests if the resources are constrained. Approach 2 can still be FCFS
> based on the implementation & configuration but seems more best-effort,
> given the implication that server offers no guarantee to the TIPS view.
>

Agreed that it's best effort. The original draft delivered to me was best
effort, but was pretty vague about what servers can do. (2) has a bunch of
guidelines for servers so clients can make assumptions, but servers can
break them when under stress.


> If the liveness of a TIPS view depends on the usage, I wonder if that will
> encourage clients to compete, for example, by making requests that are not
> necessary. In the extreme case, a client may even try disabling caching on
> intention to make sure the repeated requests arrive at the server, which
> essentially becomes heartbeating but with data in the response. Even though
> a malicious client can still do that in the current design, the incentives
> for normal clients will be much weaker as they can do that legitimately.
>
The intent of (2) is not to keep stats on the number of open requests for a
resource! I think it's a bad idea because of caching, etc. Instead, if
there's an open request it should be retained.

If there are no stats on the number of open requests, then caching doesn't
matter.

I do agree that this could create a behavior where the client doesn't
actually need 102/103 but puts in the request just to keep the TIPS view
alive.  From your previous reply, it seems like not having an open edge
request on a resource is an edge case. I think I would prefer that we
recommend that a client that doesn't need an update right away just be
prepared for the TIPS view to go away.


> Another potential issue is that creating new TIPS views with customized
> filters (unshareable) is likely to be more computationally expensive than
> computing the incremental updates. If there is a resource concern, I would
> anticipate that allocating the resources to a steady set of TIPS views is
> more efficient. While this may be addressed by using a smarter scheduler,
> the client developers cannot know that and may also program defensively,
> e.g., by making frequent queries to detect liveness of the view and try
> recreating the view before new updates arrive -- otherwise a complete fetch
> might be needed.
>
If custom filters are a big issue, another way to implement this is to have
a sequence number space for the base (unfiltered) resource. All filtered
requests would use this TIPS view, but many of the updates would be null if
they didn't affect filtered elements. This is noisier but reduces state at
the server. The noise could be mitigated by the next edge request in Sec
7.4. It's all tradeoffs.

Those are the thoughts that I have at this point. Any comments or
> suggestions are appreciated!
>
> Best,
>
> Kai
>
> -Original Messages-
> *From:* "Martin Duke" 
> *Send time:* Thursday, 10/12/2023 22:54:32
> *To:* kai...@scu.edu.cn
> *Cc:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
> m...@lowentropy.net>, "IETF ALTO" 
> *Subject:* Re: AD comments on draft-ietf-alto-new-transport-15
>
> Kai,
>
> Adding the ALTO list for proper archiving of this thread.
>
> I don't see that the fact that it's a proxy matters here; if there is
> *any* open request from anywhere, that's an indication that someone is
> still interested in the TIPS view.
>
> If I understand MT's comments correctly, he would prefer somewhat looser
> requirements on the server here. This has some friction with my AD review,
> but maybe we can synthesize something better here.
>
> I see two ways forward:
> 1) This Heartbeat/DELETE design with the discussed changes. It's clever
> but a little complicated, and I have concerns about the scalability of
> Heartbeats.
>
> 2) A set of rules that sets reasonable expectations of the server that the
> client can use, but that ultimately falls back on 404s. No Heartbeat or
> DELETE. Something like:
>
> Servers might have to delete a TIPS view due to resource constraints,
> especially when the resource is specific to a single client.
>
> - Servers SHOULD NOT delete a TIPS view when there is an open request for
> an edge.
> - Servers SHOULD NOT delete a TIPS view if it sent a response for an edge
> in the last few seconds.
> - Servers MUST respond with a 404 or 410 if the requested TIPS view has
> been destroyed. Clients can then request a new TIPS view.
>
&g

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

[Martin Duke]

Kai,

Adding the ALTO list for proper archiving of this thread.

I don't see that the fact that it's a proxy matters here; if there is *any*
open request from anywhere, that's an indication that someone is still
interested in the TIPS view.

If I understand MT's comments correctly, he would prefer somewhat looser
requirements on the server here. This has some friction with my AD review,
but maybe we can synthesize something better here.

I see two ways forward:
1) This Heartbeat/DELETE design with the discussed changes. It's clever but
a little complicated, and I have concerns about the scalability of
Heartbeats.

2) A set of rules that sets reasonable expectations of the server that the
client can use, but that ultimately falls back on 404s. No Heartbeat or
DELETE. Something like:

Servers might have to delete a TIPS view due to resource constraints,
especially when the resource is specific to a single client.

- Servers SHOULD NOT delete a TIPS view when there is an open request for
an edge.
- Servers SHOULD NOT delete a TIPS view if it sent a response for an edge
in the last few seconds.
- Servers MUST respond with a 404 or 410 if the requested TIPS view has
been destroyed. Clients can then request a new TIPS view.

I would lean towards (2), but am interested in what you and the team think.

Martin Duke





On Thu, Oct 12, 2023 at 6:58 AM  wrote:

> Hi Martin,
>
> Thanks for the comments. Please see inline.
>
> Best,
>
> Kai
>
> -Original Messages-
> *From:* "Martin Duke" 
> *Send time:* Thursday, 10/12/2023 03:27:14
> *To:* draft-ietf-alto-new-transport@ietf.org, "Martin Thomson" <
> m...@lowentropy.net>
> *Subject:* AD comments on draft-ietf-alto-new-transport-15
>
> Hello ALTO and Martin,
>
> Thanks to Martin for his excellent HTTPDIR review and the team's quick
> work to update the draft. The primary purpose of this email is to verify
> with Martin that the edits are sufficient to address his concerns, as those
> objections are quite detailed.
>
> I also have a couple of followup questions and nits for my own
> understanding:
>
> - Is it a valid use case for the client to open a tips view and then not
> have a request open for an edge? (i.e. can it hold a tips review "in
> reserve" in case it has a need for the resource?) If not, it seems like a
> simpler way to do this would be for the server to keep the tips view open
> as long as there is an open request for an edge (giving a grace period of a
> few RTTs from when a request is filled to allow the client to request the
> next edge). IIUC, this seems much easier than the heartbeat mechanism, and
> more scalable: a cache only needs to forward one GET per update, instead of
> N heartbeats going all the way back to the origin.
>
>
> [KAI] The current document does not demand the client to always send an
> open request. One reason is that, in the case of handling dependent TIPS
> views, a client may hold the request to fetch the latest update of one
> resource (e.g., a cost map) when it is still processing updates for a
> dependent resource (e.g., a network map). Even if we demand that, one
> lesson I learnt from the previous persistent connection debate is that the
> open request, which implies that the underlying connection is still up, may
> not reflect the status of a client but that of a proxy.
>
> Assuming that doesn't work, two questions about heartbeat and DELETEs:
>
> - (S4.1) I don't think the DELETE mechanism works properly. Let's say
> there are two clients subscribing to a TIPS view and they both are sending
> Heartbeat POST requests. if the first client sends DELETE, the server
> really should not delete the TIPS view!
>
> [KAI] Yes the server should not. We do mention how to correctly manage
> shared views in section 8.7.
>
> Sec 6 says "The server MAY keep track of which clients are subscribing to
> each TIPS view to determine whether or not it should delete a TIPS view and
> its corresponding updates graph and associated data." ISTM this is an
> obsolete relic from an earlier design (as some GETs may never arrive at the
> server due to a cache), and a better sentence might be "The server SHOULD
> keep track of how many clients are sending it heartbeat messages and SHOULD
> NOT delete the TIPS view until each client has either sent a DELETE request
> or failed to send a Heartbeat message in the required interval".
>
> [KAI] The proposed text is clearer. We will update the text with a small
> variantion: the server may close the view if multiple heartbeat messages
> are not received.
>
> - (S6.4) There are a few instances of "must" here that I believe should be
> "MUST"?
>
> [KAI] Indeed. Updated as suggested.
>
> thanks
> Martin (Duke)
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Status of ALTO

[Martin Duke]

To the participants in ALTO:

I am proud of the achievements of this community in building the ALTO
protocol, and deploying it for new use cases after the initial use case
didn't work out. Nevertheless, after extensive consideration I have decided
to close the ALTO working group once the current deliverables have
stabilized. The IESG's area reorganization plan [1] ultimately does not
affect this decision, although I consulted with the OPS ADs.

Briefly, my assessment is that proposed new work items either do not fit in
any sensible boundary for ALTO, and/or are not ready for standardization at
this time. Furthermore, this group is a little small to produce robust
reviews, and would benefit from participation in a wider community.

The mailing list will remain open as a tool for ALTO practitioners. *I
encourage further work in ALTO both inside and outside the IETF/IRTF*.
Closing a working group in no way indicates that a technology is obsolete
or deprecated, merely that the group’s mission is complete.

There are several IETF and IRTF venues the community can consider for
additional work in this area:

OPSAWG <https://datatracker.ietf.org/wg/opsawg/about/> for minor
maintenance of the existing ALTO RFCs, and other one-off topics that don’t
fit elsewhere.

GROW <https://datatracker.ietf.org/wg/grow/about/> for aggregation of BGP
routing information. LSR <https://datatracker.ietf.org/wg/lsr/about/> or
RTGWG <https://datatracker.ietf.org/wg/rtgwg/about/> could work for other
protocols. TEAS <https://datatracker.ietf.org/wg/teas/about/> is also
chartered to work on collection of information for traffic engineering
purposes, which seems like a much bigger use case than ALTO.

CATS <https://datatracker.ietf.org/wg/cats/about/> for compute as a metric.

IPPM <https://datatracker.ietf.org/wg/ippm/about/> for
collection/aggregation of performance metrics like latency.

PANRG <https://datatracker.ietf.org/rg/panrg/about/> for research results
related to path awareness at the transport layer.

Notably, gathering topology data is an interesting problem but has
potential applications well beyond ALTO. If there is an explosion of work
on this subject, a BoF in the Routing or Ops area would be appropriate.
This BoF would ideally consider the ALTO use case, but also bring in
participants with related problems.

The ALTO community is also welcome to request a side meeting or hackathon
slot at future IETFs to further deployment and implementation of existing
standards and pioneer development of further extensions.

Thanks to everyone for their past, and ongoing, contributions to the
internet.

Martin Duke

Responsible AD


[1] https://mailarchive.ietf.org/arch/msg/ietf/qK_TwOiniQWxonzhkE5AQeK45mg/
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03: (with DISCUSS and COMMENT)

[Martin Duke]

I see now that 8.5 of RFC 7285 covers this, so please disregard

On Thu, Jun 2, 2022 at 12:07 PM Martin Duke  wrote:

> I discussed this with Paul. Can we add a sentence about what to do if the
> received string is more than 32 characters?
>
> On Wed, Jun 1, 2022 at 9:24 PM  wrote:
>
>> Hi Paul,
>>
>> Thank you for the review.
>>
>> Please see inline.
>>
>> Cheers,
>> Med
>>
>> > -Message d'origine-
>> > De : Paul Wouters via Datatracker 
>> > Envoyé : jeudi 2 juin 2022 05:12
>> > À : The IESG 
>> > Cc : draft-ietf-alto-cost-m...@ietf.org; alto-cha...@ietf.org;
>> > alto@ietf.org; kai...@scu.edu.cn; kai...@scu.edu.cn
>> > Objet : Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03:
>> > (with DISCUSS and COMMENT)
>> >
>> > Paul Wouters has entered the following ballot position for
>> > draft-ietf-alto-cost-mode-03: Discuss
>> >
>> > When responding, please keep the subject line intact and reply to
>> > all email addresses included in the To and CC lines. (Feel free to
>> > cut this introductory paragraph, however.)
>> >
>> >
>> > Please refer to
>> > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
>> > positions/
>> > for more information about how to handle DISCUSS and COMMENT
>> > positions.
>> >
>> >
>> > The document, along with other ballot positions, can be found
>> > here:
>> > https://datatracker.ietf.org/doc/draft-ietf-alto-cost-mode/
>> >
>> >
>> >
>> > --
>> > 
>> > DISCUSS:
>> > --
>> > 
>> >
>> > Probably an easily answered issue, but I am not too familiar with
>> > ALTO.
>> >
>> >  The string MUST be no more than 32 characters, and it MUST
>> > NOT contain
>> >  characters other than [...]
>> >
>> > Are there implementations that already deployed a cost string with
>> > more than 32
>> > characters or characters not in this newly imposed set of
>> > characters?
>>
>> [Med] No.
>>
>>  What
>> > should happen if that is in use? That is, is this protocol
>> > modification
>> > potentially breaking interoperability with older implementations?
>> >
>> >
>> > --
>> > 
>> > COMMENT:
>> > --
>> > 
>> >
>> > While no fan of "patch RFCs", thank you for at least putting the
>> > OLD and NEW
>> > text in one document, so an implementer and reviewer doesn't have
>> > to switch
>> > between documents and get confused about what was read was the old
>> > doc or new
>> > doc.
>> >
>> > That said, patching in the text "This document" feels a little
>> > weird. What RFC
>> > does "This document" then refer to? Perhaps change "This document
>> > defines two
>> > cost modes" to "Two cost modes are defined".
>>
>> [Med] OK.
>>
>> >
>> >  Future documents that define a new cost mode SHOULD indicate
>> >
>> > I think that SHOULD can be a MUST.
>>
>> [Med] We don't use MUST here because we do have a default behavior
>> specified in the sentence right after: "If not explicitly indicated, the
>> new cost mode applies to all cost metrics."
>>
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>> ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>
>>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] [IANA #1230654] [Errata Verified] RFC7285 (6876)

[Martin Duke]

yes, I believe that is correct.

On Fri, May 13, 2022 at 12:58 PM Amanda Baber via RT 
wrote:

> Hi all,
>
> This question relates to both 6874 and 6876:
>
> Should "priv:" be removed from the ALTO Cost Metrics and ALTO Endpoint
> Property Types registries? See
>
> https://www.iana.org/assignments/alto-protocol
>
> If so, should we add the note "Note: Identifiers prefixed with 'priv:' are
> reserved for Private Use (see RFC 7285, Section 10.8.2)" to the top of each
> registry?
>
> We'll need Martin to sign off on any registry changes.
>
> thanks,
>
> Amanda Baber
> IANA Operations Manager
>
> On Thu May 12 22:09:51 2022, rfc-edi...@rfc-editor.org wrote:
> > The following errata report has been verified for RFC7285,
> >  "Application-Layer Traffic Optimization (ALTO) Protocol".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6876
> >
> > ------
> > Status: Verified
> > Type: Technical
> >
> > Reported by: Mohamed BOUCADAIR 
> > Date Reported: 2022-03-09
> > Verified by: Martin Duke (IESG)
> >
> > Section: 14.3
> >
> > Original Text
> > -
> > +++
> > | Identifier | Intended Semantics |
> > +++
> > | pid| See Section 7.1.1  |
> > | priv:  | Private use|
> > +++
> >
> > Table 4: ALTO Endpoint Property Types
> >
> >
> > Corrected Text
> > --
> > +++
> > | Identifier | Intended Semantics |
> > +++
> > | pid| See Section 7.1.1  |
> > +++
> >
> > Table 4: ALTO Endpoint Property Types
> >
> > Note: Identifiers prefixed with "priv:" are
> > reserved for Private Use (see Section 10.8.2.)
> >
> >
> > Notes
> > -
> > priv: is not an identifier, but a prefix.
> >
> > --
> > RFC7285 (draft-ietf-alto-protocol-27)
> > --
> > Title   : Application-Layer Traffic Optimization (ALTO)
> > Protocol
> > Publication Date: September 2014
> > Author(s)   : R. Alimi, Ed., R. Penno, Ed., Y. Yang, Ed., S.
> > Kiesel, S. Previdi, W. Roome, S. Shalunov, R. Woundy
> > Category: PROPOSED STANDARD
> > Source  : Application-Layer Traffic Optimization
> > Area: Transport
> > Stream  : IETF
> > Verifying Party : IESG
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)

[Martin Duke]

Yes, the so the idea here is that we'd do a short new PS document
updating 7285 to loosen the MUST and establish a registry, which
path-vector could then reference.

On Fri, Mar 4, 2022 at 2:42 AM Qin Wu  wrote:

> Kai:
>
> If my understanding is correct, an Experimental RFC can not update a
> Standards Track RFC. It is unlikely IESG will make a new rule for this.
>
>
>
> -Qin
>
> *发件人:* kai...@scu.edu.cn [mailto:kai...@scu.edu.cn]
> *发送时间:* 2022年3月4日 15:24
> *收件人:* Martin Duke 
> *抄送:* Benjamin Kaduk ; IETF ALTO ;
> alto-chairs ; The IESG ;
> draft-ietf-alto-path-vec...@ietf.org
> *主题:* Re: Re: [alto] Benjamin Kaduk's Discuss on
> draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)
>
>
>
> Hi Martin and Ben,
>
>
>
> I think ideally making an update to RFC 7285 probably is the best way to
> solve the issue. In RFC 7285, the definition for the cost services actually
> leave space for non-numerical/ordinal cost values:
>
>
>
> Section 11.2.3.6:
>
>
>
>... An implementation of the protocol in this document
>
>SHOULD assume that the cost is a JSONNumber and fail to parse if it
>
>is not, unless the implementation is using an extension to this
>
>document that indicates when and how costs of other data types are
>
>signaled.
>
> and similarly in section 11.5.1.6:
>
>
>
>... An implementation of the protocol in this document
>
>SHOULD assume that the cost value is a JSONNumber and fail to parse
>
>if it is not, unless the implementation is using an extension to this
>
>document that indicates when and how costs of other data types are
>
>signaled.
>
>
>
> Thus, adding a cost mode registry and modifying the definition of CostMode
> in section 10.5 may be sufficient to solve the issue without breaking the
> other parts of RFC 7285 and other extensions.
>
>
>
> Best,
>
> Kai
>
>
>
>
> -Original Messages-
> *From:*"Martin Duke" 
> *Sent Time:*2022-03-04 04:25:37 (Friday)
> *To:* "Kai Gao" 
> *Cc:* "Benjamin Kaduk" , "IETF ALTO" ,
> alto-chairs , "The IESG" ,
> draft-ietf-alto-path-vec...@ietf.org
> *Subject:* Re: [alto] Benjamin Kaduk's Discuss on
> draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)
>
> Ben and Kai,
>
>
>
> Thanks for calling attention to this problem.
>
>
>
> In RFC 7285, there is no IANA registry for Cost Mode, because, as you
> point out Sec 10.5
> <https://www.rfc-editor.org/rfc/rfc7285.html#section-10.5> says the Mode
> MUST be "ordinal" or "numerical".
>
>
>
> RFC 8896, though not listed as a document that updates RFC 7285, certainly
> implies it is doing so in Sec 3.3.1:
> <https://www.rfc-editor.org/rfc/rfc8896.html#name-alto-cost-calendar-for-all->
>
>
>
> An ALTO Cost Calendar is well suited for values encoded in the "numerical"
> mode. Actually, a Calendar can also represent metrics in other modes
> considered as compatible with time-varying values. For example, types of
> cost values (such as JSONBool) can also be calendared (as their value may
> be 'true' or 'false' depending on given time periods or likewise) values
> represented by strings, such as "medium", "high", "low", "blue", and "open".
>
>
>
> and in 3.3.2:
>
>
>
> As a consequence, when a metric is available as a Calendar array, it also
> *MUST* be available as a single value, as required by [RFC7285
> <https://www.rfc-editor.org/rfc/rfc8896.html#RFC7285>]. The Server, in
> this case, provides the current value of the metric to either
> Calendar-aware Clients not interested in future or time-based values or
> Clients implementing [RFC7285
> <https://www.rfc-editor.org/rfc/rfc8896.html#RFC7285>] only.
>
>
>
> then in Sec 4.3 there are fictitious examples of string Cost Modes, etc.
>
>
>
> I'm not sure that any of that is helpful, but RFC8896 is at least a worked
> example of delivering an array of costs without coining a new Cost Mode.
> Unfortunately, this is an array of strings, not an array of numericals or
> ordinals.
>
>
>
> I'm not sure I see a way forward other than a short new PS draft that
> updates 7285 and creates a Cost Mode registry. Other ideas?
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Mar 3, 2022 at 9:51 AM  wrote:
>
> Hi Ben,
>
> Thanks a lot for the review. The comments are really helpful. We have
> proposed texts for most of the comments except for calculating
> content-lengths and the security-related comments, which we will come 

Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)

[Martin Duke]

Ben and Kai,

Thanks for calling attention to this problem.

In RFC 7285, there is no IANA registry for Cost Mode, because, as you point
out Sec 10.5 
says the Mode MUST be "ordinal" or "numerical".

RFC 8896, though not listed as a document that updates RFC 7285, certainly
implies it is doing so in Sec 3.3.1:


An ALTO Cost Calendar is well suited for values encoded in the "numerical"
> mode. Actually, a Calendar can also represent metrics in other modes
> considered as compatible with time-varying values. For example, types of
> cost values (such as JSONBool) can also be calendared (as their value may
> be 'true' or 'false' depending on given time periods or likewise) values
> represented by strings, such as "medium", "high", "low", "blue", and "open".


and in 3.3.2:

As a consequence, when a metric is available as a Calendar array, it also
> MUST be available as a single value, as required by [RFC7285
> ]. The Server, in
> this case, provides the current value of the metric to either
> Calendar-aware Clients not interested in future or time-based values or
> Clients implementing [RFC7285
> ] only.


then in Sec 4.3 there are fictitious examples of string Cost Modes, etc.

I'm not sure that any of that is helpful, but RFC8896 is at least a worked
example of delivering an array of costs without coining a new Cost Mode.
Unfortunately, this is an array of strings, not an array of numericals or
ordinals.

I'm not sure I see a way forward other than a short new PS draft that
updates 7285 and creates a Cost Mode registry. Other ideas?





On Thu, Mar 3, 2022 at 9:51 AM  wrote:

> Hi Ben,
>
> Thanks a lot for the review. The comments are really helpful. We have
> proposed texts for most of the comments except for calculating
> content-lengths and the security-related comments, which we will come up
> with some proposal tomorrow. Please see our feedback inline.
>
> Best,
> Kai
>
>
>  -Original Messages-
>  From: "Benjamin Kaduk via Datatracker" 
>  Sent Time: 2022-03-03 17:53:16 (Thursday)
>  To: "The IESG" 
>  Cc: alto-cha...@ietf.org, draft-ietf-alto-path-vec...@ietf.org,
> alto@ietf.org
>  Subject: [alto] Benjamin Kaduk's Discuss on
> draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)
> 
>  Benjamin Kaduk has entered the following ballot position for
>  draft-ietf-alto-path-vector-22: Discuss
> 
>  When responding, please keep the subject line intact and reply to all
>  email addresses included in the To and CC lines. (Feel free to cut
> this
>  introductory paragraph, however.)
> 
> 
>  Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>  for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
>  The document, along with other ballot positions, can be found here:
>  https://datatracker.ietf.org/doc/draft-ietf-alto-path-vector/
>  ;
> 
> 
>  --
>  DISCUSS:
>  --
> 
>  The IANA Considerations section seems incomplete.
>  Looking over the registries at
>  https://www.iana.org/assignments/alto-protocol/alto-protocol.xhtml
> and
>  comparing against the mechanisms defined in this document, it seems
> that
>  we need to register the "ane-path" Cost Metric.
>
> Thanks for pointing that out. We will add a new section to register the
> cost metric.
>
>  More worryingly, there is
>  no registry on that page in which the "array" cost mode could be
>  registered, and it seems that using any value other than "numerical"
> or
>  "ordinal" would violate a "MUST" in §10.5 of RFC 7285.  This seems to
>  present some procedural difficulties, especially now that this
> document is
>  targeting Experimental status rather than Proposed Standard (which,
> to be
>  clear, I think was the right thing to do).
>
> Indeed this is a big issue. As it also doesn't make sense if we use either
> ordinal or numerical as the cost mode, we cannot fall back to what is
> compatible with RFC 7285. Here is what we have in mind: first we make it
> clear that the new cost mode will violate RFC 7285; second, we restrict the
> use of the cost mode to only the ALTO information resources that enable
> this extension. Here is the proposed text:
>
> Note that the new cost mode violates the requirements that cost mode
> MUST either
> be "numerical" or "ordinal" in Section 10.5 of {{RFC7285}}. To avoid
> compatibility issues, an ALTO server MUST NOT use this cost mode in an
> ALTO
> information resource that does not enable this extension.
>
> 
> 
>  --
> 

Re: [alto] Éric Vyncke's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

[Martin Duke]

Authors,

8312bis is still in the informational references; is this an oversight, or
are you arguing that it's not normative?

On Mon, Nov 22, 2021 at 8:39 AM Martin Duke  wrote:

> Good catch!
>
> I'm not sure that either of these references are actually directly
> relevant to the subject, though I'm happy to be convinced otherwise.
>
> It might be that one of the IPPM docs (RFC 8337?) might be a better fit.
>
> If RFC 8312 is the right answer, 8312bis is almost done and they can
> simply update to avoid the downref.
>
> Martin
>
> On Mon, Nov 22, 2021 at 7:54 AM Eric Vyncke (evyncke) 
> wrote:
>
>> Martin,
>>
>>
>>
>> The text in § 4.1.3 says:
>>
>>Intended Semantics: To give the throughput of a TCP congestion-
>>
>>control conforming flow from the specified source to the specified
>>
>>destination; see [RFC3649, Section 5.1 of RFC8312
>> <https://datatracker.ietf.org/doc/html/rfc8312#section-5.1>] on how TCP
>>
>>throughput is estimated.  The spatial aggregation level is specified
>>
>>in the query context (e.g., PID to PID, or endpoint to endpoint).
>>
>>
>>
>> So, it is RFC 8312 in the text, RFC 8312 is vaguely related to TCP
>> bandwidth
>>
>>
>>
>> -éric
>>
>>
>>
>> *From: *Martin Duke 
>> *Date: *Monday, 22 November 2021 at 16:40
>> *To: *Eric Vyncke 
>> *Cc: *The IESG , alto-chairs , "
>> draft-ietf-alto-performance-metr...@ietf.org" <
>> draft-ietf-alto-performance-metr...@ietf.org>, IETF ALTO ,
>> Jan Seedorf 
>> *Subject: *Re: Éric Vyncke's Discuss on
>> draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)
>>
>>
>>
>> Thanks Eric,
>>
>>
>>
>> I think you mean RFC 8321? I am in the early stages of AD sponsoring a
>> draft to update that to PS. The authors have the choice of doing a downref
>> or referring to 8321bis and being stuck in the RFCEd queue for a few extra
>> months.
>>
>>
>>
>> On Mon, Nov 22, 2021 at 3:32 AM Éric Vyncke via Datatracker <
>> nore...@ietf.org> wrote:
>>
>> Éric Vyncke has entered the following ballot position for
>> draft-ietf-alto-performance-metrics-19: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>> for more information about how to handle DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
>>
>>
>>
>> --
>> DISCUSS:
>> --
>>
>> Thank you for the work put into this document. Please bear with my lack of
>> knowledge about ALTO in general.
>>
>> Please find below one trivial blocking DISCUSS points (probably easy to
>> address), some non-blocking COMMENT points (but replies would be
>> appreciated
>> even if only for my own education), and some nits.
>>
>> Special thanks to Jan Seedorf for the shepherd's write-up about the WG
>> consensus (even if not using the usual template).
>>
>> I have appreciated the "operational considerations" section as it
>> addresses
>> many questions that popped up during reading the document; notably, how
>> can the
>> ALTO server measure any metric between the ALTO client and a resource.
>>
>> I hope that this helps to improve the document,
>>
>> Regards,
>>
>> -éric
>>
>> == DISCUSS ==
>>
>> -- Section 4.1.3 --
>> A very trivial DISCUSS to fix: this document relies on RFC 8312 to
>> specify how
>> TCP throughput is estimated but RFC 8312 does not appear in the normative
>> reference list (this will probably generate a down ref though).
>>
>>
>> --
>> COMMENT:
>> --
>>
>> == COMMENTS ==
>>
>> Minor regret about the examples as they are all about the IPv4 address
>> family
>> especially in a world of happy eyeballs where the IPv4 and IPv6 paths may
>> still
>> have different performance metrics.
>&g

[alto] New chair!

[Martin Duke]

Hello ALTO,

I'd like to welcome Mohamed Boucadair, of Orange, as the new ALTO chair.
This frees Jan to step down at his convenience. When he chooses to do so,
we'll thank him properly.

Mohamed has not been intimately involved with ALTO, but he will bring
significant IETF experience and an operator's perspective to the role.
Thanks for serving, Mohamed!

I'd also like to thank the other candidates. We were blessed with several
volunteers who all would have done a fine job, and it was hard to pick from
them.

Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] IESG evaluation results

[Martin Duke]

Hi Richard,

Yes, I agree that metric collection is out of scope. However, to the extent
that we can import very precise definition (perhaps saying that ALTO
servers SHOULD post measurements as close to this definition as possible?)
it will save a lot of text and review.

On Fri, Dec 3, 2021 at 11:06 AM Y. Richard Yang  wrote:

> Hi Martin,
>
> Add the WG, so that we can hear others' comments as well. Please see below
> for a small addition.
>
> On Fri, Dec 3, 2021 at 1:46 PM Y. Richard Yang  wrote:
>
>> Martin,
>>
>> Thanks a lot for the update! A quick reply on performance metrics.
>>
>> On Fri, Dec 3, 2021 at 1:22 PM Martin Duke 
>> wrote:
>>
>>>
>>> 2) We will have to do something about performance-metrics. In the
>>> telechat, we agreed that metrics collection is out of scope.
>>>
>>
>> Not sure I understand what metrics collection refers to. Could you please
>> add a bit of detail?
>>
>>
>>> However, more precise definitions of these metrics are in scope. I would
>>> suggest finding RFCs in the ippm WG stream that contain useful definitions
>>> and using those.
>>>
>>
>> Going down the path ippm can lead to potential issues. The
>> current metrics definitions are more based on deriving path metrics from
>> link metrics reported in the routing system (e.g., BGP-LS). This is how
>> current deployment (e.g., Flow Director, Lui's team) works and hence is
>> proven to be feasible. I do not see that the routing systems will start to
>> ask routing devices to measure link properties using ippm measurements, and
>> then report using routing protocols. Then conforming to ippm measurement
>> metrics can lead to higher deployment barriers. We sure can take a look but
>> want to point out the potential problem first.
>>
>>
> Almost all metrics are derived from BGL-LS metrics (RFC8571). Hence, it is
> not clear what more precise definitions mean. Does it mean that those
> definitions in RFC8571 (which are defined in IGP existing IGP protocols)
> are not precise, and hence should not be used (and hence switch to ippm
> type of metrics, which specify many more parameters such as traffic
> patterns)? Or it means that the performance metric document should just
> make a single reference, and the IGP metrics as already defined by IETF are
> acceptably "precise".
>
> Or maybe it is only about the tput metric, and if so, we can discuss it
> carefully.
>
> Thanks a lot,
> Richard
>
>
>
>
>
>
>> Thanks.
>>
>> Richard
>>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] IESG evaluation results

[Martin Duke]

The IESG ballot did not go particularly well.

Not enough ADs read the drafts to advance any of the documents, which is
unfortunate and reflects poorly on the IESG. However, there are numerous
useful and straightforward reviews, DISCUSS and otherwise, that we can
immediately address.

To the extent that author resources are limited, I suggest you focus on
resolving issues on unified-props, as this is the prerequisite for others
and the changes are straightforward. I will nag the ADs to move forward
with reviews and clearing DISCUSSES, starting with this draft.

There are two DISCUSSes that are worthy of some, well, discussion:

1) I believe that Roman's suggestion that path-vector move to Experimental
is valid, as to my knowledge there is not a lot of experience with
obscuring network details. I see no normative references to this draft, so
this would not create problems down the road.

2) We will have to do something about performance-metrics. In the telechat,
we agreed that metrics collection is out of scope. However, more precise
definitions of these metrics are in scope. I would suggest finding RFCs in
the ippm WG stream that contain useful definitions and using those.

Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Lars Eggert's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

[Martin Duke]

1. One problem here is that 3649 and 8312 aren't in the references at all,
so that should be fixed if we retain the text

2. IMO collection of bandwidth information is out of scope of this
document; in general collection of network information is out of scope for
ALTO. I viewed the references as informative examples rather than a
prescription of how it's collected.

3. I agree, in retrospect, that 3649 and 8312 are bad suggestions, as their
result is very time-dependent and noisy. From the rest of section 4, this
metric is clearly in the context of bandwidth reservations and min(raw link
capacity) is probably a better indicator. However, the rest of these
sections don't really talk about metric definitions, so it might be best
simply to delete the parenthetical.

So my suggestion would be to take Lars's request to define what the authors
mean a little precisely (raw capacity?), but not to the granularity that
IPPM defines metrics, and get rid of the references entirely.

Is that satisfactory to you, Lars?

Martin

On Mon, Nov 29, 2021 at 5:10 AM Lars Eggert via Datatracker <
nore...@ietf.org> wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-alto-performance-metrics-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
>
>
>
> --
> DISCUSS:
> --
>
> This document needs to become much more formal about how it defines the
> metrics it wishes to use with ALTO. This could either be done either by
> identifying and normatively referencing existing metrics the IETF has
> defined,
> or by defining them here. When normatively referencing existing IETF
> metrics, it
> would need to explain why their use with ALTO makes sense.
>
> At the moment, the document informatively points to a somewhat arbitrary
> collection of prior IETF metrics (most of which are from IPPM, residual
> bandwidth from IS-IS TE, but then reservable bandwidth from OSPF TE?). But
> it
> only refers to them as "examples", without actually defining how exactly
> they
> are to be used with ALTO, or - if not those - which actual metrics are
> supposed
> to be used.
>
> Defining a mechanism for exposing metric information to clients isn't
> really
> useful unless the content of that information is much more clearly
> specified.
>
> Section 4.1.3. , paragraph 2, discuss:
> >Intended Semantics: To give the throughput of a TCP congestion-
> >control conforming flow from the specified source to the specified
> >destination; see [RFC3649, Section 5.1 of RFC8312] on how TCP
> >throughput is estimated.  The spatial aggregation level is specified
> >in the query context (e.g., PID to PID, or endpoint to endpoint).
>
> A TCP bandwidth estimate can only be meaningfully be derived for bulk TCP
> transfers under a set of pretty strict and simplistic assumptions, making
> this
> metric a meaningless at best and misleading at worst, given that the
> source of
> this information doesn't know what workload, congestion controller and
> network
> conditions the user of this information will use or see.
>
> Also, RFC3649 is an Experimental RFC (from 2003!) and RFC8312 is an
> Informational RFC. Since this document normatively refers to them, it
> needs to
> cite them, and this will cause DOWNREFs for PS document. I would argue that
> at least RFC3649 is certainly not an appropriate DOWNREF.
>
> Why define this metric at all? The material you point to is the usual
> model-based throughput calculation based on RTT and loss rates; a client
> that
> intended to predict TCP performance could simply query ALTO for this and
> perform
> their own computation, which will likely be more accurate, since the
> client will
> hopefully know which congestion controller they will use for the given
> workload,
> and what the characteristics of that workload are.
>
>
> --
> COMMENT:
> --
>
> Section 1. , paragraph 6, comment:
> >The purpose of this document is to ensure proper usage of the
> >performance metrics defined in Table 1; it does not claim novelty of
> >the metrics.  The "Origin Example" column of Table 1 gives an example
> >RFC that has defined each metric.
>
> I don't understand what the purpose of the "origin example" column is.
> Most of
> these point to IPPM metrics, which have a pretty clear and
> 

Re: [alto] Éric Vyncke's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

[Martin Duke]

Good catch!

I'm not sure that either of these references are actually directly relevant
to the subject, though I'm happy to be convinced otherwise.

It might be that one of the IPPM docs (RFC 8337?) might be a better fit.

If RFC 8312 is the right answer, 8312bis is almost done and they can simply
update to avoid the downref.

Martin

On Mon, Nov 22, 2021 at 7:54 AM Eric Vyncke (evyncke) 
wrote:

> Martin,
>
>
>
> The text in § 4.1.3 says:
>
>Intended Semantics: To give the throughput of a TCP congestion-
>
>control conforming flow from the specified source to the specified
>
>destination; see [RFC3649, Section 5.1 of RFC8312
> <https://datatracker.ietf.org/doc/html/rfc8312#section-5.1>] on how TCP
>
>throughput is estimated.  The spatial aggregation level is specified
>
>in the query context (e.g., PID to PID, or endpoint to endpoint).
>
>
>
> So, it is RFC 8312 in the text, RFC 8312 is vaguely related to TCP
> bandwidth
>
>
>
> -éric
>
>
>
> *From: *Martin Duke 
> *Date: *Monday, 22 November 2021 at 16:40
> *To: *Eric Vyncke 
> *Cc: *The IESG , alto-chairs , "
> draft-ietf-alto-performance-metr...@ietf.org" <
> draft-ietf-alto-performance-metr...@ietf.org>, IETF ALTO ,
> Jan Seedorf 
> *Subject: *Re: Éric Vyncke's Discuss on
> draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)
>
>
>
> Thanks Eric,
>
>
>
> I think you mean RFC 8321? I am in the early stages of AD sponsoring a
> draft to update that to PS. The authors have the choice of doing a downref
> or referring to 8321bis and being stuck in the RFCEd queue for a few extra
> months.
>
>
>
> On Mon, Nov 22, 2021 at 3:32 AM Éric Vyncke via Datatracker <
> nore...@ietf.org> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-alto-performance-metrics-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work put into this document. Please bear with my lack of
> knowledge about ALTO in general.
>
> Please find below one trivial blocking DISCUSS points (probably easy to
> address), some non-blocking COMMENT points (but replies would be
> appreciated
> even if only for my own education), and some nits.
>
> Special thanks to Jan Seedorf for the shepherd's write-up about the WG
> consensus (even if not using the usual template).
>
> I have appreciated the "operational considerations" section as it addresses
> many questions that popped up during reading the document; notably, how
> can the
> ALTO server measure any metric between the ALTO client and a resource.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> -- Section 4.1.3 --
> A very trivial DISCUSS to fix: this document relies on RFC 8312 to specify
> how
> TCP throughput is estimated but RFC 8312 does not appear in the normative
> reference list (this will probably generate a down ref though).
>
>
> --
> COMMENT:
> --
>
> == COMMENTS ==
>
> Minor regret about the examples as they are all about the IPv4 address
> family
> especially in a world of happy eyeballs where the IPv4 and IPv6 paths may
> still
> have different performance metrics.
>
> -- Section 2.1 --
> Should the figure 1 use "perf monitoring tools" rather than "management
> tool" ?
>
> -- Section 4 --
> This section title is about 'bandwidth' but the first sub-section is about
> 'throughput', while these concepts are related they are also distinct. How
> can
> the reader reconciliate them ?
>
> -- Section 4.1 --
> Is the intent of ALTO to only work for TCP and not for other transport
> protocols ? I.e., is QUIC out of scope ?
>
> -- Section 4.2.3 --
> Where are those 'tunnels' in "by subtracting tunnel reservations " coming
> from
> ? Probably about RSVP-TE but what is the link with ALTO ? (Again I am not
> familiar with ALTO so this may be an uneducated question).
>
> == NITS ==
>
> -- Section 3.1.3 --
> Probably tedious to do but why not replacing "TBA" by the actual value in
> the
> examples for 'content-length' ?
>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Éric Vyncke's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

[Martin Duke]

Thanks Eric,

I think you mean RFC 8321? I am in the early stages of AD sponsoring a
draft to update that to PS. The authors have the choice of doing a downref
or referring to 8321bis and being stuck in the RFCEd queue for a few extra
months.

On Mon, Nov 22, 2021 at 3:32 AM Éric Vyncke via Datatracker <
nore...@ietf.org> wrote:

> Éric Vyncke has entered the following ballot position for
> draft-ietf-alto-performance-metrics-19: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/
>
>
>
> --
> DISCUSS:
> --
>
> Thank you for the work put into this document. Please bear with my lack of
> knowledge about ALTO in general.
>
> Please find below one trivial blocking DISCUSS points (probably easy to
> address), some non-blocking COMMENT points (but replies would be
> appreciated
> even if only for my own education), and some nits.
>
> Special thanks to Jan Seedorf for the shepherd's write-up about the WG
> consensus (even if not using the usual template).
>
> I have appreciated the "operational considerations" section as it addresses
> many questions that popped up during reading the document; notably, how
> can the
> ALTO server measure any metric between the ALTO client and a resource.
>
> I hope that this helps to improve the document,
>
> Regards,
>
> -éric
>
> == DISCUSS ==
>
> -- Section 4.1.3 --
> A very trivial DISCUSS to fix: this document relies on RFC 8312 to specify
> how
> TCP throughput is estimated but RFC 8312 does not appear in the normative
> reference list (this will probably generate a down ref though).
>
>
> --
> COMMENT:
> --
>
> == COMMENTS ==
>
> Minor regret about the examples as they are all about the IPv4 address
> family
> especially in a world of happy eyeballs where the IPv4 and IPv6 paths may
> still
> have different performance metrics.
>
> -- Section 2.1 --
> Should the figure 1 use "perf monitoring tools" rather than "management
> tool" ?
>
> -- Section 4 --
> This section title is about 'bandwidth' but the first sub-section is about
> 'throughput', while these concepts are related they are also distinct. How
> can
> the reader reconciliate them ?
>
> -- Section 4.1 --
> Is the intent of ALTO to only work for TCP and not for other transport
> protocols ? I.e., is QUIC out of scope ?
>
> -- Section 4.2.3 --
> Where are those 'tunnels' in "by subtracting tunnel reservations " coming
> from
> ? Probably about RSVP-TE but what is the link with ALTO ? (Again I am not
> familiar with ALTO so this may be an uneducated question).
>
> == NITS ==
>
> -- Section 3.1.3 --
> Probably tedious to do but why not replacing "TBA" by the actual value in
> the
> examples for 'content-length' ?
>
>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] PANRG questions

[Martin Duke]

Hello ALTO,

Please have a look at this paper in the PANRG about open research questions
in path aware networking.

https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/

In some ways this document is orthogonal to ALTO, but in others (notably
2.1 and 2.2) ALTO has at least attempted to provide a complete answer.

As I've said before, a lot of proposals for future extensions to ALTO could
usefully get vetted in PANRG while we complete the items in our current
charter.

Thanks,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] CERN?

[Martin Duke]

I've read that ALTO is used for some large data transfers at CERN. Does
anyone have a contact there that can talk about this? We're trying to do
some promotional material for IETF, and it would be a good testimonial.

Thanks,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Designated Experts

[Martin Duke]

Never mind, this is IETF review, so there is no DE needed.

On Tue, Oct 26, 2021 at 12:18 PM Martin Duke 
wrote:

> Kai, does this work for you?
>
> Any other nominations?
>
> On Mon, Oct 25, 2021 at 10:57 PM Qin Wu  wrote:
>
>> Hi, Martin:
>>
>> I suggest Kai, as the primary, I can be the backup.
>>
>>
>>
>> -Qin
>>
>> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Martin Duke
>> *发送时间:* 2021年10月26日 8:43
>> *收件人:* IETF ALTO 
>> *主题:* [alto] Designated Experts
>>
>>
>>
>> Who will be the designated experts for the ALTO Cost Source Registry in
>> ietf-alto-performance-metrics?
>>
>>
>>
>> Once I have a couple of volunteers, this can go to IESG evaluation.
>>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Designated Experts

[Martin Duke]

Kai, does this work for you?

Any other nominations?

On Mon, Oct 25, 2021 at 10:57 PM Qin Wu  wrote:

> Hi, Martin:
>
> I suggest Kai, as the primary, I can be the backup.
>
>
>
> -Qin
>
> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Martin Duke
> *发送时间:* 2021年10月26日 8:43
> *收件人:* IETF ALTO 
> *主题:* [alto] Designated Experts
>
>
>
> Who will be the designated experts for the ALTO Cost Source Registry in
> ietf-alto-performance-metrics?
>
>
>
> Once I have a couple of volunteers, this can go to IESG evaluation.
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Designated Experts

[Martin Duke]

Who will be the designated experts for the ALTO Cost Source Registry in
ietf-alto-performance-metrics?

Once I have a couple of volunteers, this can go to IESG evaluation.
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Zaheduzzaman Sarker's No Objection on charter-ietf-alto-04-01: (with COMMENT)

[Martin Duke]

Hi Zahed,

The original use case for ALTO -- peer to peer -- is largely dead. The
current charter's work supports the new CDN Interconnect use case.

It is too early to see how this affects adoption of ALTO, and I'm not
convinced we understand the current level of ALTO adoption.

So, this charter focuses on closing loose ends on the existing ALTO work
while we mature our understanding of the demand of for further extensions.

Martin

On Thu, Aug 26, 2021 at 5:31 AM Zaheduzzaman Sarker via Datatracker <
nore...@ietf.org> wrote:

> Zaheduzzaman Sarker has entered the following ballot position for
> charter-ietf-alto-04-01: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-alto/
>
>
>
> --
> COMMENT:
> --
>
> I see a need for protocol maintenance and potential extensions based on the
> deployment experience.
>
> However, for future protocol usage I don't think there is a need to a
> working
> group. This actually even puts doubts about potential direction that the
> working group will take, hence not a deterministic focus or item that the
> working group can deliver on. I mean to say, the future discussions can be
> separated and might result in - ALTO is not a good fit for the future
> usages.
>
> Also, as far as I understand ALTO uses the HTTP semantics hence the h2/h3
> adoption seems like a implementation choice on the ALTO server. Should
> there
> any issues on that adoption, that should be covered in the maintenance and
> extension bullet based on current deployment.
>
> Having said that, I wont block this rechartering but would suggest to
> rethink
> about the focuses set on the charter.
>
>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Éric Vyncke's No Objection on charter-ietf-alto-04-01: (with COMMENT)

[Martin Duke]

Hi Eric, I've edited the charter to reflect your concerns.

On Thu, Aug 26, 2021 at 5:48 AM Qin Wu  wrote:

> Thanks Eric, see comments inline below.
> -邮件原件-
> >发件人: Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
> >发送时间: 2021年8月26日 14:06
> >收件人: The IESG 
> >抄送: alto-cha...@ietf.org; alto@ietf.org
> >主题: Éric Vyncke's No Objection on charter-ietf-alto-04-01: (with COMMENT)
>
> >Éric Vyncke has entered the following ballot position for
> >charter-ietf-alto-04-01: No Objection
>
> >When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> >The document, along with other ballot positions, can be found here:
> >https://datatracker.ietf.org/doc/charter-ietf-alto/
>
>
>
> --
> >COMMENT:
> --
>
> >While I still wonder whether there is a need for a ALTO 'extension'
> working group, I do not object the rechartering.
> [Qin]: Yes, ALTO operational support doesn't require ALTO protocol
> extension, ALTO over HTTP3 needs to be investigated to see whether the
> protocol extension or just guidance is required?
> Even protocol extension is not needed, guidance on ALTO over HTTP2 or
> HTTP3 is still useful, e.g., how multiple stream carried in one connection
> can be leverage to support SSE.
> See section 4 of RFC8650
> "
> 4.  QoS Treatment
>
>Qos treatment for event streams is described in Section 2.3 of
>[RFC8639].  In addition, if HTTP/2 is used, the publisher MUST:
>
>*  Take the "weighting" leaf node in [RFC8639] and copy it into the
>   HTTP/2 stream weight, Section 5.3 of [RFC7540], and
>
>*  Take any existing subscription "dependency", as specified by the
>   "dependency" leaf node in [RFC8639], and use the HTTP/2 stream for
>   the parent subscription as the HTTP/2 stream dependency (as
>   described in Section 5.3.1 of [RFC7540]) of the dependent
>   subscription.
>
>*  Set the exclusive flag (Section 5.3.1 of [RFC7540]) to 0.
>
>For dynamic subscriptions with the same Differentiated Services Code
>Point (DSCP) value to a specific publisher, it is recommended that
>the subscriber sends all URI GET requests on a common HTTP/2 session
>(if HTTP/2 is used).  Conversely, a subscriber cannot use a common
>HTTP/2 session for subscriptions with different DSCP values.
> "
> As an example, HTTP 1.1 and HTTP 2.0 actually introduce different QoS
> treatment.
>
> >Nevertheless I am puzzled by the apparent conflict of a YANG model
> milestone and the sentence "This *may* include YANG models and OAM
> mechanisms"...
> [Qin]: Okay, will see how to fix it.
> >About the protocol extensions for  H/2 and H/3, does it imply the use of
> multistreaming ?
> [Qin]: I think some design guideline should be investigated, e.g.,
> multiple stream multiplexing is one feature that can be leveraged to
> enhance SSE, maybe there are other design principles here, e.g., ALTO over
> HTTP over QUIC features
> I will ask ALTO proponents to chime in to comment on this.
> >One minor nit: please introduce OAM at first use.
> [Qin]: Thanks.
>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] charter-ietf-alto-04-01

[Martin Duke]

Hi Lars,

I'm initiating a discussion about the value of the document deliverables in
the charter. Meanwhile, I've already edited the charter to be a little more
explicit why the routing WG activities are  called out in the text.

Thanks for your comments.

On Thu, Aug 26, 2021 at 7:46 AM Peng Liu  wrote:

> Hi all,
>
> Indeed, Amin's speech in sigcomm NAI 2021 inspired me a lot. I hope ALTO
> can be rechartered to cover more networking use cases, such as our
> computing aware networking use case and requirements. we really want to
> investigate how ALTO can be integrated into our work and serve as one of
> key components in our framework. Yes, we are looking for more help and
> input on this topic.
>
> Regards,
> Peng
>
> Peng Liu | 刘鹏
> China Mobile | 移动研究院
> mobile phone：13810146105
> email: * liupeng...@chinamobile.com *
>
>
> *From:* Y. Richard Yang 
> *Date:* 2021-08-24 22:42
> *To:* Lars Eggert 
> *CC:* IETF ALTO ; alto-cha...@ietf.org; Qin Wu
> ; The IESG 
> *Subject:* Re: [alto] charter-ietf-alto-04-01
> Hi Lars,
>
> I saw your comment and have to chime in.
>
> I have to respectfully disagree with your assessment: "Overall, I remain
> unconvinced that there is sufficient work/interest in this space to warrant
> a chartered WG." I am not sure if you attended the NAI@SIGCOMM'21
> Workshop yesterday. There was clearly a huge interest and work in the
> space. The title of Amin Vahdat's talk is "Application-Defined Networking",
> as "It now opens the next wave of opportunities toward Application-Defined
> Networking, Where application efficiency metrics drive network control
> configuration policy, Integration into compute and storage infrastructure→
> job placement, replication, Visibility into distributed systems structure,
> including Load Balancing, Thread Scheduling, RPCs, RDMA, and Collectives",
> using the sentences from the keynote. Now, let's go more specific to ALTO
> and to engineering. The work of Flow Director, in the scope of ALTO, was
> reported in CoNEXT'19 (https://gsmaragd.github.io/publications/CoNEXT2019/).
> Luis mentioned ongoing deployment efforts at Telefonica; there is the
> on-going deployment of ALTO at the Greater Bay Network, which is a large,
> among the most-advanced networks covering Shenzhen, Hong Kong; there is the
> ongoing MoWIE work, based on and the need to extend ALTO, by China Mobile
> and Tencent...  I agree that ALTO is far far far from taking over the
> world, but I have a totally different assessment.
>
> If when you say that there is not sufficient work, you mean that *the
> charter* does not include sufficient work. This is by design and good
> guidance: the WG substantially limits the scope of the recharter to
> consolidate the WG in the short term, and there was a huge disappointment
> from many industry parties on the removing of their work from the charter
> discussions---not sure if you attended some of the recharter discussions,
> there was a large amount of proposed work but they were mostly removed.
>
> Please see below.
>
> On Tue, Aug 24, 2021 at 9:29 AM Lars Eggert  wrote:
>
>> Hi,
>>
>> On 2021-8-24, at 16:07, Qin Wu  wrote:
>> > Thank you for reviewing the proposed re-charter of the ALTO working
>> group.
>>
>> > > It's not clear to me why this effort would need a chartered WG vs.
>> just a
>> > > mailing list and/or a wiki.
>>
>
>  A chartered WG has many benefits. As one example, multiple participants
> spend huge efforts on the ALTO work and bring "human resources" to IETF; an
> informal mailing list/wiki will be harder to justify the efforts. I assume
> that many IETF WGs can also operate mostly as a mailing list/wiki; then the
> participation can be lower, it will be harder to maintain scope, to meet
> deadlines. We feel that the WG recharter has wonderful guidance to be
> focused, to be timely.
>
>>
>> > >> o Develop operational support tools for ALTO.
>> > >
>>
>
> See above.
>
>
>> > > I'm not aware of any larger-scale product deployments of ALTO - do
>> some exists?
>>
>
> See some examples above.
>
> > > Otherwise, I question whether operational tools can effectively be
>> developed
>> > > without relevant operational experience.
>
>
>> > There is big suggestion that the reason for no larger-scale product
>> deployment of ALTO is because missing operational support tools.
>> > It is big mistake to make protocol without operational support.
>> > We saw this happen many times with OAM added much later. It make the
>> protocol hard to use and is bad for operator.
>>
>> Would you point me at a discussion where this lack of operational support
>> was brought up by a potential large-scale deployer as a reason to not
>> deploy ALTO?
>>
>>
> The issue of lacking operational support was not proposed by academics,
> but by people from the operator sides, during ALTO meetings, e..g., by Lyle
> Bertz (T-Mobile), Luis (Telefonica). The main complexity discussed by the
> Steering Giants report was mostly operational.
>
> > >> o Support for modern 

Re: [alto] Benjamin Kaduk's No Objection on charter-ietf-alto-04-01: (with COMMENT)

[Martin Duke]

HI Ben,

I edited the H/2 and 3 bullet to read as follows:
o Support for modern transport protocols. ALTO only uses the capabilities
of HTTP version 1. While ALTO can operate successfully over any version of
HTTP, it would benefit from leveraging HTTP/2 and HTTP/3 capabilities such
as push. The WG will produce an ALTO extension that leverages these
capabilities if they can be shown to improve performance.

It more accurately states the current status.

On Thu, Aug 26, 2021 at 6:34 AM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> charter-ietf-alto-04-01: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-alto/
>
>
>
> --
> COMMENT:
> --
>
> o Support for modern transport protocols. ALTO only uses the
> capabilities of HTTP version 1. Since then, the IETF has developed
> HTTP/2 and HTTP/3.  The working group will develop any necessary
> protocol extensions and guidance to support the use of ALTO over HTTP/2
> and HTTP/3.
>
> The IESG is reviewing on this same telechat a "bis" version of BCP56,
> guidelines for applications using HTTP.  Let's discuss whether this
> language is consistent with the guidance contained therein, which
> includes:
>
>[...] Requiring a particular
>version of HTTP makes it difficult to use in these situations, and
>harms interoperability.  Therefore, it is NOT RECOMMENDED that
>applications using HTTP specify a minimum version of HTTP to be used.
>
>However, if an application's deployment would benefit from the use of
>a particular version of HTTP (for example, HTTP/2's multiplexing),
>this ought be noted.
>
> My understanding is that typically it suffices to "just use HTTP", and
> that there should be no need for ALTO extensions to support running the
> protocol over HTTP/2 or HTTP/3.  Any HTTP-version-specific work would
> then be about making more effective use of features that are available
> in those later versions, without requiring them to be available, or
> perhaps (hopefully not) fixing issues with the original ALTO specification
> that caused it to not be HTTP-version-agnostic.
>
>
>
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.txt

[Martin Duke]

Hi Sabine,

Minor comments that aren't blocking last call:

(7) Eliminate the commas around "for the Client"

(8.3) Isn't " The client wants all properties values on all the entities,"
the use case for the (unfiltered) property map?

(8.3) s/Sever/Server

On Thu, Aug 12, 2021 at 8:38 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hello Martin and ALTO WG,
>
> Thanks again Martin for your thorough review and discussions that allowed
> to improve the document and enrich the capabilities of this extension.
>
> This new version addresses the comments in the AD review and is available
> at
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-18
> You may check the diffs here
> https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-18
>
> The main updates:
> - remove unused and unclear terms and clarifies text in many places,
> - Filtered Property Map (FPM) queries now allow empty lists of entities
> and properties. Empty lists are interpreted as representing the full set of
> entities and properties.
> - put tables and text in coherency in IANA sections 12.2 and 12.3. Though
> due to lack of space, only added a column "mapping to ALTO address type" in
> Table 2.  Some text on the security issue item referring to relevant
> sections was added in the introduction of section 12.2 and 12.3
>
> The key updates were added in section 8 "Filtered Property Map". (FPM)
> They address the question on: how a Client can obtain the list of
> entityIDs that can be used as input to a FPM without having to download a
> full property map. The FPM query input format and response have been
> updated accordingly.
> - In Section 8: a paragraph explains why this is useful for a Client
> - In section 8.3 Accept Input Parameters: the format of query object
> ReqFilteredPropertyMap is revised and explained to support this. The
> property member is optional.
> - In section 8.6 Filtered Property Map Response:
> --- an error case is added when input member "entities" is absent
> --- text explains how, when the "property" member is absent in the query,
> the Server returns an empty value for the queried entities.
>
> We hope the updates are meeting the review expectations.
> Thanks,
> Sabine and authors
>
> >-Original Message-
> >From: alto  On Behalf Of internet-dra...@ietf.org
> >Sent: Thursday, August 12, 2021 4:45 PM
> >To: i-d-annou...@ietf.org
> >Cc: alto@ietf.org
> >Subject: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.txt
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >This draft is a work item of the Application-Layer Traffic Optimization
> WG of
> >the IETF.
> >
> >Title   : ALTO Extension: Entity Property Maps
> >Authors : Wendy Roome
> >  Sabine Randriamasy
> >  Y. Richard Yang
> >  Jingxuan Jensen Zhang
> >  Kai Gao
> >   Filename: draft-ietf-alto-unified-props-new-18.txt
> >   Pages   : 60
> >   Date: 2021-08-12
> >
> >Abstract:
> >   This document extends the base Application-Layer Traffic Optimization
> >   (ALTO) Protocol by generalizing the concept of "endpoint properties"
> >   to entities defined by a wide set of objects, instead of only IP
> >   addresses.  Further, these properties are presented as maps, similar
> >   to the network and cost maps in the base ALTO protocol.  The protocol
> >   is extended in two major directions.  First, from endpoints
> >   restricted to IP addresses to entities covering a wider and
> >   extensible set of objects; second, from properties on specific
> >   endpoints to entire entity property maps.  These extensions introduce
> >   additional features allowing entities and property values to be
> >   specific to a given information resource.  This is made possible by a
> >   generic and flexible design of entity and property types.
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
> >
> >There is also an htmlized version available at:
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-18
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-18
> >
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >
> >___
> >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
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] New wikipedia page

[Martin Duke]

This reply makes me realize I may have created confusion with my last email.

The new charter calls for the WG to track certain things, like known
deployments, on a Wiki. This is *not* meant to imply wikipedia; in fact,
this is probably too much information for that.  Instead, it's probably
best to use trac (https://trac.ietf.org/trac/alto/wiki) for internal WG
tracking, though I'm not going to dictate which tool the WG uses.

The wikipedia page I created is totally orthogonal to the new charter. It's
something I created while reviewing the current batch of documents. As with
any other page on Wikipedia, anyone is invited to edit it, but this has
nothing to do with charter deliverables.

Thanks
Martin

On Tue, Jul 6, 2021 at 11:54 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hello Martin,
>
>
>
> Great thanks for this initiative, the page is very informative, synthetic
> and pleasant to read. With the ALTO WG contributors, we will be more than
> happy to update it. Before doing so, if you think it makes sense, we plan
> to draft the potential additions on a wiki page, to ensure WG consensus and
> approval from the WG chairs and AD. We will proceed with collaborative
> editing and use the datatracker facilities. And indeed, we aim at keeping
> it concise and focused on mature work.
>
> Best regards,
>
> Sabine
>
>
>
> *From:* alto  *On Behalf Of *Martin Duke
> *Sent:* Friday, July 2, 2021 8:46 PM
> *To:* IETF ALTO 
> *Subject:* [alto] New wikipedia page
>
>
>
> Hello ALTO,
>
>
>
> When reviewing ALTO documents I find myself constantly re-reading large
> sections of RFC 7285. To stop repeating this step, I cleaned up my notes
> and made a Wikipedia page.
>
>
>
> https://en.wikipedia.org/wiki/ALTO_(protocol)
>
>
>
> While I think it's a mistake to put immature internet drafts on the wiki
> page, please feel free to improve the page, while keeping it relatively
> concise.
>
>
>
> Thanks
>
> Martin
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Martin Duke]

This has been in "Revised I-D needed" for 95 days. Is there an issue I
should be aware of, or will I see a revision soon?

On Wed, Jun 9, 2021 at 5:36 AM Qin Wu  wrote:

> Hi, Richard and Martin:
>
>
>
> *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Martin Duke
> *发送时间:* 2021年5月4日 2:01
> *收件人:* Y. Richard Yang 
> *抄送:* Brian Trammell ; IETF ALTO 
> *主题:* Re: [alto] AD review of draft-ietf-alto-performance-metrics-15
>
>
>
> Hi Richard,
>
>
>
> Replies inline.
>
>
>
> On Thu, Apr 8, 2021 at 1:04 PM Y. Richard Yang  wrote:
>
> If the intent is that it be machine-readable, then there are several
> places where this standard is going to need more standardization (i.e.
> precise definition of text fields).
>
>
>
> Some of the authors discussed the issue and feel that going down the path
> of making the content machine-readable, in a systematic way, adds
> substantial complexity.
>
>
>
> OK, let's just make the intent clear in the draft.
>
>
>
> .
>
> But zooming out: I understand that the point is that "the client knows
> more about the context," which is pretty much what 5.1 says. But I don't
> understand if the "client" is the user or a user agent, and what either one
> would actually do with the information. Would the application execute a
> policy based on the source? Why would it use a latency that came from an
> sla, but not from measurement? etc.
>
>
>
> This is a good comment. Here is an example (
> https://ipnetwork.bgtmo.ip.att.net/pws/averages.html) that motivated some
> early discussions. In this example, AT post both target (aka sla. should
> we change the name from sla to service-level-target?) and actual
> measurements. In this sense, ALTO can be considered as a standard way of
> providing and update the information. Both target and actual values can be
> useful. Make sense?
>
>
>
> So this use case is about allowing users to query performance metrics for
> consumption by humans, rather than by automated clients trying to pick a
> server? This seems like a lot of machinery for that purpose, but if this is
> important to the WG than OK. Let's just write down how this context info
> can be used, if this is the strongest use case.
>
>
>
> [Qin] I think operators may need to monitor the performance where there is 
> SLA and proactively detect when the service is degrading. The regulators are 
> also interested in monitoring the performance of broadband service and 
> compare performance between ISPs or between different countries. All of these 
> use cases have been documented in RFC7536 which performance metric draft 
> could reference.
>
>
>
>
>
>
>
>
>
> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
> this refer to an SLA the ALTO client has with the network? Between the
> target IP and the network? Or something else? If the first, does this link
> to client authentication in some way? If the second, what are the privacy
> implications of exposing these SLAs?
>
>
>
> It is target IP and the network. Here is some text in the current version
> on the authentication and privacy aspects (Sec. 6):
> "Indeed, TE
>
>performance is a highly sensitive ISP information; therefore, sharing
>TE metric values in numerical mode requires full mutual confidence
>between the entities managing the ALTO server and the ALTO client.
>ALTO servers will most likely distribute numerical TE performance to
>ALTO clients under strict and formal mutual trust agreements.  On the
>other hand, ALTO clients must be cognizant on the risks attached to
>such information that they would have acquired outside formal
>conditions of mutual trust."
>
>
>
> Will this be OK?
>
>
>
> That privacy information is alright, but exposing the details of
> third-party SLAs deserves special attention.
>
>
> Yes.
>
>
>
> But to follow up your answer: if the client has a better SLA than the
> target, this won't show up in the metrics at all?
>
>
>
> Now I see that I need to clarify. The metric is end-to-end, from src IP to
> dst (target) IP. Does this clarify? I can add a sentence to clarify this.
>
>
>
> Yes, that clarifies it. It also spurs my first followup question: does
> this link to client authentication in some way, or can anyone impersonate a
> client to get its SLA?
>
> [Qin]: I agree with Martin we should prevent Excess disclosure of the ALTO 
> service provider's data to the unauthorized client or third party,RFC7285 
> defines protection strategy in the security section to address these risks 
> such as adopt HTTP Dig

[alto] New wikipedia page

[Martin Duke]

Hello ALTO,

When reviewing ALTO documents I find myself constantly re-reading large
sections of RFC 7285. To stop repeating this step, I cleaned up my notes
and made a Wikipedia page.

https://en.wikipedia.org/wiki/ALTO_(protocol)

While I think it's a mistake to put immature internet drafts on the wiki
page, please feel free to improve the page, while keeping it relatively
concise.

Thanks
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] WG Review: ALTO Charter Update(Internet mail)

[Martin Duke]

Chunshan,

Thanks for your input. I support Qin's comments.

I will also say that exploring these sorts of possibilities are the domain
of the IRTF -- the IETF works where organizations are ready to deploy an
architecture and just need the details to be worked out.

ALTO is *not* the working group for all application/network communication
-- it is the working group to develop and maintain an HTTP-based protocol
to acquire long-lived network parameters. PANRG exists to tackle research
questions in the broader space, where the community doesn't believe there
is a fully formed consensus on how to fix the big problems.

If 3GPP won't send a Liaison Statement, that tells me they are not yet
convinced that ALTO is a solution to their problem. This tells me that
there needs to be a proof of concept and/or some experiments to convince
the industry*. *After that persuasion has happened, it is a good time to
consider major standards activity.

On Thu, May 13, 2021 at 6:58 AM chunshxiong(熊春山) 
wrote:

> Hello Qin,
>
> Thanks for the feedback!
>
>
> Regarding to the recharter proposal, we attended the discussion quite long 
> time (though quite a lot are not the WG level but within design team).  The 
> bullet you referenced indeed in our view is just for information and may not 
> end up with a WG document.  So this is indeed not our expectation:-)
>
>
> o Report back to the Area Director to identify any use cases that have strong 
> support and a realistic chance of implementation and deployment.
>
>
> So, regarding to your proposal to spit into different documents, thanks for 
> the proposal but we will evaluate and discuss within design team and decide 
> whether to continue.
>
>
> Meanwhile, for coordination between 3GPP and IETF, indeed there is official 
> LSes always between these two SDOs, but the LS normally is based on the 
> progress on standards work related to each other. The ongoing 3GPP R-18 new 
> study/work item selection sees great interest in ( interactive) application 
> network coordination for different kinds of companies. If IETF ALTO does not 
> continue to study the new protocol to support the new services, even if 3GPP 
> sends LS to IETF, we may not be able to address it properly.
>
> In 3GPP Rel-17, 44 companies from global area support advanced interactive 
> services related work ranked as high priority topic during work item 
> prioritization.   From a service provider perspective, it is also very clear 
> to us how important it is to optimize the user experiences for such important 
> and popular scenarios like cloud gaming etc.  It is really a pity that some 
> of the interested companies may not come to IETF but it really doesn’t mean 
> such use case are not dominant.  In future we can consider to ask more 
> companies to come to IETF or ask their 3GPP team to align with IETF team:-)  
> Regarding to new wheels, we think there is very clear spit/boundary between 
> 3GPP and IETF thus such cases can probably be avoided easily.  Anyway, this 
> is something in the future and we can come to IETF when proper.
>
>
> So, again thanks for Qin’s response and we do hope ALTO  is actually 
> addressing how state-of -the-art dominating application and network can 
> coordinate to improve user experiences.
>
> Thanks a lot!
>
> BRs,
>
>
>
> Chunshan Xiong
>
>
>
> *From:* Qin Wu 
> *Sent:* Wednesday, May 12, 2021 8:14 PM
> *To:* chunshxiong(熊春山) ; IETF ALTO  >
> *Cc:* alto-cha...@ietf.org; Zaheduzzaman Sarker <
> zaheduzzaman.sar...@ericsson.com>
> *Subject:* RE: [alto] WG Review: ALTO Charter Update(Internet mail)
>
>
>
> Thanks Chunshan for your input and comments on charter proposal, see reply
> inline.
>
> *发件人:* chunshxiong(熊春山) [mailto:chunshxi...@tencent.com
> ]
> *发送时间:* 2021年5月11日 16:40
> *收件人:* Qin Wu ; IETF ALTO 
> *抄送:* alto-cha...@ietf.org; Zaheduzzaman Sarker <
> zaheduzzaman.sar...@ericsson.com>
> *主题:* RE: [alto] WG Review: ALTO Charter Update(Internet mail)
>
>
>
> Hello WuQin and working group,
>
>
>
> I provide our views on this recharter.
>
>
>
> Firstly, we think ALTO is an IETF WG to standardize the interaction
> between application and network, initially for P2P application and now it
> is a good chance to continue optimization to support these new interactive
> services like Cloud Gaming, XR/AR, V2X application etc.
>
> [Qin]: I agree to support further evolving of ALTO protocol.
>
> To support new application and introduce further optimization for ALTO
> protocol, we need to get more implementation deployment and experience to
> help us better understand which piece works, which pieces not needed, which
> pieces need to be redesigned. ALTO protocol is initial designed for P2P,
> later on CDN application, it is generic protocol, Do we have P2P specific
> features that need to peel off? To get this question answer, we propose the
> first work item and the second item and will create wiki page to keep track
> of related concern/issues/report
>
>
>
> Secondly, we have been 

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Martin Duke]

Hi Richard,

Replies inline.

On Thu, Apr 8, 2021 at 1:04 PM Y. Richard Yang  wrote:

> If the intent is that it be machine-readable, then there are several
>> places where this standard is going to need more standardization (i.e.
>> precise definition of text fields).
>>
>
> Some of the authors discussed the issue and feel that going down the path
> of making the content machine-readable, in a systematic way, adds
> substantial complexity.
>

OK, let's just make the intent clear in the draft.


> .
>
>> But zooming out: I understand that the point is that "the client knows
>> more about the context," which is pretty much what 5.1 says. But I don't
>> understand if the "client" is the user or a user agent, and what either one
>> would actually do with the information. Would the application execute a
>> policy based on the source? Why would it use a latency that came from an
>> sla, but not from measurement? etc.
>>
>
> This is a good comment. Here is an example (
> https://ipnetwork.bgtmo.ip.att.net/pws/averages.html) that motivated some
> early discussions. In this example, AT post both target (aka sla. should
> we change the name from sla to service-level-target?) and actual
> measurements. In this sense, ALTO can be considered as a standard way of
> providing and update the information. Both target and actual values can be
> useful. Make sense?
>

So this use case is about allowing users to query performance metrics for
consumption by humans, rather than by automated clients trying to pick a
server? This seems like a lot of machinery for that purpose, but if this is
important to the WG than OK. Let's just write down how this context info
can be used, if this is the strongest use case.


>
>>
>>
>>>
 - Sec 2.1 I am confused about the meaning of the "sla" cost-source.
 Does this refer to an SLA the ALTO client has with the network? Between the
 target IP and the network? Or something else? If the first, does this link
 to client authentication in some way? If the second, what are the privacy
 implications of exposing these SLAs?

>>>
>>> It is target IP and the network. Here is some text in the current
>>> version
>>> on the authentication and privacy aspects (Sec. 6):
>>> "Indeed, TE
>>>performance is a highly sensitive ISP information; therefore, sharing
>>>TE metric values in numerical mode requires full mutual confidence
>>>between the entities managing the ALTO server and the ALTO client.
>>>ALTO servers will most likely distribute numerical TE performance to
>>>ALTO clients under strict and formal mutual trust agreements.  On the
>>>other hand, ALTO clients must be cognizant on the risks attached to
>>>such information that they would have acquired outside formal
>>>conditions of mutual trust."
>>>
>>> Will this be OK?
>>>
>>
>> That privacy information is alright, but exposing the details of
>> third-party SLAs deserves special attention.
>>
>
> Yes.
>
>
>> But to follow up your answer: if the client has a better SLA than the
>> target, this won't show up in the metrics at all?
>>
>
> Now I see that I need to clarify. The metric is end-to-end, from src IP to
> dst (target) IP. Does this clarify? I can add a sentence to clarify this.
>

Yes, that clarifies it. It also spurs my first followup question: does this
link to client authentication in some way, or can anyone impersonate a
client to get its SLA?


>
>
>>
>>
>>>
>>> - Sec 2.1. Related to the above, the text suggests that any cost-source
 expressed as "import" could also be expressed as "estimation". Why would
 the server do this? The text should say, or perhaps it would be
 conceptually cleaner if "estimation" and "import" were mutually exclusive
 sources by definition.

>>>
>>> In the early WG discussion, they were considered separate, and then the
>>> agreement was that import is a special case of estimation, with more
>>> specific dependency tracking. Consider data provenance of how the ALTO data
>>> are computed. Estimation means that the server does not want to indicate
>>> the specific details, and the important gives a precise indication of the
>>> exact protocols.
>>>
>>
>> OK, I now understand that "import" implies a specific set of parameters.
>> I can't understand what value this distinction has, but that just circles
>> around to me not understanding the cost-source information at all.
>>
>>
>
> I see. Let me try to clarify slightly differently. import means that the
> ALTO server can provide a precise source of information using specific
> parameters, and estimate is that it comes from a black-box (the server does
> not reveal). Thinking about it a bit more, we can go down the path of
> specifying a precise format (rfc/section just as ippm) when specifying
> import. Will this be a direction that you want to go?
>

I don't have a strong opinion on the outcome, except that it is strongly
motivated by a use case and have semantics consistent with that use 

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Martin Duke]

Hi Richard,

Where needed, responses inline.

On Fri, Apr 2, 2021 at 6:18 PM Y. Richard Yang  wrote:

> - Sec 2.1. The cost-source model is conceptually sound, but the
>> justification for it seems underexplained. What exactly is a client going
>> to do with this information? What different behaviors would a client
>> execute if the context was e.g. "sla" instead of "nominal?" To the extent
>> the parameters are not machine readable, like links to webpages, are we
>> really expecting this information to be presented to the humans behind ALTO
>> clients?
>>
>
> Good comment. This is a point which the WG indeed discussed multiple
> times. The decision was that providing the source will give the server the
> ability to indicate the source, and the client knows more about the
> context. Some operational aspects are discussed in Sec. 5.1. There were
> some discussions on potential normative specifications on the client-side
> and/or the server-side, but the final decision is that ALTO provides
> non-normative information. For example, the basic cost values are
> non-normative, and only best-effort information. There can be out-of-ALTO
> control loops, for example, business contracts, and the cost-source
> supports indication of such information channel.
>
> The comment on clarifying whether the info will be for humans behind is a
> great one. One use case setting discussed is that the link can provide
> machine-readable specifications such as a machine-readable language
> specifying the measurement parameters, but this is considered out of scope.
> Will you recommend that we include more some more elaboration in the
> operational considerations section (i.e., extending Sec. 5.1)?
>

If it were me, I'd put some of it in the intro and some motivation in 2.1,
and maybe go through some miscellaneous considerations in 5. But that's
less important that it be there somewhere.

If the intent is that it be machine-readable, then there are several places
where this standard is going to need more standardization (i.e. precise
definition of text fields).

But zooming out: I understand that the point is that "the client knows more
about the context," which is pretty much what 5.1 says. But I don't
understand if the "client" is the user or a user agent, and what either one
would actually do with the information. Would the application execute a
policy based on the source? Why would it use a latency that came from an
sla, but not from measurement? etc.



>
>> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
>> this refer to an SLA the ALTO client has with the network? Between the
>> target IP and the network? Or something else? If the first, does this link
>> to client authentication in some way? If the second, what are the privacy
>> implications of exposing these SLAs?
>>
>
> It is target IP and the network. Here is some text in the current version
> on the authentication and privacy aspects (Sec. 6):
> "Indeed, TE
>performance is a highly sensitive ISP information; therefore, sharing
>TE metric values in numerical mode requires full mutual confidence
>between the entities managing the ALTO server and the ALTO client.
>ALTO servers will most likely distribute numerical TE performance to
>ALTO clients under strict and formal mutual trust agreements.  On the
>other hand, ALTO clients must be cognizant on the risks attached to
>such information that they would have acquired outside formal
>conditions of mutual trust."
>
> Will this be OK?
>

That privacy information is alright, but exposing the details of
third-party SLAs deserves special attention. But to follow up your answer:
if the client has a better SLA than the target, this won't show up in the
metrics at all?


>
> - Sec 2.1. Related to the above, the text suggests that any cost-source
>> expressed as "import" could also be expressed as "estimation". Why would
>> the server do this? The text should say, or perhaps it would be
>> conceptually cleaner if "estimation" and "import" were mutually exclusive
>> sources by definition.
>>
>
> In the early WG discussion, they were considered separate, and then the
> agreement was that import is a special case of estimation, with more
> specific dependency tracking. Consider data provenance of how the ALTO data
> are computed. Estimation means that the server does not want to indicate
> the specific details, and the important gives a precise indication of the
> exact protocols.
>

OK, I now understand that "import" implies a specific set of parameters. I
can't understand what value this distinction has, but that just circles
around to me not understanding the cost-source information at all.



> - Sec 5.4.1: "...the ALTO server may provide the client with the validity
> period of the exposed metric values."
>
> Shouldn't there be a standard format for this? Or are you implying the use
> of cost-calendar?
>

Good catch. The decision of the WG at the time was to use HTTP 

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Martin Duke]

Sorry for the fragmented review, but there are a couple of more issues:

- The authors should do a review of all lower-case occurrences of must,
should, may, and recommended. At least a few of them should be capitalized
to indicate normative requirements.

- IMO, from a quick review,  I-D.ietf-ippm-initial-registry as written is
normative and should be listed as such. However, I think it would be better
to simply refer to the actual registry (
https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml)
rather than tie it to the initial entries.


On Mon, Mar 29, 2021 at 5:30 PM Martin Duke  wrote:

> One small correction: I'm jumping the gun on the author policy; 6 is
> probably OK for now.
>
> On Mon, Mar 29, 2021 at 11:33 AM Martin Duke 
> wrote:
>
>> Hello authors,
>>
>> Thank you very much for writing this draft. It is clearly a useful
>> extension to ALTO and is quite clearly written, even to someone who is not
>> a practitioner. I have numerous comments/questions and a few nits.
>>
>> These points are all invitations to discussion, rather than commands
>> about what to change, as I've missed much of the WG deliberations that led
>> to this text.
>>
>> COMMENTS:
>> - There are six authors. Having more than 5 editors/authors listed on the
>> front page requires strong justification and chair/AD approval. See the RFC
>> Editor statement [1]. You are encouraged to designate a few editors for the
>> front page and list as many authors as desired at the end.
>>
>> - Sec 2.1. The cost-source model is conceptually sound, but the
>> justification for it seems underexplained. What exactly is a client going
>> to do with this information? What different behaviors would a client
>> execute if the context was e.g. "sla" instead of "nominal?" To the extent
>> the parameters are not machine readable, like links to webpages, are we
>> really expecting this information to be presented to the humans behind ALTO
>> clients?
>>
>> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
>> this refer to an SLA the ALTO client has with the network? Between the
>> target IP and the network? Or something else? If the first, does this link
>> to client authentication in some way? If the second, what are the privacy
>> implications of exposing these SLAs?
>>
>> - Sec 2.1. Related to the above, the text suggests that any cost-source
>> expressed as "import" could also be expressed as "estimation". Why would
>> the server do this? The text should say, or perhaps it would be
>> conceptually cleaner if "estimation" and "import" were mutually exclusive
>> sources by definition.
>>
>> - Sec 3. I would prefer it if the parameters field in each of these
>> definitions was a bit more strict. This relates to my confusion about
>> machine-readable vs. human readable data; if this is meant to be
>> machine-readable, then e.g. Sec 3.4.4 should be more specific in spelling
>> out that the IGP protocols should be in a format with the RFC number, for
>> instance. If it's to be human readable for a purpose I don't understand,
>> then these looser definitions are probably OK.
>>
>> - Sec 3.4 Unlike the other metrics, I have no idea what a client is to do
>> with the hop count metric, since clients don't care about hop count. Hops
>> only affect users through delay and loss rate, which is present in other
>> metrics. Is the intent here to provide a proxy for delay when direct delay
>> information is not available? If so, we should say so.
>>
>> - Sec 5.3. I suggest a reword.
>>
>> OLD:
>> To address this issue, the only defined "routingcost" metric can be
>>only "estimation".
>>
>> NEW:
>> To address this issue, if the "routingcost" metric contains a
>> cost-context field, it MUST be "estimation."
>>
>> What should clients do if it's not "estimation?" Can they use it or
>> reject the metric
>> as malformed?
>>
>> - Sec 5.4.1: "...the ALTO server may provide the client with the validity
>> period of the exposed metric values."
>>
>> Shouldn't there be a standard format for this? Or are you implying the
>> use of cost-calendar?
>>
>> - Sec 5.4.2: I don't understand what this section is saying. Can the
>> server provide new metrics not in the spec? Or is it saying that the server
>> can take singletons about link one-way delays and compose path one-way and
>> two-way delays, for example?
>>
>> NITS:
>> - S

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

[Martin Duke]

One small correction: I'm jumping the gun on the author policy; 6 is
probably OK for now.

On Mon, Mar 29, 2021 at 11:33 AM Martin Duke 
wrote:

> Hello authors,
>
> Thank you very much for writing this draft. It is clearly a useful
> extension to ALTO and is quite clearly written, even to someone who is not
> a practitioner. I have numerous comments/questions and a few nits.
>
> These points are all invitations to discussion, rather than commands about
> what to change, as I've missed much of the WG deliberations that led to
> this text.
>
> COMMENTS:
> - There are six authors. Having more than 5 editors/authors listed on the
> front page requires strong justification and chair/AD approval. See the RFC
> Editor statement [1]. You are encouraged to designate a few editors for the
> front page and list as many authors as desired at the end.
>
> - Sec 2.1. The cost-source model is conceptually sound, but the
> justification for it seems underexplained. What exactly is a client going
> to do with this information? What different behaviors would a client
> execute if the context was e.g. "sla" instead of "nominal?" To the extent
> the parameters are not machine readable, like links to webpages, are we
> really expecting this information to be presented to the humans behind ALTO
> clients?
>
> - Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
> this refer to an SLA the ALTO client has with the network? Between the
> target IP and the network? Or something else? If the first, does this link
> to client authentication in some way? If the second, what are the privacy
> implications of exposing these SLAs?
>
> - Sec 2.1. Related to the above, the text suggests that any cost-source
> expressed as "import" could also be expressed as "estimation". Why would
> the server do this? The text should say, or perhaps it would be
> conceptually cleaner if "estimation" and "import" were mutually exclusive
> sources by definition.
>
> - Sec 3. I would prefer it if the parameters field in each of these
> definitions was a bit more strict. This relates to my confusion about
> machine-readable vs. human readable data; if this is meant to be
> machine-readable, then e.g. Sec 3.4.4 should be more specific in spelling
> out that the IGP protocols should be in a format with the RFC number, for
> instance. If it's to be human readable for a purpose I don't understand,
> then these looser definitions are probably OK.
>
> - Sec 3.4 Unlike the other metrics, I have no idea what a client is to do
> with the hop count metric, since clients don't care about hop count. Hops
> only affect users through delay and loss rate, which is present in other
> metrics. Is the intent here to provide a proxy for delay when direct delay
> information is not available? If so, we should say so.
>
> - Sec 5.3. I suggest a reword.
>
> OLD:
> To address this issue, the only defined "routingcost" metric can be
>only "estimation".
>
> NEW:
> To address this issue, if the "routingcost" metric contains a cost-context
> field, it MUST be "estimation."
>
> What should clients do if it's not "estimation?" Can they use it or reject
> the metric
> as malformed?
>
> - Sec 5.4.1: "...the ALTO server may provide the client with the validity
> period of the exposed metric values."
>
> Shouldn't there be a standard format for this? Or are you implying the use
> of cost-calendar?
>
> - Sec 5.4.2: I don't understand what this section is saying. Can the
> server provide new metrics not in the spec? Or is it saying that the server
> can take singletons about link one-way delays and compose path one-way and
> two-way delays, for example?
>
> NITS:
> - Sec 1. An initial sentence introducing ALTO at the beginning would be
> helpful, e.g.
>
> "ALTO [RFC 7285] provides a means for client to identify the most
> efficient information source when multiple copies of such information
> exist, by quering path information from an HTTP server."
>
> - Sec 2. The second paragraph is a little hard to read. Suggestion:
>
> OLD:
>
> On the other hand, to be able to use coarse-grained information such
>as routing system information (e.g., [RFC8571 
> <https://datatracker.ietf.org/doc/html/rfc8571>]), which may not
>provide fine-grained information such as (iii) Method of Measurement
>or Calculation and (vi) Measurement Timing, this document provides
>context information to indicate the source of information and hence
>available metric details.
>
> NEW:
>
>   This document specifies context information to indicate t

[alto] AD review of draft-ietf-alto-performance-metrics-15

[Martin Duke]

Hello authors,

Thank you very much for writing this draft. It is clearly a useful
extension to ALTO and is quite clearly written, even to someone who is not
a practitioner. I have numerous comments/questions and a few nits.

These points are all invitations to discussion, rather than commands about
what to change, as I've missed much of the WG deliberations that led to
this text.

COMMENTS:
- There are six authors. Having more than 5 editors/authors listed on the
front page requires strong justification and chair/AD approval. See the RFC
Editor statement [1]. You are encouraged to designate a few editors for the
front page and list as many authors as desired at the end.

- Sec 2.1. The cost-source model is conceptually sound, but the
justification for it seems underexplained. What exactly is a client going
to do with this information? What different behaviors would a client
execute if the context was e.g. "sla" instead of "nominal?" To the extent
the parameters are not machine readable, like links to webpages, are we
really expecting this information to be presented to the humans behind ALTO
clients?

- Sec 2.1 I am confused about the meaning of the "sla" cost-source. Does
this refer to an SLA the ALTO client has with the network? Between the
target IP and the network? Or something else? If the first, does this link
to client authentication in some way? If the second, what are the privacy
implications of exposing these SLAs?

- Sec 2.1. Related to the above, the text suggests that any cost-source
expressed as "import" could also be expressed as "estimation". Why would
the server do this? The text should say, or perhaps it would be
conceptually cleaner if "estimation" and "import" were mutually exclusive
sources by definition.

- Sec 3. I would prefer it if the parameters field in each of these
definitions was a bit more strict. This relates to my confusion about
machine-readable vs. human readable data; if this is meant to be
machine-readable, then e.g. Sec 3.4.4 should be more specific in spelling
out that the IGP protocols should be in a format with the RFC number, for
instance. If it's to be human readable for a purpose I don't understand,
then these looser definitions are probably OK.

- Sec 3.4 Unlike the other metrics, I have no idea what a client is to do
with the hop count metric, since clients don't care about hop count. Hops
only affect users through delay and loss rate, which is present in other
metrics. Is the intent here to provide a proxy for delay when direct delay
information is not available? If so, we should say so.

- Sec 5.3. I suggest a reword.

OLD:
To address this issue, the only defined "routingcost" metric can be
   only "estimation".

NEW:
To address this issue, if the "routingcost" metric contains a cost-context
field, it MUST be "estimation."

What should clients do if it's not "estimation?" Can they use it or reject
the metric
as malformed?

- Sec 5.4.1: "...the ALTO server may provide the client with the validity
period of the exposed metric values."

Shouldn't there be a standard format for this? Or are you implying the use
of cost-calendar?

- Sec 5.4.2: I don't understand what this section is saying. Can the server
provide new metrics not in the spec? Or is it saying that the server can
take singletons about link one-way delays and compose path one-way and
two-way delays, for example?

NITS:
- Sec 1. An initial sentence introducing ALTO at the beginning would be
helpful, e.g.

"ALTO [RFC 7285] provides a means for client to identify the most efficient
information source when multiple copies of such information exist, by
quering path information from an HTTP server."

- Sec 2. The second paragraph is a little hard to read. Suggestion:

OLD:

On the other hand, to be able to use coarse-grained information such
   as routing system information (e.g., [RFC8571
]), which may not
   provide fine-grained information such as (iii) Method of Measurement
   or Calculation and (vi) Measurement Timing, this document provides
   context information to indicate the source of information and hence
   available metric details.

NEW:

  This document specifies context information to indicate the metric
source, which can allow clients to obtain fine-grained information like
(ii) Method of Measurement or Calculation and (vi) Measurement Timing."

- Sec 2.1 In Fig. 1, please expand "NBI" on first use.

- Sec 3.1.3 Expand "PID" on first use.

- Sec 3.1.4 s/recommended/RECOMMENDED

- Sec 3.4 s/metric hopcount/hopcount metric

- Sec 4.1.3 would this be correct: s/give the throughput/give the maximum
throughput

- Sec 6. s/is a highly sensitive/is highly sensitive

Thanks
Martin

[1] https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Please mention deployments in the charter

[Martin Duke]

Thanks to some feedback I got on announcing this recharter exercise, I
think it would be helpful to have the (second?) paragraph of the charter to
explain how ALTO has been deployed in the internet. It doesn't need to
mention a bunch of companies, or describe every deployment out there, but
it would help to say "this has seen wide deployment in ..." and "there is
demand for extensions" or something of that nature.

Thanks
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ALTO Testimonials

[Martin Duke]

Hello ALTO,

IETF is looking to publicize the work of the transport area a little more
to the media. In particular, we'd like to highlight how recent work in
Working Groups like ALTO have a made a difference in industry, government,
and society.

If any of you work for organizations that could tell a story on how the
ALTO standards have improved your enterprise, please email me (do not reply
all). I imagine there might be a short written testimonial, and possibly a
video interview in 2021.

This could be a relatively junior engineer or someone like your CTO.

Thanks,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Welcome Qin Wu

[Martin Duke]

Hello ALTO,

I'm pleased to welcome Qin Wu as the newest working group chair, effective
immediately. Qin is and active participant in ALTO and an experienced chair.

We will have three chairs at IETF 109. Shortly afterwards, one of the
current chairs will step down. As we complete the current milestones, I
will appoint a second chair to free both Jan and Vijay to move on to other
things.

See you next week,
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Seeking a new ALTO chair

[Martin Duke]

Hi ALTO,

This is a reminder to get in touch with me by October 20th if you're
interested in being the ALTO chair.

Thanks,
Martin

On Wed, Sep 30, 2020 at 9:43 AM Martin Duke  wrote:

> Hello ALTO,
>
> As you all know, we are approaching completion of the milestones for the
> working group, and starting discussion of a new charter. Vijay and Jan will
> step down when these milestones are complete, after years of diligent
> service to the IETF and the working group. Thanks Vijay and Jan!
>
> I would like there to be a third chair at IETF 109 as a transitional step,
> to allow at least one of them to exit soon after the meeting. I believe it
> is appropriate for at least one of the future chairs to come from the ALTO
> community, and have no objection to both doing so.
>
> While I don't expect the next chairs to meet of all of the requirements
> below, an ideal candidate would:
> - intend to serve at least 2 years in the position;
> - plan to attend IETF meetings in person, whenever that starts happening
> again;
> - understand how to run a meeting and motivate volunteers from diverse
> backgrounds;
> - exercise good judgment about document progress, consensus, etc.;
> - have basic understanding of the technology and use cases under
> development;
> - constructively manage conflict when it arises; and
> - not expect to constantly recuse themselves due to authorship of most or
> all of the documents under consideration.
>
> The bureaucratic workflow management is really not hard, and I encourage
> people to apply even if they don't know all of the buttons in datatracker,
> etc.
>
> Chairing is a way to serve the community and identify yourself as a leader
> in a small piece of the future internet. I try hard to also make it fun and
> not especially time consuming.
>
> *If you're interested in being a chair, or have questions about the
> position, please email me privately and we can arrange a chat. I'm sure
> Vijay or Jan would also be happy to answer questions. I would hope to
> identify a chair by early November.*
>
> Thanks for your consideration!
>
> Regards,
> Martin Duke
> Responsible Area Director
>
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Seeking a new ALTO chair

[Martin Duke]

Hello ALTO,

As you all know, we are approaching completion of the milestones for the
working group, and starting discussion of a new charter. Vijay and Jan will
step down when these milestones are complete, after years of diligent
service to the IETF and the working group. Thanks Vijay and Jan!

I would like there to be a third chair at IETF 109 as a transitional step,
to allow at least one of them to exit soon after the meeting. I believe it
is appropriate for at least one of the future chairs to come from the ALTO
community, and have no objection to both doing so.

While I don't expect the next chairs to meet of all of the requirements
below, an ideal candidate would:
- intend to serve at least 2 years in the position;
- plan to attend IETF meetings in person, whenever that starts happening
again;
- understand how to run a meeting and motivate volunteers from diverse
backgrounds;
- exercise good judgment about document progress, consensus, etc.;
- have basic understanding of the technology and use cases under
development;
- constructively manage conflict when it arises; and
- not expect to constantly recuse themselves due to authorship of most or
all of the documents under consideration.

The bureaucratic workflow management is really not hard, and I encourage
people to apply even if they don't know all of the buttons in datatracker,
etc.

Chairing is a way to serve the community and identify yourself as a leader
in a small piece of the future internet. I try hard to also make it fun and
not especially time consuming.

*If you're interested in being a chair, or have questions about the
position, please email me privately and we can arrange a chat. I'm sure
Vijay or Jan would also be happy to answer questions. I would hope to
identify a chair by early November.*

Thanks for your consideration!

Regards,
Martin Duke
Responsible Area Director
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Comment on draft-ietf-alto-performance-metric-09

[Martin Duke]

This is not a full review. I'm late to this and I apologize if I'm covering
ground which has been fully resolved before. With all hats off...

It has come up in the working group before that some of the cost metrics
can vary quite a lot over time, much more quickly than the scale at which
ALTO would update them.

Have we considered changing the metrics to have more long-lived properties
while still being useful? For example
1. we could split the various delay metrics into min and max versions. Min
and Max delay should be relatively constant over a given topology. Max
delay maps quite nicely to something like an SLA.
2. packet loss -- can we focus this on link layer losses rather than queue
drops? Most simply, this could just be a boolean that says "this path
frequently has losses not related to congestion" but could also be expanded
into a link packet error rate, if valuable. Congestion based losses are of
course dependent on the application.

Thanks
Martin
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ALTO Interim in lieu of IETF 107

[Martin Duke]

I have no conflicts with any of these times, but #0 and #1 are pretty
brutal for Pacific Time.

On Fri, Mar 13, 2020 at 10:59 AM Vijay Gurbani 
wrote:

> All: The IESG has been working on coming up with a virtual interim
> schedule for WGs that would have met in Vancouver.  As the original
> schedule avoided WG and RG conflicts to the maximum extent possible, the
> virtual interim schedule has been created so that working groups and
> research groups can be reasonably sure that most participants will not have
> a conflict with another IETF interim meeting on the same day.
>
> For ALTO, IESG has suggested Tue, Apr 21.  We will plan to hold a virtual
> interim on that day.  While we can decide another day besides the IESG
> suggested one, I would hesitate to do so for a variety of reasons, the most
> important of which is that we will have to ensure that our chosen day does
> not conflict with other WGs, BoFs, and RGs, that WG list members may be
> interested in.  Thus, it seems safe to stay with the IESG suggested date of
> Apr 21, as that date has honored all of the WG/RG conflicts with ALTO.
>
> What we need to do soon (48 hours or so) is to agree on a specific time
> for Apr 21 so Jan and I can set the wheels in motion to schedule the
> virtual interim on Apr 21.
>
> Here are the options, please reply with your preferred option on the
> list.  Jan and I will collect all of the responses we receive by Sunday
> night, and choose the one that is most frequent by Mon AM.  I know Europe
> has not yet changed their clocks, so I will leave the times below in US
> Central time zone (which is now on daylight savings time).  So please
> adjust accordingly for your locale.  All times are for Apr 21, 2020.
>
> 0. 5:00am - 7:00am US Central
> 1. 7:00am - 9:00am US Central
> 2. 9:00am - 11:00am US Central
> 3. 11:00am - 1:00pm US Central
> 4. 1:00pm - 3:00pm US Central
> 5. 3:00pm - 5:00pm US Central
> 6. 5:00pm - 7:00 pm US central *
> 7. 7:00pm - 9:00pm US central *
> 8. 9:00pm - 11:00pm US Central  *
>
> * I will not be able to make these timeslots as they overlap with the
> class I teach.
>
> Thank you,
>
> - vijay
> ___
> 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