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

Alissa Cooper <alissa@cooperw.in> Fri, 04 March 2016 19:43 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F671A88C2 for <p2psip@ietfa.amsl.com>; Fri, 4 Mar 2016 11:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT6vs1aJL4XZ for <p2psip@ietfa.amsl.com>; Fri, 4 Mar 2016 11:42:59 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1F81A88BD for <p2psip@ietf.org>; Fri, 4 Mar 2016 11:42:59 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DEC9720A89 for <p2psip@ietf.org>; Fri, 4 Mar 2016 14:36:45 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Fri, 04 Mar 2016 14:36:45 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; 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= messagingengine.com; 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 dhcp-171-68-20-44.cisco.com (dhcp-171-68-20-44.cisco.com [171.68.20.44]) by mail.messagingengine.com (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 <alissa@cooperw.in>
In-Reply-To: <D2B42F28.FFE86%aretana@cisco.com>
Date: Fri, 4 Mar 2016 11:36:43 -0800
Message-Id: <AFED0F52-7A79-4F70-819D-D6F385ED6B3A@cooperw.in>
References: <20151216220546.7663.70255.idtracker@ietfa.amsl.com> <E33E01DFD5BEA24B9F3F18671078951F65DAC97F@nkgeml513-mbx.china.huawei.com> <D2B42F28.FFE86%aretana@cisco.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/JybIWuZOJUaJomB5wtPX6ibDiJ0>
Cc: "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>, "p2psip@ietf.org" <p2psip@ietf.org>, IESG <iesg@ietf.org>, "draft-ietf-p2psip-diagnostics@ietf.org" <draft-ietf-p2psip-diagnostics@ietf.org>
Subject: Re: [P2PSIP] Alvaro Retana's Discuss on draft-ietf-p2psip-diagnostics-19: (with DISCUSS and COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=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? 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) <aretana@cisco.com> wrote:
> 
> On 1/6/16, 4:44 AM, "Songhaibin (A)" <haibin.song@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.
>