Re: [P2PSIP] RFC6940: Detecting Partitioning

Evgeny <xramtsov@gmail.com> Mon, 15 October 2018 07:57 UTC

Return-Path: <xramtsov@gmail.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24DD130DCE for <p2psip@ietfa.amsl.com>; Mon, 15 Oct 2018 00:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 TYsnHN3GbcD8 for <p2psip@ietfa.amsl.com>; Mon, 15 Oct 2018 00:56:59 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3182130DBE for <p2psip@ietf.org>; Mon, 15 Oct 2018 00:56:58 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id p143-v6so2332850lfp.13 for <p2psip@ietf.org>; Mon, 15 Oct 2018 00:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:message-id:in-reply-to:references:mime-version; bh=LhmndSphHcdXBvmyWvnSi/JdaiP+TYhtNp5o6/tSNzQ=; b=j52GwXOm1MpKSVqNNMEf8STy1/0Fhj1xkD6CJm74ikmK5wEijorcyM8U4uunHP8/qy /EpC5YSbzxbsr0g2buwnFRCwiojXCJiArBYTuByYZrsoltpk8lzKe52F3nEw5PeSmGnX DdSvnjKFkdS0aNX6ZfZwinodIp3VI928gymO2G5k2FgyJMkbOTpIQpHkLWy+nAp8ncp+ 3UD2bdm4zN2WkkBlOZKOSgtDf43J9sNR42ISpD9UxY/yibu5skfc2N5XJqSOYDju5AY3 XPQ2Qm5yWqjaxpFORR1PbA9rMM7cz1/NtEQ6FkNWGhUT34wwv9p12+Hl6sWA4FGP2o07 TpDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:message-id:in-reply-to :references:mime-version; bh=LhmndSphHcdXBvmyWvnSi/JdaiP+TYhtNp5o6/tSNzQ=; b=jHSSqrWlIe9lmjaqrFZD5p5l00SoPT/pwpJFTbHsJC7zbr+3/JnP0FIrbKruhRZ2iW mbvzMXK0TZzZ7hdZsUctx2KTzRYUvIEeL9QXeWFZIUjjBYVmeUa3eXi4R0/fOJHv+ZxZ t7cqkNvh/0gMj4Vz1frQAPzs88iM8rVH9ZEUTd7oMpWk3MtW0F7t6Buo7wGy8eNwSJIN ZjN7KVKNEWC5jN0gQ5QcnovEwA7eFXjH8I1KB2mCGPOhERY8eNgU3XgDYSzhMbX5o+X8 VPrqrj4V1e+DvYI29DE3uSYJu9l59qZoxwLyQGKQ6xS81qq2zFPYasl/M0XMzmUia6t3 719A==
X-Gm-Message-State: ABuFfoifB0RSBezxPcI/MftJkipYr6XA5WqqQtDDU4otvmE76ariT+iT psbK0ZEtYh5XAXkWu0PUNTa/Jgu8
X-Google-Smtp-Source: ACcGV61s8gnVYOYXUSIBo7v807vSYRDpeQWORfHN+3DprYwjEKVWuZEyEjBRJ49JSa56b5eOan1y9g==
X-Received: by 2002:a19:9b12:: with SMTP id d18-v6mr9478600lfe.132.1539590216678; Mon, 15 Oct 2018 00:56:56 -0700 (PDT)
Received: from [192.168.1.102] ([31.181.13.56]) by smtp.gmail.com with ESMTPSA id t6-v6sm2161656ljd.2.2018.10.15.00.56.55 for <p2psip@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 15 Oct 2018 00:56:56 -0700 (PDT)
Date: Mon, 15 Oct 2018 10:56:54 +0300
From: Evgeny <xramtsov@gmail.com>
To: p2psip@ietf.org
Message-Id: <1539590214.1981.2@smtp.gmail.com>
In-Reply-To: <e1479c89-b408-0574-55bb-5a158e284c51@kit.edu>
References: <1539543879.1981.0@smtp.gmail.com> <e1479c89-b408-0574-55bb-5a158e284c51@kit.edu>
X-Mailer: geary/0.12.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/p2psip/NyAiEgC-v8q4ydC61u6f4u3a66o>
Subject: Re: [P2PSIP] RFC6940: Detecting Partitioning
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 15 Oct 2018 07:57:01 -0000


On Mon, Oct 15, 2018 at 10:13 AM, Bless, Roland (TM) 
<roland.bless@kit.edu>; wrote:
> Yes, the last hop forwarding the answer will be B, but the originating
> node from the other end (i.e., the one answering the ping request) is 
> a
> different node than P's current successor.

"the one answering the ping request"? But this will be my node 
answering the ping request.
Ok, I'm lost. Let's consider the PingReq path:

my_node -> boot_node -> ... -> node_X -> my_node

The corresponding PingAns will be:

my_node -> node_X -> ... -> boot_node -> my_node

So the idea is to check if node_X is the successor of my_node, right?
In this case I don't understand how to get that node from the answer: 
forwarding nodes
are not required to maintain Via lists, or they can just hide the path 
by OpaqueID.
Should I maintain some state on my node to do these checks?

> That may be best understood by looking at Figure 1 on page 139 and/or
> section 10.5.
> The Joining Node sends an AttachReq to its own ID+1 (this process
> is probably denoted as "Attaching"). The Admitting Peer (AP) and
> responsible peer are the same in this case, it will be the successor
> of the newly joining node. Does this make sense?

Yes, this makes sense, and this is trivial, but it's hard to understand 
from that phrase.
Whatever, thanks for the clarification.