Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard

Fortune HUANG <fqhuang@huawei.com> Thu, 18 March 2010 04:07 UTC

Return-Path: <fqhuang@huawei.com>
X-Original-To: ippm@core3.amsl.com
Delivered-To: ippm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5658628C0ED for <ippm@core3.amsl.com>; Wed, 17 Mar 2010 21:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.524
X-Spam-Level:
X-Spam-Status: No, score=0.524 tagged_above=-999 required=5 tests=[AWL=-2.681, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMLpQEAPIC2q for <ippm@core3.amsl.com>; Wed, 17 Mar 2010 21:07:41 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E598728C0F8 for <ippm@ietf.org>; Wed, 17 Mar 2010 21:07:39 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG006NSM510M@szxga03-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:07:49 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZG0049FM51BT@szxga03-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:07:49 +0800 (CST)
Received: from h36145c ([10.70.39.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZG005SIM51AQ@szxml06-in.huawei.com> for ippm@ietf.org; Thu, 18 Mar 2010 12:07:49 +0800 (CST)
Date: Thu, 18 Mar 2010 12:07:49 +0800
From: Fortune HUANG <fqhuang@huawei.com>
To: ippm@ietf.org
Message-id: <004601cac650$9284a3d0$4027460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_kcWwp8t4u4eTBFsqD2U3TQ)"
Thread-index: AcrGUJJZlnp5haxQTGO04jUqKw4trg==
X-Mailman-Approved-At: Sun, 21 Mar 2010 08:01:41 -0700
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Mar 2010 04:07:42 -0000

Dear all,
 
I have some questions about this draft below. Sorry for being a little late.
 
1. It is not clear to me how the server or the reflector use the SID
specified in the request from the client. The SID doesn't seem to be used to
correlate the test packets and the accepted sessions because there is no SID
in the test packets. 
 
2. In section 3.3, I think the SIDs may not need to be carried back to the
client. Assuming the SID is accepted in sequence with no discrimination, the
client can figure out the list of accepted SIDs with the accepted number of
sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in
sequence, can the server accepts only SID1, SID3 without accepting SID2? If
it can do that, how does the server differentiate SID3 and SID2? If it can
not do that, that I think the server can return a acceptance count to the
client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and
SID3.
 
3. In section 3.5, What can the client do if told by the server that some
the sessions can not be stopped? To resend the stop request? But in that
case, a simpler way would be that the server could try to stop the sessions
again without any stop request resent from the client. The signalling could
be reduced in this way.
 
 
Regards,
Fortune