Re: [P2PSIP] Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

Hi Alvaro,

Are you able to clear based on the latest version? https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-21 <https://tools.ietf.org/html/draft-ietf-p2psip-diagnostics-21>

Thanks,
Alissa


> On Jan 7, 2016, at 12:27 PM, Alvaro Retana (aretana) <[e-mail]> wrote:
> 
> On 1/6/16, 4:44 AM, "Songhaibin (A)" <[e-mail]> wrote:
> 
> Haibin:
> 
> Hi!
> 
> ...
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> I am balloting a DISCUSS because I am concerned that this document
>>> doesn't
>>> actually do what it set out to achieve.  I would love it if during the
>>> discussion I
>>> was pointed to the places where RELOAD already solves the issues, but
>>> for now
>>> I wasn't able to find them.
>>> 
>>> According to the text, both extensions are intended to collect
>>> information
>>> "along the path", and the Figures clearly depict what is intended to
>>> happen.
>>> However, I don't think that as specified (or at least as explained) the
>>> behavior is
>>> guaranteed.  Specific points:
>>> 
>>> 1. RFC6940 says (in Section 6.2. (Symmetric Recursive Routing)) that an
>>> "overlay MAY be configured to use alternative routing
>>> algorithmsŠ[or]ŠMAY be
>>> selected on a per-message basis". How is the symmetry enforced if other
>>> routing algorithms are used?  Enforcing that the ping/trace messages use
>>> symmetric routing when other algorithms are in use won't necessarily
>>> help
>>> because the paths may be different.
>> 
>> I think one important thing is that, the draft does not guarantee what it
>> conveys must be the information that caused the previous failures, but
>> with the retrieved information from the previous traversed nodes (with
>> high probability, as it cannot guarantee the exact same path), a user or
>> machine can analyze and infer what is the problem. Symmetric routing is
>> achieved by the via list (whatever DHT routing algorithms are used), but
>> response message could go through not exactly the same path as there
>> still can be failures during that short period.
>> 
>>> 
>>> 2. RFC6940 also (in 6.2.2. (Response Origination)) reads: "the response
>>> traverses the same peers as the request traversed, except in reverse
>>> order
>>> (symmetric routing) and possibly with extra nodes (loose routing)."
>>> In other words, even if symmetric routing is used, there is no
>>> guarantee that
>>> the same path will be followed by the response, unless the originator
>>> builds the
>>> Via List with strict details of all the nodes in the path -- maybe this
>>> is what is
>>> intended, but no explicit mention occurs in the document.
>> 
>> I agree this should be mentioned in the document.
> 
> Clarifying the caveats (like what we're discussing above, for example) is
> one of the ways to move forward with resolving my DISCUSS.
> 
> However, I have to say that the clarifications, which basically point at
> no guarantees about the path (or its relevance), leave me very
> dissatisfied with a technical solution that is unreliable. :-(
> 
>> 
>>> 
>>> 3. In 4.3, what does "directly or via symmetric routing" mean? Is it
>>> directly
>>> connected? If so, then (for the text in 4.3) that would mean that C is
>>> adjacent
>>> to A, and even though it is the next hop after B, the path taken to
>>> reach C with
>>> the PathTrack request doesn't include B ‹ the result is that the
>>> diagnostic
>>> information received from C may not be relevant relative to destination
>>> D.
>> 
>> As each PathTrack request will contain the destination ID, which was the
>> same destination ID as the previously failed message. So no matter how
>> the PathTrack request arrives to C, C will have a look at that
>> destination ID for the next step.
> 
> My point above was the the path *to* C (from A) may not actually even go
> through B.  In other words, even if the rest of the path (all the way to
> D) is congruent, the overall information is still not completely relevant.
> 
>> 
>> 
>>> 
>>> Are there implementations available?  What has been the experience? The
>>> Shepherd's write-up didn't mention any, and the TBD codes make me think
>>> that
>>> maybe Experimental might be a better status for this document.
>> 
>> In my memory, there was one several years ago, but not based on RELOAD.
> 
> Given the clear inconsistency and the lack of experience, I want to
> suggest that Experimental status be considered.
> 
>> 
>> 
>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> In general, as others have mentioned, I think the text could be a lot
>>> clearer and
>>> not leave some concepts to interpretation.
>>> 
>>> 1. In 4.2.1, the MessageExtension is defined with a Boolean of
>>> "critical", but
>>> the text (a paragraph later) says that this "extension is not
>>> critical". I may be
>>> missing some of the semantics, or there's an error somewhere.
>> 
>> My understanding with RELOAD, if value of "critical" can be true or
>> false, if it is critical, then every node must support the extension, if
>> it is not critical, then it is optional to support it. As it explains in
>> that section, "If a peer does not support the extension, they will simply
>> ignore the diagnostic portion of the message..."
> 
> I looked at the text again -- it is still confusing to me, but I noticed
> that Section 6.1. (Message Creation and Transmission) does say that "the
> sender MUST...[set] the value of critical to FALSE".  Maybe using
> "Critical" (capital C) to describe the state (vs the use of the word as an
> adjective) would help.
> 
>> 
>>> 
>>> 2. In 4.3..the last paragraph reads: if "...succesive calls to
>>> PathTrack return
>>> different paths, the results should be discarded and the request resent,
>>> ensuring that the second request traverses the appropriate path".
>>> Path changes are a fact of life ‹ the second request may just be
>>> reflecting the
>>> new path, so resending it in an attempt to find the "appropriate path"
>>> may be
>>> futile.
>> 
>> At least in the previous two attempts, the path was "stable".
>> 
>>> 3. What is a "routing mode"?  Section 4.3.1. (New RELOAD Request:
>>> PathTrack) talks about it when saying that the "PathTrack request can be
>>> routed directly or through the overlay based on the routing mode".
>>> Later
>>> Section 6.2. (Message Processing: Intermediate Peers) says that
>>> "processing
>>> this request according to the overlay specified routing mode from RELOAD
>>> protocol" -- I looked in RFC6940 for "routing mode", but didn't find
>>> anything.
>>> Note that it also looks to me like there's no place in the
>>> DiagnosticsRequest to
>>> indicate a mode..
>> 
>> This draft should add a reference to RFC 7263 for the routing mode.
> 
> Ok.
> 
>> 
>>> 4. Section 5.3. (dMFlags and Diagnostic Kind ID Types) defines an
>>> "UNDERLAY_HOP (8 bits): Indicates the IP layer hops from the
>>> intermediate
>>> peer which receives the diagnostics message to the next hop peer for
>>> this
>>> message."  How is that information derived?
>> 
>> It can use the traceroute tool.
>> 
>>> 5. I think that the Reference to RFC5226 should be Normative.
>>> 
>> 
>> Accepted.
>> 
>>> 
>>> I also agree with others that the title should probably be something
>>> around
>>> RELOAD Diagnostics, and that this work doesn't really update RFC6940, it
>>> extends it in independent ways.
>> 
>> It seems we can achieve a consensus here that it extends RELOAD. What
>> about the title "RELOAD Extension for P2P Overlay Diagnostics"?
> 
> I am not opposed to that.
> 
> Thanks!
> 
> Alvaro.
>