daveoran
commented
3 years ago Rute,
Here are my (quite belated) responses to your excellent comments and questions on the -03 version. As I mentioned earlier, I had refreshed the draft to version -04 just to keep it alive, so it is version -05 that contains the modifications noted below in my responses.
I just posted the revised draft, which you can find at: https://datatracker.ietf.org/doc/draft-oran-icnrg-pathsteering
On 11 May 2020, at 11:24, Rute Sofia wrote:
Hello Ilya, David,
so here is a review for https://datatracker.ietf.org/doc/draft-oran-icnrg-pathsteering/?include_text=1.
The draft is quite clear given that it has as basis an ACM ICN (2017) paper.. Some suggestions :
- If possible, Figure 1 should be revised, as ideally the reader should understand the difference when applying this specific proposal of path steering (where, since a first Interest packet follows a path, all subsequent ones directed to the same object/session will do the same)...The figure on the paper is similar, so a suggestion would be to have a fig exemplifying what would happen in forwarder 2, if the conditions in between Interest 1 and Interest 2 would change (for path discovery in ICN vs path steering)..
Excellent idea - I enhanced the figure to show the ability to discover multiple paths.
- Even though you state that the paper should be a normative reference, the fact is that the reader may or may not read the paper. Therefore, IMO it would be good to have up front a list of definitions (end to end path discovery, path label, etc).
Good suggestion. I added a reference to the Terminology RFC (RFC8793) and definitions for Path Discovery, Path Steering, Path Label, and Nexthop Label.
- Applicability. A summary for the applicability of path steering is provided in the intro (accurate measurement; monitoring and discovery of multipath). However, the draft would benefit from a section on specific applicability aspects, beyond measurement, and also considering application of ICN on wireless environments IMO.
Going along with general guidance about specifications intended for experimental publication status, I reworked the introduction a bit to separate out the various uses of Path Steering in experimental settings. I’m a bit at a loss for what to add here, especially with respect to wireless - are you thinking of scenarios where mobility management would be enhanced by the use of path steering? If so any guidance (or better, text!) you can supply on this would be highly valued. I will note that the documented uses in the spec include some important functions beyond measurement (multi-path congestion control and diversion around poisoned caches) so i think these are covered, albeit briefly. Do you think it would help to highlight these by moving them up above the measurement examples?
And an additional question:
- This specific proposal for path steering builds the path for a session/chunks of an object) based on the first Interest packet for that specific object, correct? Yes, or a set of related objects pointed to by a Manifest that are likely to reside at the same producer and/or be cached at the same forwarders.
Would it be possible/make sense to debate on an approach which would consider a set of first Interest packets, i.e., so that the path would be built on a "best" path instead of on a "first" path? Ah, that brings up an interesting design question. Some multi-path forwarding/routing schemes in fact forward over the “best” path unless that path becomes congested. In this common situation the first path discovered is highly likely to be the “best path”. In other schemes that do things like round-robin it is somewhat slippery to even say what the “best” path is. In the absence of any multi-path forwarding of course the “best” path is the only path until some routing event changes the path. This makes path steering still moderately useful for instrumentation purposes, but obviously not for the other cited use cases.
I haven’t made any changes to the document in this regard.
Does this help or do you think we need to expand some discussion around how various enumerated or non-enumerated paths relate to one another?
Hello Ilya, David,
so here is a review for https://datatracker.ietf.org/doc/draft-oran-icnrg-pathsteering/?include_text=1.
The draft is quite clear given that it has as basis an ACM ICN (2017) paper. Some suggestions :
- If possible, Figure 1 should be revised, as ideally the reader should understand the difference when applying this specific proposal of path steering (where, since a first Interest packet follows a path, all subsequent ones directed to the same object/session will do the same)…The figure on the paper is similar, so a suggestion would be to have a fig exemplifying what would happen in forwarder 2, if the conditions in between Interest 1 and Interest 2 would change (for path discovery in ICN vs path steering).
- Even though you state that the paper should be a normative reference, the fact is that the reader may or may not read the paper. Therefore, IMO it would be good to have up front a list of definitions (end to end path discovery, path label, etc).
- Applicability. A summary for the applicability of path steering is provided in the intro (accurate measurement; monitoring and discovery of multipath). However, the draft would benefit from a section on specific applicability aspects, beyond measurement, and also considering application of ICN on wireless environments IMO.
And an additional question:
- This specific proposal for path steering builds the path for a session/chunks of an object) based on the first Interest packet for that specific object, correct? Would it be possible/make sense to debate on an approach which would consider a set of first Interest packets, i.e., so that the path would be built on a “best” path instead of on a “first” path?
BR,
Rute Sofia