Re: [P2PSIP] RFC6940: Detecting Partitioning

Evgeny <> Mon, 15 October 2018 07:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E24DD130DCE for <>; Mon, 15 Oct 2018 00:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TYsnHN3GbcD8 for <>; Mon, 15 Oct 2018 00:56:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3182130DBE for <>; Mon, 15 Oct 2018 00:56:58 -0700 (PDT)
Received: by with SMTP id p143-v6so2332850lfp.13 for <>; Mon, 15 Oct 2018 00:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 [] ([]) by with ESMTPSA id t6-v6sm2161656ljd.2.2018. for <> (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 <>
Message-Id: <>
In-Reply-To: <>
References: <> <>
X-Mailer: geary/0.12.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Archived-At: <>
Subject: Re: [P2PSIP] RFC6940: Detecting Partitioning
X-Mailman-Version: 2.1.29
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: Mon, 15 Oct 2018 07:57:01 -0000

On Mon, Oct 15, 2018 at 10:13 AM, Bless, Roland (TM) 
<> 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.