Re: [ppsp] Regarding clause "2.3.2 error conditios" in PPSP-TP

"Huangyihong (Rachel)" <rachel.huang@huawei.com> Mon, 19 October 2015 09:15 UTC

Return-Path: <rachel.huang@huawei.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4B1A87A1 for <ppsp@ietfa.amsl.com>; Mon, 19 Oct 2015 02:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Level:
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 2UdVu0y6rrbk for <ppsp@ietfa.amsl.com>; Mon, 19 Oct 2015 02:15:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 773941A8787 for <ppsp@ietf.org>; Mon, 19 Oct 2015 02:15:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYZ14163; Mon, 19 Oct 2015 09:15:35 +0000 (GMT)
Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 19 Oct 2015 10:15:35 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Mon, 19 Oct 2015 17:15:30 +0800
From: "Huangyihong (Rachel)" <rachel.huang@huawei.com>
To: 현욱 <whyun@etri.re.kr>, "ppsp@ietf.org" <ppsp@ietf.org>
Thread-Topic: [ppsp] Regarding clause "2.3.2 error conditios" in PPSP-TP
Thread-Index: AdEKSu3CS4xk/LVuSWKsP+auNVOHtwAAu0XA
Date: Mon, 19 Oct 2015 09:15:29 +0000
Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86441C16@nkgeml501-mbs.china.huawei.com>
References: <3547C9BBE62E844093C527F2EE9D9E3A1E237A57@SMTP1.etri.info>
In-Reply-To: <3547C9BBE62E844093C527F2EE9D9E3A1E237A57@SMTP1.etri.info>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.79.189]
Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB86441C16nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/ppsp/4Ui2tEwpf5BK1sNqdKuga3qE7gM>
Subject: Re: [ppsp] Regarding clause "2.3.2 error conditios" in PPSP-TP
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ppsp/>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 09:15:43 -0000

Hi Hyun,

I think you’re right. At the TRACKING state, only when timeout the registration should be removed. In any other cases of the TRACKING state, including receiving error CONNECT, error FIND and error STAT_REPORT,  just sending response with error code. Right?
We can address it in the next version.

BR,
Rachel

From: ppsp [mailto:ppsp-bounces@ietf.org] On Behalf Of ??
Sent: Monday, October 19, 2015 4:47 PM
To: ppsp@ietf.org
Subject: [ppsp] Regarding clause "2.3.2 error conditios" in PPSP-TP


Hi all,

I have a question regarding clause 2.3.2 Error conditions.
In sub-clause B) it says,

B) At the TRACKING state (while the "track timer" has not expired)
      receiving a CONNECT message from that Peer ID with invalid swarm
      actions (section 5.1) is considered an error condition.  The
      Tracker responds with error code Forbidden (described in
      section 4.3), stops the "track timer", deletes the registration,
      transitions to TERMINATE state for that Peer ID and the SM is
      destroyed.

If a peer that has already joined multiple overlay networks(swarms) tries to join invalid swarm,
it looks like that the registration should be removed according to above sentence.

Am I understanding right?

I think that such situation probably happen often, since a user may mistype or session may be removed by owner.
How about don’t going TERMINATE state but just send error message for the transaction.


Regards,..
W.Hyun