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

["Songhaibin (A)" <[e-mail]>]

Dear Alvaro,

Thank you and see my reply in line.

> -----Original Message-----
> From: Alvaro Retana [mailto:[e-mail]]
> Sent: Thursday, December 17, 2015 6:06 AM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with
> DISCUSS and COMMENT)
> 
> Alvaro Retana has entered the following ballot position for
> draft-ietf-p2psip-diagnostics-19: 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/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-p2psip-diagnostics/
> 
> 
> 
> ----------------------------------------------------------------------
> 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.

> 
> 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. 

> 
> 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. 


> 
> ----------------------------------------------------------------------
> 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..."

> 
> 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.

> 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"?


Thanks again,

-Haibin Song