IETF Logo Mail Archive

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

Al Morton <acmorton@att.com> Fri, 19 March 2010 02:24 UTC

Return-Path: <acmorton@att.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 73D4F3A6C78 for <ippm@core3.amsl.com>; Thu, 18 Mar 2010 19:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.352
X-Spam-Level:
X-Spam-Status: No, score=-103.352 tagged_above=-999 required=5 tests=[AWL=-2.444, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3, MIME_HTML_ONLY=1.457, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ZhwgY4TKcfKh for <ippm@core3.amsl.com>; Thu, 18 Mar 2010 19:24:19 -0700 (PDT)
Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id BEC2C3A6C8D for <ippm@ietf.org>; Thu, 18 Mar 2010 19:24:17 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: acmorton@att.com
X-Msg-Ref: server-13.tower-167.messagelabs.com!1268965468!28900451!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 11191 invoked from network); 19 Mar 2010 02:24:29 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-13.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Mar 2010 02:24:29 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2J2OHeh032175 for <ippm@ietf.org>; Thu, 18 Mar 2010 22:24:17 -0400
Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o2J2ODPQ032133 for <ippm@ietf.org>; Thu, 18 Mar 2010 22:24:13 -0400
Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2J2ON9q014725 for <ippm@ietf.org>; Thu, 18 Mar 2010 21:24:23 -0500
Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o2J2OHtm014686 for <ippm@ietf.org>; Thu, 18 Mar 2010 21:24:18 -0500
Message-Id: <201003190224.o2J2OHtm014686@klpd017.kcdc.att.com>
Received: from acmt.att.com (vpn-135-70-233-24.vpn.east.att.com[135.70.233.24](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20100319022416gw100b8iihe>; Fri, 19 Mar 2010 02:24:17 +0000
X-Originating-IP: [135.70.233.24]
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 18 Mar 2010 22:24:21 -0400
To: Fortune HUANG <fqhuang@huawei.com>, ippm@ietf.org
From: Al Morton <acmorton@att.com>
In-Reply-To: <002401cac705$b5fd7110$4027460a@china.huawei.com>
References: <201003181355.o2IDtTDD010094@klpd017.kcdc.att.com> <002401cac705$b5fd7110$4027460a@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
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: Fri, 19 Mar 2010 02:24:20 -0000

At 09:44 PM 3/18/2010, Fortune HUANG wrote:
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.

Use of SID was decided in the OWAMP spec. We simply continue to
use it in TWAMP and it keeps the two specs similar.
 
[Fortune: I don't think we need redundant fields to keep the two specs similar, but I won't fight for it anyway. But could you tell me that if the server accepts the SID in the way as described above, please?]

Your scenario seems to have the Control-client assigning the SID.
That's not how the protocol works - the Server assigns the SID.
from RFC 5357, section 3.5:

   The Session Identifier (SID) is as defined in OWAMP
[http://tools.ietf.org/html/rfc4656" rel="nofollow">RFC4656].  Since
   the SID is always generated by the receiving side, the
Server
   determines the SID, and the SID in the Request-TW-Session
message
   MUST be set to 0.
Al

v2.23.0 | Report a Bug | By Email