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) <[email protected]> > wrote: > > On 1/6/16, 4:44 AM, "Songhaibin (A)" <[email protected]> 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. >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
