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

Alissa Cooper <> Fri, 04 March 2016 19:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 61F671A88C2 for <>; Fri, 4 Mar 2016 11:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CT6vs1aJL4XZ for <>; Fri, 4 Mar 2016 11:42:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B1F81A88BD for <>; Fri, 4 Mar 2016 11:42:59 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id DEC9720A89 for <>; Fri, 4 Mar 2016 14:36:45 -0500 (EST)
Received: from frontend1 ([]) by compute6.internal (MEProxy); Fri, 04 Mar 2016 14:36:45 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=BX+Ef VfgIRiE5ARYnclDDDQXGn4=; b=298vE/lOhynlKIOeoloQ7hAR4aTc4Mdp0ZiqM HoSOVi8WJsf+OAYSGeu6HvDCTd4Y2kOh63+wL3gM0douiCS6RSlrDI3JXUA4Bkt5 G1hUWd0iA8CplcobRY87j3yd47jn7JPufeHIAxr3jGpb4U7ApXqLtXQ91nL3OjSm /7brac=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=BX+EfVfgIRiE5ARYnclDDDQXGn4=; b=qSJFx tpIAZIzVB0ZVK/L7t2mzzbjXYUjYumihgn5lb0BcMrC4wMXLpoRmwQQRVJg5fPJw e/WdFDDCCYzrBKmw5nizQWTJfLoBmUeoF8M9WdE5xqIGZ3F2jq+RunB/md/peIse N1uP8v0IWi0o+j9yhm9jKd1RaOgG/UQmpXlcvU=
X-Sasl-enc: 3XP2uBhUWlYynL8K1cUsGQY8ylOTUmp0cFaEAoOJOSG6 1457120205
Received: from ( []) by (Postfix) with ESMTPA id B1784C00018; Fri, 4 Mar 2016 14:36:44 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6605EAB1-BFCE-49F0-9F18-59DF81BD3FF6"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Fri, 4 Mar 2016 11:36:43 -0800
Message-Id: <>
References: <> <> <>
To: "Alvaro Retana (aretana)" <>
X-Mailer: Apple Mail (2.3112)
Archived-At: <>
Cc: "" <>, "" <>, IESG <>, "" <>
Subject: Re: [P2PSIP] Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Mar 2016 19:43:02 -0000

Hi Alvaro,

Are you able to clear based on the latest version? <>


> On Jan 7, 2016, at 12:27 PM, Alvaro Retana (aretana) <> wrote:
> On 1/6/16, 4:44 AM, "Songhaibin (A)" <> wrote:
> Haibin:
> Hi!
> ...
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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.
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> 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.