Hi Ben, How are you doing?
We are wondering if you can take a look at the proposed changes of Path Vector and see whether they address the DISCUSS and COMMENT. Thanks a lot! Best, Kai > -----Original Messages----- > From: [email protected] > Sent Time: 2022-03-06 01:17:37 (Sunday) > To: "Benjamin Kaduk" <[email protected]> > Cc: [email protected], [email protected], [email protected], "The IESG" <[email protected]> > Subject: Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT) > > Hi Ben, > > We have just submitted a new revision of path vector. Please see the diff in [1]. > > [1] https://www.ietf.org/rfcdiff?url1=draft-ietf-alto-path-vector-22&url2=draft-ietf-alto-path-vector-23 > > There are two parts that are slightly different from the previously proposed text: > > Section 6.2.4: > > Old: > ... Meanwhile, for persistent ANEs whose entity > domain name has the format of "PROPMAP.ane" where PROPMAP is the name > (proposed to be replaced with "resource ID") ^^^^ > of a Property Map resource, PROPMAP is the defining resource of these > ANEs. > > New: > ... Meanwhile, for any persistent ANE whose defining > resource is a Property Map resource, its entity domain name MUST have > the format of "PROPMAP.ane" where PROPMAP is the resource ID of the > defining resource. > > > Section 11 > > Old: > For risk type (3), an ALTO server MUST use dynamic mappings from > ephemeral ANE names to underlying physical entities. Thus, ANE names > contained in the Path Vector responses to different clients or even > for different request from the same client SHOULD point to different > physical entities. > > New: > For risk type (3), an ALTO service provider must be aware that > persistent ANEs may be used as "landmarks" in collaborative > inferences. Thus, they should only be used when exposing public > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > service access points (e.g., API gateways, CDNi) and/or when the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > granularity is coarse-grained (e.g., when an ANE represents an AS, a > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > data center or a WAN). Otherwise, an ALTO server MUST use dynamic > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (New sentence added to the proposed text) > mappings from ephemeral ANE names to underlying physical entities. > Specifically, for the same physical entity, an ALTO server SHOULD > assign a different ephemeral ANE name when the entity appears in the > responses to different clients or even for different request from the > same client. A RECOMMENDED assignment strategy is to generate ANE > names from random numbers. > > Please let us know whether the proposed change is OK. Suggestions and feedback are more than welcome! > > Thanks! > > Best, > Kai > > -----Original Messages----- > From:[email protected] > Sent Time:2022-03-05 10:21:53 (Saturday) > To: "Benjamin Kaduk" <[email protected]> > Cc: [email protected], [email protected], "The IESG" <[email protected]>, [email protected] > Subject: Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT) > > Hi Ben, Martin and Qin, > > Thanks for the feedback and suggestions. Please see our responses inline. > > Best, > Kai > > > > -----Original Messages----- > > From: "Benjamin Kaduk" <[email protected]> > > Sent Time: 2022-03-05 07:31:51 (Saturday) > > To: [email protected] > > Cc: "The IESG" <[email protected]>, [email protected], [email protected], [email protected] > > Subject: Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT) > > > > Hi Kai, > > > > Also inline... > > > > On Fri, Mar 04, 2022 at 01:51:07AM +0800, [email protected] 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" <[email protected]> > > > > Sent Time: 2022-03-03 17:53:16 (Thursday) > > > > To: "The IESG" <[email protected]> > > > > Cc: [email protected], [email protected], [email protected] > > > > 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. > > > > [just noting that this has been covered downthread already] > > Yes. We will reference the PS draft. > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > Thanks for fleshing out the security considerations section substantially > > > > in recent revisions, and thanks to Sam Weiler for the multiple secdir > > > > reviews. While I agree with Sam that it would be nice to be able to list > > > > examples of non-DRM technical measures to protect the confidentiality of > > > > sensitive path vector information, I can't actually think of any that > > > > would be worth listing, myself. So we may have to proceed with the > > > > current text (unless you have further ideas, of course). > > > > > > > > It looks like the VersionTag.tag value of "d827f484cb66ce6df6b5077cb8562b0a" > > > > is used in a few different examples. While being associated with > > > > different VersionTag.ResourceID values is sufficient to distinguish the > > > > uses from each other, it seems like these examples might be more > > > > enlightening if distinct VersionTag.tag values were used for the distinct > > > > resources. > > > > > > Very good suggestion. We will use different version tags in different examples. > > > > > > > > > > > Section 1 > > > > > > > > Predicting such information can be very complex without the help of > > > > ISPs [BOXOPT]. [...] > > > > > > > > I'm not entirely sure which part(s) of [BOXOPT] are being referenced here. > > > > Their scheme seems to involve producing a privacy-preserving scheme for > > > > resource allocation that does involve exchnages between client and > > > > network, just not ones that reveal sensitive information. Did I miss a > > > > part where they compare against a scenario where the network/ISP does not > > > > provide input? (I only skimmed the paper.) > > > > > > The paper is mainly referenced because of its analysis on the NP-hardness of predicting the values without the help of ISPs (in the introduction). How about we use the following text to make it clear? > > > > > > Predicting such information can be very complex without the help of > > > ISPs, for example, [BOXOPT] has shown that finding the optimal > > > bandwidth reservation for multiple flows is NP-hard without > > > further information than whether a reservation succeeds. > > > > Ah! Yes, that would be a useful clarification. > > > Great! We will proceed with the proposed text. > > > > > > > > > Section 4.1 > > > > > > > > * The ALTO server must expose abstract information on the properties > > > > of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4", e.g., the > > > > available bandwidth between "eh1 - sw1", "sw1 - sw5", "sw5 - sw7", > > > > "sw5 - sw6", "sw6 - sw7", "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", > > > > "sw4 - eh4" in Case 1. > > > > > > > > Does it actually need to expose exactly the available bandwidth between > > > > all those listed pairs of entities? I would have thought that some of the > > > > details could be abstracted away. > > > > > > Not really. Actually for this use case the information can be abstracted as linear constraints. Maybe we should make this more explicit by adding the following text: > > > > > > * The ALTO server must expose abstract information on the properties > > > of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4". For example, > > > an ALTO server can either expose the available bandwidth between > > > "eh1 - sw1", "sw1 - sw5", "sw5 - sw7", "sw5 - sw6", "sw6 - sw7", > > > "sw7 - sw2", "sw7 - sw4", "sw2 - eh2", "sw4 - eh4" in Case 1, or > > > expose 3 abstract elements "A", "B" and "C", which represent the > > > linear constraints that define the same capacity region in Case 1. > > > > Thanks, I think that helps introduce the core ideas of this draft. > > Sounds good. We will use the proposed text in the next revision. > > > > > > > > > > Section 4.2.1 > > > > > > > > For example, assume hosts "a", "b", > > > > "c" are in site 1 and hosts "d", "e", "f" are in site 2, and there > > > > > > > > In Figure 5, I see something that looks like an entry for [d] in the "Site > > > > 1" part, and an entry for [c] in the "Site 2" part. I'm not sure if > > > > that's just an attempt to indicate the directionality of the core backbone > > > > or something else. > > > > > > Yes. The figure is trying to illustrate a flow across sites from host [c] to host [d]. The reason why [d] is shown in Site 1 is to illustrate that the traffic to [d] goes to the backbone in Site 1's network. > > > > > > > > > > > Section 6.4 > > > > > > > > Note that these property types do not depend on any information > > > > resource. As such, their ResourceID part must be empty. > > > > > > > > Does this mean that the '.' is absent as well? > > > > > > > > > > Yes, indeed. We will make this clear with the following text: > > > > > > Note that these property types do not depend on any information > > > resource. As such, the EntityPropertyName MUST only have the > > > EntityPropertyType part. > > > > > > > Section 6.5.2 > > > > > > > > Note that this cost mode only requires the cost value to be a JSON > > > > array of JSONValue. However, an ALTO server that enables this > > > > extension MUST return a JSON array of ANEName (Section 6.1) when the > > > > cost metric is "ane-path". > > > > > > > > If we're going to require that the cost mode "array" only be used with an > > > > array of ANEName, then would it make more sense to call the cost mode > > > > "anearray", leaving the generic "array" for a more generic behavior? > > > > > > > > > > This design is actually discussed in early versions of this document. See [1]. The main point is that "cost-mode" is the type of the value and "cost-metric" is the meaning of the value. I think maybe we can put this as a constraint to the cost metric instead of the cost mode, as proposed below: > > > > Looking at this again, I think I may have misread things the first time. > > On re-reading, it seems like the requirement to return an array of ANEName > > is already conditioned on "when the cost-metric is 'ane-path'", which, > > as you describe, is probably the right condition to use. I think I got > > confused by the phrase "that enables this extension", since I interpreted > > "this extension" to mean the cost-mode "array" itself, rather than the > > broader path-vector extension functionality. So a minor rewording might > > help here; one possible option is '''when the Path Vector procedures defined > > in this document are in use, an ALTO Server using the "ane-path" cost > > metric and the "array" cost mode MUST return as the cost value a JSON array > > of ANEName.''' > > > > > [1] https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-02#section-4.1.3 > > > > > > This cost metric MUST be used when the cost mode is "array" unless > > > explicitly specified by another extension. An ALTO server MUST > > > ensure the returned cost value is an array of ANENames. The client > > > MUST also check that each element contained in the array is an > > > ANEName (Section 6.1). Otherwise, the client MUST discard the > > > response and SHOULD follow the instructions in Section 8.3.4.3 of > > > [RFC7285] to handle the error. > > > > In light of the above, I would suggest not including the requirements in > > the first two sentences (that effectively make the ANEName the default > > behavior for the "array" cost mode). > > OK. The final text (for the last two comments) will be: > > When the Path Vector procedures defined in this document are in use, > an ALTO server using the "ane-path" cost metric and the "array" cost > mode MUST return as the cost value a JSON array of ANEName and the > client MUST also check that each element contained in the array is an > ANEName (Section 6.1). Otherwise, the client MUST discard the > response and SHOULD follow the instructions in Section 8.3.4.3 of > [RFC7285] to handle the error. > > > > > Sorry to have caused confusion here. > > > > > > Section 6.6 > > > > > > > > DOMAIN-NAME: DOMAIN-NAME has the same format as dot-atom-text > > > > specified in Section 3.2.3 of [RFC5322]. It must be the domain > > > > name of the ALTO server. > > > > > > > > (somewhat editorial) is there always exactly one domain name of the ALTO > > > > server (vs. more than one)? > > > > > > > > > > Yes. I think so. In the IRD, each ALTO service is associated with exactly one uri and hence has a unique domain name. > > > > > > > Section 7.2.4 > > > > > > > > object { > > > > [EntityPropertyName ane-property-names<0..*>;] > > > > } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities; > > > > > > > > with fields: > > > > > > > > Up in §7.2.3 we didn't repeat any of the fields from the base type we > > > > inherited from. Here we do, but (apparently) only because we have more to > > > > say about them, e.g., new restrictions on the cost-type-names field to > > > > include the Path Vector cost type. Do we want to mention that some fields > > > > are repeated because we make their definiton more specific for the > > > > PVFilteredCostMapCapabilities usage? > > > > > > Very good suggestion. We intend to put the new field after "with fields" and then insert a sentence to explicitly say that the others have specific restrictions. Here is the proposed text: > > > > > > > > > ane-property-names: ... > > > > > > This extension also introduces additional restrictions for the > > > following fields: > > > > > > cost-type-names: ... > > > cost-constraints: ... > > > > Excellent; thank you! > > No problem! We will use the proposed text in the next revision. > > > > > > > > > > Also, since we're repeating most of the FilteredCostMapCapabilities > > > > fields, is it worth also defining max-cost-types for completeness? > > > > > > This extension does not need modification to the max-cost-types field. With the proposed change to the previous comment, maybe we can skip max-cost-types? > > > > Yes, that seems fine with the "also introduces additional restrictions for" > > text above. > > > > > > > > > > Section 7.2.6 > > > > > > > > The "Content-Type" header of the response MUST be "multipart/related" > > > > as defined by [RFC2387] with the following parameters: > > > > > > > > This could be read as saying that all three parameters are mandatory, but > > > > the actual description for "start" includes the phrase "if present", > > > > implying that it is optional. Some more clarity would be helpful > > > > (especially relating to whether "boundary" is optional or mandatory, which > > > > RFC 2387 itself does not actually clarify directly). > > > > > > Good point. We explicitly specify for each parameter whether it is mandatory or optional. For example: > > > > > > start: The start parameter is as defined in [RFC2387] and is > > > optional. > > > > > > boundary: The boundary parameter is as defined in [RFC2387] and is > > > mandatory. > > > > > > > > > > > * The Path Vector part MUST include "Content-ID" and "Content-Type" > > > > [...] > > > > RESOURCE-ID in the "Content-ID" of the Path Vector part. The > > > > "meta" field MUST also include the "dependent-vtags" field, whose > > > > value is a single-element array to indicate the version tag of the > > > > network map used, where the network map is specified in the "uses" > > > > attribute of the multipart Filtered Cost Map resource in IRD. > > > > > > > > Just to confirm, there would not be a need to include in this > > > > "dependent-vtags" field any dependent resources relating to persistent > > > > ANEs? > > > > > > The vtags of dependent resources are used by the property map part and here it's for the Path Vector part (which is essentially an ALTO cost map). Thus, the interpretation of the Path Vector part only depends on the network map. > > > > Thanks for confirming. > > > > > > > > > > Vector part MUST be included in the "dependent-vtags". If > > > > "persistent-entity-id" is requested, the version tags of the > > > > dependent resources that MAY expose the entities in the response > > > > MUST also be included. > > > > > > > > This seems a surprising use of the normative MAY, to me. > > > > > > Thanks for pointing this out. This should not be a normative MAY. > > > > > > > > > > > HTTP/1.1 200 OK > > > > Content-Length: 821 > > > > Content-Type: multipart/related; boundary=example-1; > > > > > > > > I'm having a hard time reproducing this Content-Length value. Could you > > > > double-check it? > > > > > > > Thanks for the comment. I save the examples and use curl to calculate the value. The new value is 859. > > > > > > > Section 7.3.3 > > > > > > > > POST /ecs/pv HTTP/1.1 > > > > Host: alto.example.com > > > > Accept: multipart/related;type=application/alto-endpointcost+json, > > > > application/alto-error+json > > > > Content-Length: 222 > > > > > > > > I'm getting a length of 226 or 227 (depending on newline at end of file); > > > > please confirm that 222 is correct. > > > > > > > The new calculated value is 227. > > > > > > > Section 7.3.6 > > > > > > > > boundary: The boundary parameter is as defined in [RFC2387]. > > > > > > > > As I alluded to above, the boundary parameter is actually defined in RFC > > > > 2045; the only appearance in RFC 2387 is in two examples. > > > > > > Thanks for the pointer. I checked RFC 2045 and see it actually refers to RFC 2046 (section 5.1.1) for the format of boundary. How about we use RFC 2046 instead? > > > > Oops, I must have been too hasty. Thanks for checking, and yes, it is > > better to use 2046. > > > > We will use RFC 2046 in the next revision. > > > > > > > > The body of the Path Vector part MUST be a JSON object with the > > > > same format as defined in Section 11.5.1.6 of [RFC7285] when the > > > > "cost-type" field is present in the input parameters and MUST be a > > > > JSON object with the same format as defined in Section 4.1.3 of > > > > [RFC8189] if the "multi-cost-types" field is present. The JSON > > > > > > > > I think §4.2.3 of RFC 8189 is somewhat more relevant than §4.1.3, here. > > > > > > Yes indeed. We will change 4.1.3 to 4.2.3. > > > > > > > > > > > The body of the Unified Property Map part MUST be a JSON object > > > > with the same format as defined in Section 4.6 of > > > > [I-D.ietf-alto-unified-props-new]. [...] > > > > > > > > Is §4.6 the right reference here? I don't see much defining a JSON format > > > > in that section or subsections. > > > > > > Thanks for pointing that out. It should be section 7.6 now. > > > > > > > > > > > Vector part MUST be included in the "dependent-vtags". If > > > > "persistent-entity-id" is requested, the version tags of the > > > > dependent resources that MAY expose the entities in the response > > > > MUST also be included. > > > > > > > > As above, this is an unusual use of the normative "MAY". > > > > > > We will change it to "may". > > > > > > > > > > > HTTP/1.1 200 OK > > > > Content-Length: 810 > > > > Content-Type: multipart/related; boundary=example-1; > > > > type=application/alto-endpointcost+json > > > > > > > > Continuing the theme, please check this Content-Length as well. > > > > > > The new calculated value is 845 and we will check the content-length for all examples in the document. > > > > Thanks for going through and checking all of them; I think I did stop > > checking around this point. > > > > > > > > > > Section 8.4 > > > > > > > > As mentioned in Section 6.5.1, an advanced ALTO server may obfuscate > > > > the response in order to preserve its own privacy or conform to its > > > > own policies. [...] > > > > > > > > Is §6.5.1 the correct reference? The word "obfuscate" does not appear > > > > therein that I can see. > > > > > > Thanks for pointing that out. There was a paragraph in early revisions on obfuscation in 6.5.1 but was later moved into security considerations. Here is the proposed text: > > > > > > Under certain scenarios where the traversal order is not crucial, an > > > ALTO server implementation may choose to not follow strictly the > > > physical traversal order and may even obfuscate the order > > > intentionally to preserve its own privacy or conform to its own > > > policies. > > > > That looks okay, thanks. > > Sounds good. We will proceed with the proposed text then. > > > > > > > > > > Section 8.5 > > > > > > > > Is there anything to say about updates needing to be paired in the same > > > > way/for the same reasons we have to use multipart/related to get a > > > > consistent picture of the path vector cost map and its associated ANE > > > > property map? Or perhaps in §9.3 instead? > > > > > > > > > > Thanks for the comment. We feel 9.3 is more appropriate and below is the proposed text: > > > > > > Additionally, the incremental updates of the Path > > > Vector part and the Property Map part MUST be published separately, > > > where the substream ID of each part MUST have the following format: > > > > > > substream-id '.' part-resource-id > > > > > > where "substream-id" is the substream ID of the Path Vector request > > > (e.g., "ecspvsub1" in Section 8.5) and "part-resource-id" is the Part > > > resource ID (e.g., "ecsmap" for the Path Vector part and "propmap" > > > for the Property Map part in Section 8.5). > > > > Overall this seems reasonable. I'd suggest tweaking the wording around > > "MUST be published separately" -- to me, that currently is focusing on > > "they are not published in the same data structure", but we probably want > > to emphasize "if you publish one, you have to publish the other in order > > for it to be useful". Perhaps "MUST both be published, as separate > > updates, where ..."? > > I just checked RFC 8895 and realize that RFC 8895 already gives the specifications for streaming incremental updates for multipart messages in section 6.7.3. Maybe we can simply reference that section as below: > > Section 8.5 (example) > > When the contents change, the ALTO server will publish the updates > for each part separately, based on Section 6.7.3 of [RFC8895]. > > Section 9.3 (compatibility) > > This extension is compatible with the incremental update extension > [RFC8895]. ALTO clients and servers MUST follow the specifications > given in Sections 5.2 and 6.7.3 of [RFC8895] to support incremental > updates for a Path Vector resource. > > > > > > > Section 8.6 > > > > > > > > The second part is the same as in Section 8.4 > > > > > > > > It seems only analogous, not "the same as", to me -- this example uses > > > > aggregated ANEs but §8.3 used the full topology of Figure 10. > > > > > > The second part is actually the same as the second (obfuscated) example in Section 8.4. However, to avoid ambiguity, we propose to use the following text instead: > > > > > > The second part contains a Property Map that maps the ANEs to their > > > requested properties. > > > > Ah, I was presumably going too quickly and just took the first example from > > 8.4 for my diff. The proposed update looks good regardless, though. > > Sounds good. We will proceed with the proposed text. > > > > > > > > > > "endpoint-cost-map": { > > > > "ipv4:192.0.2.34": { > > > > "ipv4:192.0.2.2": [[ "NET3", "AGGR1" ], 1], > > > > "ipv4:192.0.2.50": [[ "NET3", "AGGR2" ], 1] > > > > }, > > > > "ipv6:2001:db8::3:1": { > > > > "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 1] > > > > > > > > Is it really plausible to use the same routing cost of 1 for all three > > > > paths? > > > > > > > We use different routing cost values as below: > > > > > > "endpoint-cost-map": { > > > "ipv4:192.0.2.34": { > > > "ipv4:192.0.2.2": [[ "NET3", "AGGR1" ], 3], > > > "ipv4:192.0.2.50": [[ "NET3", "AGGR2" ], 2] > > > }, > > > "ipv6:2001:db8::3:1": { > > > "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 2] > > > > > > > Section 11 > > > > > > > > Streaming updates of max-reservable-bandwidth seems to provide basically > > > > an equivalent information stream as to what paths have been reserved (and > > > > their bandwidth). That information might be differently sensitive than > > > > the primary network information we're exposing with the path-vector > > > > methodology, so we should probably mention this "information leakage" > > > > channel and give some guidance about what server behaviors might mitigate > > > > the leakage (e.g., batching updates, though I suspect that the policy for > > > > doing so in a way that minimizes information leakage will be about as hard > > > > a problem to solve as padding policies are in general). > > > > > > True if the server is returning all physical links on the paths. However, a major point of introducing (ephemeral) abstract network element is trying to hide such information. For example, with the obfuscation methods (e.g., only returning the linear constraints), only the "bottlenecks" will be revealed and their orders can be arbitrary. We did say in section 11 that these obfuscation methods should be considered/adopted (e.g., reference [NOVA]), though. Do you think we should make this more specific for the "max-reservable-bandwidth" property? > > > > Since we only define "max-reservable-bandwidth" and "persistent-entity-id", > > it seems like the reader has a pretty clear indication that the obfuscation > > concerns apply to "max-reservable-bandwidth". I don't think we need to > > make the references to the obfuscation techniques more prominent here. > > > > I mostly wanted to draw the reader's attention to the causitive > > relationship that when "max-reservable-bandwidth" changes, that means that > > one or more reservations has been made or changed. The process of > > streaming individual updates to the max-reservable-bandwidth at many places > > in the network, even in an abstract topology, does not just give > > information about the network but also gives information about other > > consumers of the network. This sort of "non-local" effect (information > > nominally about the network revealing information about other consumers of > > the network" is what seemed worth highlighting, to me. > > Got it. This makes sense. Here is the proposed text: > > The ALTO service providers must be aware that providing incremental > updates of the "max-reservable-bandwidth" may provide information > about other consumers of the network. For example, a change of the > value may indicate one or more reservations has been made or changed. > To mitigate this risk, an ALTO server CAN batch the updates and/or > add a random delay before publishing the updates. > > > > > > > > > > > I'm a little surprised that we didn't mention anything about persistent > > > > ANEs here (which would be a great way to contrast with the obfuscation > > > > that ephemeral ANEs provide). > > > > > > Good point. We will think about this and propose some new text soon. > > > > > > > > > > > MIME parsers have historically been a recurring source of > > > > security-relevant bugs in other contexts. Perhaps that's sufficiently > > > > well known to not need restating here, though. > > > > > > > > For risk type (3), an ALTO server MUST use dynamic mappings from > > > > ephemeral ANE names to underlying physical entities. Thus, ANE names > > > > contained in the Path Vector responses to different clients or even > > > > for different request from the same client SHOULD point to different > > > > physical entities. [...] > > > > > > > > The guidance of "SHOULD point to different physical entities" doesn't seem > > > > quite right. If the ANE abstraction actually attempted to maximize the > > > > number of distinct physical entities represented, that seems lke it would > > > > make graph reconstruction easier, rather than harder. Perhaps it is > > > > better to give guidance about noncorrelation over time of the ANE > > > > name/physical element mapping, or even guidance to just use randomized ANE > > > > names. > > > > > > > > > > The sentence is trying to say that the same ANEName (e.g., ane1) should not point to the same entity. We agree the guidance might be misleading and the randomized ANE names can be a good option. We will propose the new text soon. > > > > Okay. I think on my third reading or so I came to the tentative conclusion > > that the intent was to say "don't use the same ANEName for the same entity > > over time", but I wasn't entirely sure about it. This is still good > > guidance to give, even if we do also give guidance about randomized ANE > > names. > > We propose the following text to clarify this (along with the persistent ANE): > > For risk type (3), an ALTO service provider must be aware that > persistent ANEs may be used as "landmarks" in collaborative > inferences. Thus, an ALTO server MUST use dynamic mappings from > ephemeral ANE names to underlying physical entities. Specifically, > for the same physical entity, an ALTO server SHOULD assign a > different ephemeral ANE name when the entity appears in the responses > to different clients or even for different request from the same > client. A RECOMMENDED assignment strategy is to generate ANE names > from random numbers. > > > > > > > Section 13.1 > > > > > > > > I don't think RFC 4271 needs to be classified as normative; we seem to > > > > only reference it as an analogy for the Path Vector/AS Path. > > > > > > Good point. We will make it informative. > > > > > > > > > > > Section 13.2 > > > > > > > > [BOXOPT] Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and Y.R. > > > > Yang, "Optimizing in the dark: Learning an optimal > > > > solution through a simple request interface", Proceedings > > > > of the AAAI Conference on Artificial Intelligence 33, > > > > 1674-1681 , 2019. > > > > > > > > It looks like this is https://doi.org/10.1609/aaai.v33i01.33011674 ; if > > > > so, including the DOI link would be very helpful for readers. > > > > > > > > That's just the one I happend to go pull up; DOIs for the other papers (if > > > > available) should be included, too. > > > > > > OK. We will add the DOI link for each academic paper. > > > > > > > > > > > NITS > > > > > > > > Section 1 > > > > > > > > Map that contains the properties requested for these ANEs. To > > > > enforce consistency and improve server scalability, this document > > > > uses the "multipart/related" message defined in [RFC2387] to return > > > > the two maps in a single response. > > > > > > > > I think it's more typical to say "content type" than "message" in this > > > > context. > > > > > > We will modify as suggested. > > > > > > > > Section 3 > > > > > > > > performance of traffic. An ANE can be a physical device such as a > > > > router, a link or an interface, or an aggregation of devices such > > > > as a subnetwork, or a data center. > > > > > > > > I think we do not want a comma before "or a data center", since the data > > > > center is just another example of an aggregation of devices. > > > > > > > We will modify as suggested. > > > > > > > Section 4.1 > > > > > > > > performance. The capacity region information for those flows will > > > > benefit the scheduling. However, Cost Maps as defined in [RFC7285] > > > > can not reveal such information. > > > > > > > > I'm not sure I know what "capacity region information" is; did we mean > > > > "region capacity information" (or maybe "Knowledge of the relevant > > > > capacity regions for those flows")? > > > > > > We change the term to "constraints on feasible rate allocations of those flows" which may be clearer. > > > > That seems more clear, thanks. > > > > > > > > > > With the ALTO Cost Map, the cost between PID1 and PID2 and between > > > > PID1 and PID4 will be 100 Mbps. The client can get a capacity region > > > > > > > > I'd suggest "will both be". > > > > > > We will modify as suggested. > > > > > > > > Section 4.2.1 > > > > > > > > With the Path Vector extension, a site can reveal the bottlenecks > > > > inside its own network with necessary information (such as link > > > > capacities) to the ALTO client, instead of providing the full > > > > topology and routing information. [...] > > > > > > > > I'd suggest adding "or no bottleneck information at all". > > > > > > > We will modify as suggested. > > > > > > > Section 4.2.2 > > > > > > > > in various documents (e.g., [SEREDGE] and [MOWIE]). Internet Service > > > > Providers may deploy multiple layers of CDN caches, or more generally > > > > service edges, with different latency and available resources > > > > including number of CPU cores, memory in Gigabytes (G), and storage > > > > measured in Terabytes (T). > > > > > > > > The units are probably not relevant for the abstract scenario, and would > > > > only become relevant when we start introducing Figure 6 as a specific > > > > instantiation of the multi-layer model. > > > > > > > > > > We propose the following text: > > > > > > ... Internet Service > > > Providers may deploy multiple layers of CDN caches, or more generally > > > service edges, with different latency and available resources > > > including number of CPU cores, memory, and storage. > > > > > > For example, Figure 6 illustrates a typical edge-cloud scenario where > > > memory is measured in Gigabytes (G) and storage is measured in > > > Terabytes (T). > > > > Perfect! > > > > Thanks again for the explanations and updates, it sounds like we are > > getting to a good place. > > Sounds good. We will proceed with the proposed text. > > > > -Ben > > > > > > Section 5.1.3 > > > > > > > > Specifically, the available properties for a given resource are > > > > announced in the Information Resource Directory as a new capability > > > > called "ane-property-names". The selected properties are specified > > > > in a filter called "ane-property-names" in the request body, and the > > > > response includes and only includes the selected properties for the > > > > ANEs in the response. > > > > > > > > Going from the first to second sentence, we switch from using the string > > > > "ane-property-names" to refer to the available properties announced in the > > > > IRD, to using it to refer to the properties that a client supplies in a > > > > path vector query for use in filtering the response results. To help the > > > > reader make this transition smoothly, I suggest rephrasing the transition, > > > > perhaps to something like "The properties selected by a client as being of > > > > interest are specified in the subsequent Path Vector queries using the > > > > filter called 'ane-property-names'." > > > > > > > Good point. We will modify as suggested. > > > > > > > Section 5.3 > > > > > > > > 1. Since ANEs may be constructed on demand, and potentially based on > > > > the requested properties (See Section 5.1 for more details). If > > > > > > > > Incomplete sentence. > > > > > > > We will remove "Since". > > > > > > > Section 6.2.4 > > > > > > > > multipart response. Meanwhile, for persistent ANEs whose entity > > > > domain name has the format of "PROPMAP.ane" where PROPMAP is the name > > > > of a Property Map resource, PROPMAP is the defining resource of these > > > > > > > > Is it better to say "name" of "ResourceID"? > > > > > > We propose to change the "name" to "resource ID". > > > > > > > > > > > > > > > > _______________________________________________ > > > > alto mailing list > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/alto > > > </[email protected]></[email protected]> > > > </[email protected]></[email protected]></[email protected]></[email protected]> > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto </[email protected]></[email protected]> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
