IETF Logo Mail Archive

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

Fortune HUANG <fqhuang@huawei.com> Mon, 22 March 2010 00:29 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 1DD3F3A6966 for <ippm@core3.amsl.com>; Sun, 21 Mar 2010 17:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.562
X-Spam-Level: **
X-Spam-Status: No, score=2.562 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_SIDE=2.3, RDNS_NONE=0.1]
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 UadbJkw82AME for <ippm@core3.amsl.com>; Sun, 21 Mar 2010 17:29:06 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B3A063A6955 for <ippm@ietf.org>; Sun, 21 Mar 2010 17:29:04 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZN00AEIQOIS0@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 22 Mar 2010 08:29:06 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KZN00ALOQOIDO@szxga04-in.huawei.com> for ippm@ietf.org; Mon, 22 Mar 2010 08:29:06 +0800 (CST)
Received: from h36145c ([10.70.39.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KZN00BLKQOIGF@szxml04-in.huawei.com> for ippm@ietf.org; Mon, 22 Mar 2010 08:29:06 +0800 (CST)
Date: Mon, 22 Mar 2010 08:29:06 +0800
From: Fortune HUANG <fqhuang@huawei.com>
In-reply-to: <76acda071003211048v4330a008mf92f5494c1800b72@mail.gmail.com>
To: 'Murtaza Chiba' <mchiba@gmail.com>, 'Al Morton' <acmorton@att.com>
Message-id: <005601cac956$aea41600$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_uAlh4xGXudQO/KgGuEVrQg)"
Thread-index: AcrJHrz3K8R9Ka5KR8qxLlCKrU0T1gANoxDQ
Cc: ippm@ietf.org
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (IndividualSession 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: Mon, 22 Mar 2010 00:29:07 -0000

Hi Murtaza, 
Hi Al,
 
Thank you very much for the explanations. I think I've had a better view on
this draft with your help now.
 
 
Regards,
Fortune
 
 

  _____  

From: Murtaza Chiba [mailto:mchiba@gmail.com] 
Sent: Monday, March 22, 2010 1:49 AM
To: Al Morton
Cc: Fortune HUANG; ippm@ietf.org
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl
(IndividualSession Control Feature for TWAMP) to Proposed Standard




On Thu, Mar 18, 2010 at 7:24 PM, Al Morton <acmorton@att.com> wrote:


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

[RFC4656 <http://tools.ietf.org/html/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.


Furthermore, if the Client assigns a SID it is not guaranteed to be unique
in the network. If the server assigns one, at the very least all the clients
that the server accepts connections from are guaranteed to have unique
identifiers.

Thanks,
-murtaza
 


Al



_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm

v2.23.0 | Report a Bug | By Email