Re: [alto] [Last-Call] Genart last call review of draft-ietf-alto-cost-mode-02

[Lars Eggert]

Roni, thank you for your review. I have entered a No Objection ballot for this 
document.

Lars


> On 2022-5-7, at 14:38, Roni Even via Datatracker  wrote:
> 
> Reviewer: Roni Even
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-alto-cost-mode-??
> Reviewer: Roni Even
> Review Date: 2022-05-07
> IETF LC End Date: 2022-05-13
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is ready for publication as a standard track RFC
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> 
> --
> last-call mailing list
> last-c...@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call



signature.asc
Description: Message signed with OpenPGP
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Lars Eggert's No Objection on draft-ietf-alto-cost-mode-03: (with COMMENT)

[Lars Eggert via Datatracker]

Lars Eggert has entered the following ballot position for
draft-ietf-alto-cost-mode-03: 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.)


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/



--
COMMENT:
--

# GEN AD review of draft-ietf-alto-cost-mode-03

CC @larseggert

Thanks to Roni Even for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/xlaIzXHKY1NzjJRJpuXpzKwP4rc).

## Comments

### Section 1, paragraph 4
```
 Additional cost modes are required for specific ALTO deployment cases
 (e.g., [I-D.ietf-alto-path-vector]).  In order to allow for such use
 cases, this document relaxes the constraint imposed by the base ALTO
 specification on allowed cost modes (Section 3) and creates a new
 ALTO registry to track new cost modes (Section 4).
```
I second Rob's DISCUSS, i.e., it's not clear at all that current ALTO
implementations will handle this protocol parameter now taking on
values other than "numerical" or "ordinal" without explicit
negotiation.

I will let Rob hold the DISCUSS, but will monitor the discussion to
see if this issue will be addressed.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool



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

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

[Lars Eggert via Datatracker]

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 narrowly-defined area
of applicability. Since ALTO isn't performing IPPM-style network testing, it's
not clear why IPPM metrics are referenced here?

Section 2.2. , paragraph 23, comment:
>If a cost metric string does not have the optional statical operator
>string, the statistical operator SHOULD be interpreted as the default
>statical operator in the definition of the base metric.  If the

What is a "statical" operator; I am not familiar with the term and it doesn't
seem to appear in other RFCs? (Also occurs elsewhere in this document.)

Section 3.1.4. , paragraph 4, comment:
>link statistics.  Another example of a source to estimate the delay
>is the IPPM framework [RFC2330].  It is RECOMMENDED that the

IPPM defines measurement metrics. How would they be a source for estimates?

Section 3.3. , paragraph 1, comment:
> 3.3.  Cost Metric: Delay Variation (delay-variation)

Is this supposed to apply to the one-way or bidirectional delay? Also, delay
variation is not independent from path utilization (c.f. bufferbloat), so why is
it being reported independently?

Section 3.5. , paragraph 1, comment:
> 3.5.  Cost Metric: Loss Rate (lossrate)

What is this metri

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

[Lars Eggert]

Hi,

On 2021-8-24, at 16:07, Qin Wu  wrote:
> Thank you for reviewing the proposed re-charter of the ALTO working group.
> Obviously your opinions are very important as a Transport expert, but it is 
> disappointing that you have made such a strong objection so late in the 
> process and after the IESG decided that re-chartering was OK and sent the 
> charter out for external review.

I provided some comments to Martin directly some weeks ago, but I was unable to 
comment during the internal review due to vacation time. That said, it is fully 
appropriate for ADs to also raise comments during external review.

> > It's not clear to me why this effort would need a chartered WG vs. just a
> > mailing list and/or a wiki.
...
> The important difference is whether the IETF retains control of an IETF 
> protocol.

That is not actually a factor. The IETF retains change control over all 
protocols and other work it originates, even if the WG that did so has closed. 
The IETF is not relinquishing change control when it closes WGs.

> >> o Perform protocol maintenance for the existing published protocol.
> >
> > The default WG for protocol maintenance for TSV-area WGs that close is 
> > TSVWG.
> > Any such maintenance could hence be handled there.
> 
> It is true that this is one job for TSVWG.
> We would be worried that ALTO people and drafts would hide other work in TSVWG
> TSVWG meet for 2 hours at IETF-111. ALTO meet for 1 hour. Is that good 
> balance?

It depends on how much maintenance work you think would be needed. The only 
item I see expressed is support for H2 and H3.

> >> o Develop operational support tools for ALTO.
> >
> > I'm not aware of any larger-scale product deployments of ALTO - do some 
> > exists?
> > 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?

> >> 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.
> >
> > This seems to fall under the "protocol maintenance" bullet above, so I'm not
> > clear why this is a separate bullet. As stated above, this could be done in
> > TSVWG if anyone cared.
> 
> All work on a protocol after first RFC is “protocol maintenance”. We could 
> write charter as single bullet “Do protocol maintenance” but that is not 
> helpful to guide participants and make AD manage WG.

I'll note that the charter actually does contain a bullet to "perform protocol 
maintenance", which is why I pointed out the overlap?

> Also, this is big and important next step to make ALTO more relevant and 
> useable in current Internet.

What particular features of H2 and H3 would make ALTO more relevant and 
deployable in the current Internet? H2 or H3 do not obsolete H1.

> > "HTTP ", paragraph 1, comment:
> >> o Future use cases. The working group will provide a forum to discuss 
> >> possible
> >> future use cases.
> >
> > This discussion can be done on a mailing list without the need for a 
> > chartered
> > WG.
> 
> Yes, everything (even QUIC) can be done on mailing list without need for a WG.

Actually, no. Specifications cannot (easily) be published without a WG. 
Discussions, on the other hand, can be had.

> This item was added to draft charter after discussion with AD. The purpose is 
> to scope this short term re-charter – if WG cannot show meaningful future use 
> cases then there is no long future for WG.

Noted.

Thanks,
Lars




signature.asc
Description: Message signed with OpenPGP
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] How Data Center Virtualization influence ALTO mechanism.

[Lars Eggert]

Hi,

On 2010-10-9, at 10:18, Y.J. GU wrote:
 In Data Center operation, one basic consensus is 'When Virtual Machines move 
 from one site to another, the IP Addresses will not change, so that the 
 existing service connection will not be broken'.

inside one data center, sure. Maybe even across data centers, with PI space and 
a coordinated route update. But I don't think that'd common practice.

  VMs can migrate to arbitrary site, not under the control and knowledge of 
 ISP. For example, some VMs in Data Center A(IP subnet 198.1.1.0) move to Data 
 Center B (IP subnet 210.1.1.0).

Huh? Didn't you just say above that the IP addresses wouldn't change?

 IP-based, Vms are closer to DC-A. Physically, these VMs are much closer to 
 hosts in DC-B. However things are not so easy, especially considering how 
 these VMs are routed. Current ALTO may give wrong cost ranking.

If you're moving VMs around in the topology, you'll have to update the 
announced ALTO information as you do that. 

But since ALTO merely provide(s) applications with information to perform 
better-than-random initial peer selection - a direct quote from the charter - 
inaccurate or incorrect ALTO information is not catastrophic anyway.

Lars

smime.p7s
Description: S/MIME cryptographic signature
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Proposal for ALTO re-charter

[Lars Eggert]

Hi,

On 2010-6-23, at 10:56, wangaijun wrote:
 From previous discussion, we can know the Server Notification Mechanism(SNM) 
 is important for the communication efficiency between ALTO Server and ALTO 
 Client. It is very similar to the “Traffic Guidance System”,in which the 
 traffic control department will broadcast the real traffic information 
 actively to guide the car to avoid the congested road, or notify the driver 
 that some area are in “traffic control”, in order to assure the performance 
 of some high priority traffic.

I won't comment on whether your SNM is similar to traffic management systems or 
not.

However, I will note that the charter says:

  The Working Group will design and specify an Application-Layer Traffic
  Optimization (ALTO) service that will provide applications with
  information to perform better-than-random initial peer selection.

And that's it.

End systems are already being informed about network congestion. The 
notifications come via packet losses or ECN marks. Due to being transmitted 
in-band, they are as timely as possible, and provide direct feedback about the 
resource load along the data path. This already gives application all the 
information they need to decide whether they want to prefer one peer over 
another.

In other words, ALTO is providing hints to a P2P app about which peers it may 
want to try first. Because ALTO is a control-plane mechanism and not coupled to 
the data plane, the information that is useful to exchange via ALTO needs to be 
stable and accurate over timescales that are orders of magnitude longer than 
RTTs.

Using again different words: You won't know what the actual path capacity or 
congestion to a peer is unless you start transmitting along the path.

Lars



smime.p7s
Description: S/MIME cryptographic signature
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Proposal for ALTO re-charter

[Lars Eggert]

Hi,

On 2010-6-24, at 12:28, wangaijun wrote:
 The ip address allocation map can be coarser or finer, and get the different
 p2p localization effect. The ISP may adjust this allocation map, to give the
 p2p clients more or less hint according to the network condition. In this
 situation, it is useful for ISP to have SNM to notify the ALTO information
 customer.
 
 This is just one example, there are other examples for ISP want to notify
 the changed network condition timely, via SNM. With SNM, the cooperation
 between ISP and p2p/CDN based application developer can be more active, more
 reciprocal.   

why? ALTO focuses on the *initial* peer selection. When a client joins a swarm, 
it fetches the current ALTO information, and incorporates that into its peer 
decision algorithm. Done.

Nothing in the design assumes that a client will need to continuously remain 
connected to the ALTO server (or even that the client queries the ALTO server 
at all.) If a client for whatever reason needs the most recent ALTO 
information, it can simply reconnect to the server. No notification mechanism 
is needed. An ALTO server is a purely passive information storage.

(That said, we can certainly discuss extending the ALTO architecture in the 
future, but I at least would like to see actual *deployment* of the simple 
current mechanism, so that we fix limitations of the current design that have 
been demonstrated through *actual deployment experience*. Which we don't have 
yet.)

Lars

smime.p7s
Description: S/MIME cryptographic signature
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] ***SPAM*** 14.182 (5) 答复: Is it possible to incorporate server notification mechanism int o current ALTO protocol

[Lars Eggert]

Hi,

On 2010-5-21, at 4:05, wangaijun wrote:
 We have submitted the updated version of our draft about notification
 mechanism at http://tools.ietf.org/id/draft-sun-alto-notification-02.txt,
 any comments are welcomed.

I find this proposal to be problematic. ALTO is not a signaling protocol, and 
extending it into a generic network-to-client notification mechanism is well 
beyond the chartered work. ALTO is meant to improve the initial peer selection.

add standard rant about using ALTO for congestion notification here

Lars

smime.p7s
Description: S/MIME cryptographic signature
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] 'Link capacity' in scope?

[Lars Eggert]

On 2009-6-3, at 21:14, Salman Abdul Baset wrote:
Your congestion example is spot on. Provisioned link capacity  
(upstream
and downstream) is not very helpful for peer selection unless the  
current

load on the link is considered.


Agreed, but I understood that that was the information you were trying  
to propose for ALTO.


As I mentioned to Enrico, spare capacity, computed from provisioned  
link

capacity and current load, can guide peer selection.


Even if you could do this computation (which is difficult enough,  
because traffic at the access router may arrive form multiple  
different nodes in the local network, not just the box the P2P client  
is running on), you still only get a potential upper bound. Whether  
you will actually be able to use all or even most of that computed  
spare capacity will entirely depend on whether the access link happens  
to be the bottleneck resource of the path to the peer you end up  
choosing.


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] 'Link capacity' in scope?

[Lars Eggert]

On 2009-6-4, at 10:20, Enrico Marocco wrote:
It seems reasonable to allow the ALTO protocol to carry, in addition  
to

topology and cost-related information, also other information like
minimum and perhaps estimated latency (I'll let others argue whether
both would be feasible or not) about the target networks/endpoints.


Given that with the current queueing schemes and buffer sizes in use,  
path latencies to a large degree are a function of the path load, I  
don't see how this would be too useful. The best you could get is  
again a lower bound latency if the path happened to not have standing  
queues.


Lars

smime.p7s
Description: S/MIME cryptographic signature
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto