IETF Logo Mail Archive

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

Murtaza Chiba <mchiba@gmail.com> Sun, 21 March 2010 17:48 UTC

Return-Path: <mchiba@gmail.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 0F0643A6863 for <ippm@core3.amsl.com>; Sun, 21 Mar 2010 10:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.832
X-Spam-Level:
X-Spam-Status: No, score=0.832 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 1Wz+RmUQJVRY for <ippm@core3.amsl.com>; Sun, 21 Mar 2010 10:48:24 -0700 (PDT)
Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id EE0A13A69F2 for <ippm@ietf.org>; Sun, 21 Mar 2010 10:48:23 -0700 (PDT)
Received: by ywh38 with SMTP id 38so2498032ywh.29 for <ippm@ietf.org>; Sun, 21 Mar 2010 10:48:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=j15e2nNwSEiIDSYzDLmoeHw9H3U5T7Me1wgh1KOA1+s=; b=ZWMPJG2ewAcsaFq+6EIpQfxyFf4kLIhHq6icIRywm5i1Nt2wp79CuC9fvE3jGMydrr X/gX3YsofaXk3NKxwAd6y2j4psEWEyxJr4b6pQ8RveQ2m+uz/9jNbBMWT11NuYA8hGxt ngQh+yfBrOCT7ZObIeWXsdwfDa2xn1CsdM/fM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ql2Rk6rZdfVMBJ96zjiv9C4WVp3JuL2JFscvFnsOmGiXwiAycoR+giPollp3mwB51l s1VCcEr/O/4URAhxNBSi5P1DsL9W7umGkPIQfWxiyvN60G0swFb2seghUqT/zcJ7Hjq6 GLs9lX9TwEv9MXYekbHx39IRPiRAHCBQdhZu8=
MIME-Version: 1.0
Received: by 10.100.55.22 with SMTP id d22mr13786079ana.82.1269193716898; Sun, 21 Mar 2010 10:48:36 -0700 (PDT)
In-Reply-To: <201003190224.o2J2OHtm014686@klpd017.kcdc.att.com>
References: <201003181355.o2IDtTDD010094@klpd017.kcdc.att.com> <002401cac705$b5fd7110$4027460a@china.huawei.com> <201003190224.o2J2OHtm014686@klpd017.kcdc.att.com>
Date: Sun, 21 Mar 2010 10:48:36 -0700
Message-ID: <76acda071003211048v4330a008mf92f5494c1800b72@mail.gmail.com>
From: Murtaza Chiba <mchiba@gmail.com>
To: Al Morton <acmorton@att.com>
Content-Type: multipart/alternative; boundary="0016e6476278a59c5b0482533040"
Cc: ippm@ietf.org
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: Sun, 21 Mar 2010 17:48:25 -0000

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