[P2PSIP] Alvaro Retana's Discuss on

[Songhaibin (A)]

Dear Alvaro,

Thank you and see my reply in line.

-----Original Message-----
Sent: Thursday, December 17, 2015 6:06 AM
To: The IESG
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.
https://datatracker.ietf.org/doc/draft-ietf-p2psip-diagnostics/
----------------------------------------------------------------------
----------------------------------------------------------------------
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
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.

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

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

[Songhaibin (A)]

Hi Alvaro,

-----Original Message-----
Sent: Friday, January 08, 2016 4:28 AM
To: Songhaibin (A); The IESG
Subject: Re: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with
DISCUSS and COMMENT)
Hi!
...

Post by Songhaibin (A)

---------------------------------------------------------------------
-
---------------------------------------------------------------------
-
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)
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. :-(

Unless there is path information from the previous RELOAD message, it cannot guarantee the same path for the diagnostics message. It is similar to the routing packets in a large network.

Post by Songhaibin (A)

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.

It is determined by the routing table in the P2P overlay network. If the overlay is stable, then the path to the destination is stable. The "directly or via symmetric routing" only mean how the initiator node talk with each peer in the path. Symmetric routing means the use of via list. And directly routing (I will change it to direct response routing) can refer to RFC 7263.

So in this case you mentioned, A asks B first, and then asks C (via DRR or symmetric routing).

I hope the clarification helps.

Post by Songhaibin (A)

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.

If we get an consensus somewhere on the status, I will follow it to do the editing work.

Thank you very much,

-Haibin Song

Post by Songhaibin (A)

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

Post by Songhaibin (A)

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

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.

Post by Songhaibin (A)

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.

[Alissa Cooper]

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

Hi!
...

Post by Songhaibin (A)

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

Post by Songhaibin (A)

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.

Post by Songhaibin (A)

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.

Post by Songhaibin (A)

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

Post by Songhaibin (A)

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

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.

Post by Songhaibin (A)

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.

[Songhaibin (A)]

And would Jari clear his DISCUSS based on the version 21?

Best Regards!
-Haibin

From: Alissa Cooper [mailto:***@cooperw.in]
Sent: Saturday, March 05, 2016 3:37 AM
To: Alvaro Retana (aretana)
Cc: Songhaibin (A); IESG; Roni Even; p2psip-***@ietf.org; draft-ietf-p2psip-***@ietf.org; ***@ietf.org; ***@it.uc3m.es
Subject: Re: Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)

Hi Alvaro,

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

Thanks,
Alissa


On Jan 7, 2016, at 12:27 PM, Alvaro Retana (aretana) <***@cisco.com<mailto:***@cisco.com>> wrote:

On 1/6/16, 4:44 AM, "Songhaibin (A)" <***@huawei.com<mailto:***@huawei.com>> 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.