[alto] Secdir last call review of draft-ietf-alto-cost-calendar-17
Reviewer: Brian Weis Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines the ALTO Cost Calendar, an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. Currently, the ALTO cost information service provides applications with guidance about current costs of a desired resource, but not for resources with a cost that changes dramatically over time. The ALTO Cost Calendar allows for specifying costs for varying time periods in the future. The extensions in this document are to the existing network flows, with policy defined in JSON. As such, additional security considerations are few. The well-written Security Considerations document does define a few considerations that come from announcing events that are expected to happen in the future. I have only one suggestion for additional text. The second paragraph on page 27 (draft -17) describes risks of a client using the calendaring information for their own selfish purposes. The suggested mitigation in the next paragraph is to limit the information “being leaked to malicious clients or third parties“ by authenticating clients with TLS. This strategy may thwart “third parties”, but it will not help in the case of “malicious clients” possessing valid credentials to authenticate. The threat here might be legitimate clients that have become subverted by an attacker and are now ‘bots’ being asked to participate in a DDoS attack. The calendar information would be valuable information for when to persecute a DDoS attack, and this should be noted here. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] WGLC over for CDNI
Dear Vijay, all, The authors have taken a pass of the document to address the reviews. Links to the new version are below. We believe that we have addressed all of the items in the two review sets by Danny and Sanjay. Thank you so much! Richard, = The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-10 https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-10 On Mon, Feb 24, 2020 at 11:14 AM Vijay Gurbani wrote: > All: The WGLC [1] for the ALTO CDNI draft is now over. The draft received > two reviews [2,3] during the WGLC period. The authors are requested to > prepare a revision based on the reviews. The draft can move ahead once the > revision is submitted. > > [1] > https://mailarchive.ietf.org/arch/msg/cdni/gjpYSELvH2SprFSoBCD2QbrlU00/ > [2] > https://mailarchive.ietf.org/arch/msg/cdni/-gaZKrUBnC43RyMOeaf_MtdiLa8/ > [3] > https://mailarchive.ietf.org/arch/msg/cdni/keqftt-bvNZQZxHQBSADlJVkIg8/ > > Thanks, > > - vijay > ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] I-D Action: draft-ietf-alto-cdni-request-routing-alto-10.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 : Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO Authors : Jan Seedorf Y.R. Yang Kevin J. Ma Jon Peterson Jingxuan Jensen Zhang Filename: draft-ietf-alto-cdni-request-routing-alto-10.txt Pages : 38 Date: 2020-02-24 Abstract: The Content Delivery Networks Interconnection (CDNI) framework [RFC6707] defines a set of protocols to interconnect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One component that is needed to achieve the goal of CDNI described in [RFC7336] is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI). [RFC8008] defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. This document defines an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol, following the guidelines defined in [RFC8008]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-10 https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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] Mirja Kühlewind's Yes on draft-ietf-alto-cost-calendar-17: (with COMMENT)
Mirja Kühlewind has entered the following ballot position for draft-ietf-alto-cost-calendar-17: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ -- COMMENT: -- This is a returning item as initially an IPR declaration what missed to take over from the initial draft (as raised in Alvaro's discuss). Therefore we re-ran both wg last call as well as IETF last call. This version also addresses all review comments from the last IESG evaluation and hopefully should now be ready to go! Update: Latest version now also addresses the OPSDIR review from the last IETF last call. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Opsdir last call review of draft-ietf-alto-cost-calendar-16
Thank you so much, Jürgen! The WG decision is to use a single unit and hence to allow scaling below the chosen unit, we have to deal with float. As much as we thought 1 second is typically the smallest, from my understanding, some use cases from a major app developer is already below this. We will revise the sentences to be reasonable and check with you to finalize say by Wednesday the latest. Thanks again, Richard On Mon, Feb 24, 2020 at 4:55 AM Schönwälder, Jürgen < j.schoenwael...@jacobs-university.de> wrote: > I will remove all closed issues and comment further inline. > > On Fri, Feb 21, 2020 at 03:54:30PM -0500, Y. Richard Yang wrote: > > > > > > - Since you write "SHOULD at least IEEE 754 double-precision > floating > > > > > point", does this not make the IEEE 754 reference a normative > > > > > reference? > > > > > > > > > > > > - [[SR]] The text follows RFC7285, section 11.3.2.3, in which > IEEE > > > 754 > > > > is an informative reference and cited with a SHOULD. > > > > > > > > > > On second thought, I wonder whether you really want to mandate how a > > > value is 'stored'. Perhaps you wanted to require 'SHOULD use at least > > > support IEEE 754 double-precision floating point [IEEE.754.2008] > > > precision'. > > > > > > Note that several lines up you suggested to change to integer, but I > > > am not sure you wanted that - please double check that you get this > > > right. Anyway, since you refer to properties of a concrete formats > > > defined in another document, it seems to me the reference is actually > > > normative. > > > > > > > > > In general, I find the double precision requirement a bit irritating > > > given the large range of numbers doubles can represent (roughly from > > > 2.2x10^-308 to 1.8x10^308). And yet, many practically useful numbers > > > such as 0.1 can't be represented exactly as floating point numbers, > > > i.e., there is always rounding involved, making comparisons rather > > > complicated. > > > > > > Often people want to have doubles in the hope that this maximizes the > > > chances of not getting hit by rounding issues but the sad truth is that > > > floating point numbers remain dangerous. > > > > > > > > > > > Totally agree. It is interesting that you use the 0.1 second example. I > > assume that you have the classical Patriot 0.1 second rounding bug in > mind ( > > https://www.viva64.com/en/b/0445/), which is quite close to our setting, > > where 0.1 is their interval size, although I do not foresee that ALTO > cost > > calendar will be used in such a setting :-) > > > > I believe that the initial design used only integers, with a unit (s, ms, > > ns, ...) to avoid the floating-point issue (instead of 0.1 sec, it is 100 > > ms), and then the feedback and WG decision is to use generic floating > > points to have a more uniform, single unit (second) design. One proposal, > > which I am not sure others like, is to use a smaller unit, say ms, and > then > > most likely we will deal with only integers (in the range of [-(2**53)+1, > > (2**53)-1]) and can still handle smaller units should the setting arise.. > > The downside is that there might be more zeros if the interval is longer > > (60 sec -> 6 ms). What do you think? > > > > Another possibility is to keep the current design but add some text to > > discuss the precision issue. A Proposal is the following: > > > > "time-interval-size": > > > > * is the duration of an ALTO Calendar time interval in seconds. > > A "time-interval-size" value contains a JSONNumber. ALTO > > Servers SHOULD use at least IEEE 754 double-precision floating > > point [IEEE.754.2008] to store this value. Example values are: > > 300 , 7200, meaning that each Calendar value applies on a time > > interval that lasts 5 minutes and 2 hours, respectively. > > > > => > > > > "time-interval-size": > > > > * is the duration of an ALTO Calendar time interval in seconds. > > A "time-interval-size" value contains a JSONNumber. Example > > values > > are: 300 , 7200, meaning that each Calendar value applies on a > time > > interval that lasts 5 minutes and 2 hours, respectively. Since > the > > interval size can be smaller than 1 second (e.g., 100 ms), the > > value > > specified can also be a floating point (e.g., 0.1). Both ALTO > > clients and > > servers should be aware of potential issues caused by the > precision > > issues caused by using floating point numbers. For example, > > the server may have an internal, integer representation in ms, > and > > store > > 100 as an int (0.1 sec) in the local storage; the sever sends > "0.1" > > as > > the interval size to the client; the client may use a > float/double > > to store > > the JSON number, which may not represent 0.1 precisely. To > improve > > interoperability, the server and the client SHOULD use IEEE
[alto] I-D Action: draft-ietf-alto-cost-calendar-17.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 Cost Calendar Authors : Sabine Randriamasy Richard Yang Qin Wu Lingli Deng Nico Schwan Filename: draft-ietf-alto-cost-calendar-17.txt Pages : 32 Date: 2020-02-23 Abstract: This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect, but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces ALTO Cost Calendar, with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-cost-calendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-alto-cost-calendar-17 https://datatracker.ietf.org/doc/html/draft-ietf-alto-cost-calendar-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cost-calendar-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. 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] WGLC over for CDNI
All: The WGLC [1] for the ALTO CDNI draft is now over. The draft received two reviews [2,3] during the WGLC period. The authors are requested to prepare a revision based on the reviews. The draft can move ahead once the revision is submitted. [1] https://mailarchive.ietf.org/arch/msg/cdni/gjpYSELvH2SprFSoBCD2QbrlU00/ [2] https://mailarchive.ietf.org/arch/msg/cdni/-gaZKrUBnC43RyMOeaf_MtdiLa8/ [3] https://mailarchive.ietf.org/arch/msg/cdni/keqftt-bvNZQZxHQBSADlJVkIg8/ Thanks, - vijay ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Large Scale Networking (LSN) Workshop on Huge Data: A Computing, Networking and Distributed Systems Perspective
Dear ALTOers, Although we are a working group, not a research group, this workshop is still highly relevant: https://protocols.netlab.uky.edu/~hugedata2020// The white paper by some of us, with alto as a core component, has just been accepted by this workshop. If you have an interest in working together in applying alto to this context, please let us know. Thanks, Richard -- Richard ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Opsdir last call review of draft-ietf-alto-cost-calendar-16
I will remove all closed issues and comment further inline. On Fri, Feb 21, 2020 at 03:54:30PM -0500, Y. Richard Yang wrote: > > > > - Since you write "SHOULD at least IEEE 754 double-precision floating > > > > point", does this not make the IEEE 754 reference a normative > > > > reference? > > > > > > > > > - [[SR]] The text follows RFC7285, section 11.3.2.3, in which IEEE > > 754 > > > is an informative reference and cited with a SHOULD. > > > > > > > On second thought, I wonder whether you really want to mandate how a > > value is 'stored'. Perhaps you wanted to require 'SHOULD use at least > > support IEEE 754 double-precision floating point [IEEE.754.2008] > > precision'. > > > > Note that several lines up you suggested to change to integer, but I > > am not sure you wanted that - please double check that you get this > > right. Anyway, since you refer to properties of a concrete formats > > defined in another document, it seems to me the reference is actually > > normative. > > > > > > In general, I find the double precision requirement a bit irritating > > given the large range of numbers doubles can represent (roughly from > > 2.2x10^-308 to 1.8x10^308). And yet, many practically useful numbers > > such as 0.1 can't be represented exactly as floating point numbers, > > i.e., there is always rounding involved, making comparisons rather > > complicated. > > > > Often people want to have doubles in the hope that this maximizes the > > chances of not getting hit by rounding issues but the sad truth is that > > floating point numbers remain dangerous. > > > > > > > Totally agree. It is interesting that you use the 0.1 second example. I > assume that you have the classical Patriot 0.1 second rounding bug in mind ( > https://www.viva64.com/en/b/0445/), which is quite close to our setting, > where 0.1 is their interval size, although I do not foresee that ALTO cost > calendar will be used in such a setting :-) > > I believe that the initial design used only integers, with a unit (s, ms, > ns, ...) to avoid the floating-point issue (instead of 0.1 sec, it is 100 > ms), and then the feedback and WG decision is to use generic floating > points to have a more uniform, single unit (second) design. One proposal, > which I am not sure others like, is to use a smaller unit, say ms, and then > most likely we will deal with only integers (in the range of [-(2**53)+1, > (2**53)-1]) and can still handle smaller units should the setting arise. > The downside is that there might be more zeros if the interval is longer > (60 sec -> 6 ms). What do you think? > > Another possibility is to keep the current design but add some text to > discuss the precision issue. A Proposal is the following: > > "time-interval-size": > > * is the duration of an ALTO Calendar time interval in seconds. > A "time-interval-size" value contains a JSONNumber. ALTO > Servers SHOULD use at least IEEE 754 double-precision floating > point [IEEE.754.2008] to store this value. Example values are: > 300 , 7200, meaning that each Calendar value applies on a time > interval that lasts 5 minutes and 2 hours, respectively. > > => > > "time-interval-size": > > * is the duration of an ALTO Calendar time interval in seconds. > A "time-interval-size" value contains a JSONNumber. Example > values > are: 300 , 7200, meaning that each Calendar value applies on a time > interval that lasts 5 minutes and 2 hours, respectively. Since the > interval size can be smaller than 1 second (e.g., 100 ms), the > value > specified can also be a floating point (e.g., 0.1). Both ALTO > clients and > servers should be aware of potential issues caused by the precision > issues caused by using floating point numbers. For example, > the server may have an internal, integer representation in ms, and > store > 100 as an int (0.1 sec) in the local storage; the sever sends "0.1" > as > the interval size to the client; the client may use a float/double > to store > the JSON number, which may not represent 0.1 precisely. To improve > interoperability, the server and the client SHOULD use IEEE 754 > double-precision floating point [IEEE.754.2008] to store this > value, in unit >of seconds. > > I am a bit ambivalent of the last sentence though. This is something the WG has to discuss and decide. If the WG can find agreement that there is a smallest sensible unit (e.g., milliseconds or microseconds), then I personally would find it reasonable to implement this specification by storing values in an integral type of this smallest sensible unit internally (if the WG does not want to use integral numbers of that type). Hence, for me personally, a statement how implementations SHOULD store values goes too far as this is an implementation concern. /js -- Juergen Schoenwaelder
