Re: [NSIS] AD review of draft-ietf-nsis-y1541-qosm-07

Gerald Ash <gash5107@yahoo.com> Fri, 13 November 2009 22:29 UTC

Return-Path: <gash5107@yahoo.com>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E6923A684A for <nsis@core3.amsl.com>; Fri, 13 Nov 2009 14:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.042
X-Spam-Level:
X-Spam-Status: No, score=-100.042 tagged_above=-999 required=5 tests=[AWL=2.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 lKYpZhFV3Rnh for <nsis@core3.amsl.com>; Fri, 13 Nov 2009 14:29:46 -0800 (PST)
Received: from web63601.mail.re1.yahoo.com (web63601.mail.re1.yahoo.com [69.147.97.71]) by core3.amsl.com (Postfix) with SMTP id CE4533A67AA for <nsis@ietf.org>; Fri, 13 Nov 2009 14:29:45 -0800 (PST)
Received: (qmail 72839 invoked by uid 60001); 13 Nov 2009 22:30:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258151413; bh=y+CKwNhWtALiyoagxAPdV3OJRwyv4u3INptCrNBvctM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XfKezpiU2+Dtl1XK79lqDHNHAj2thplJ0+XIfJt9d0bzA9NXB4/IAekVbE/QDVKx7VhL98TMZ87jkYdwSu2P/SILD13zvAkqve2IQwRgqkHQ0LVYP8HSz4rtRSzoXqQ/Zx+gjf+oiwiXEWHkFUyqk8nsPGJJu0ppDbO8w9PJIhI=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HjtIE42kxdyngGrrWGnMC1EUGfcZmExHrOzfQc4VqpU1m+tbTloFFpUJT79oQmsgGCegu6MIca2S7uJFZUppQYyTToZshQGWN6mn18mMMacuCBhg2njhZO6lFMt+32ZXw4hDvHoYGFpANBR4XJVC5WivAofSNPZPHH3PRz0YMoM=;
Message-ID: <406754.72502.qm@web63601.mail.re1.yahoo.com>
X-YMail-OSG: 0X6ntdEVM1lHDKcGuvMOSTEb1S6vfl7lpgomLB2lOoNrS5YEmxCB0IIPido93D5t_JW4oOPCV8jVucvR6cIWA9vN.r7OjYJGC8Y5fK7jdR1QeTXPIwsgmI8UWBvPQaUk_hHGXrP7YDOV.kbInHe7bmJEWKx_BajK3xnfu62HP_XST0x3_6wRF8xbhyzwoe9wnYZNVzp0KSKPOQbLuoGS5mBKAGyMzVcawTVOHtRZ2tei3FrvozGL0vTzfda0Uhc9UHBeWMVStOdIHF_iIWmwVlpp52RBzpIzaMJdo0giUxkyZU8HnewrgZPdi9tCYteMKeXQOl4jj0f_VSK0zOdpzNta__q6gFgK3HYZM5u3j6EyxLtTFA1n1dcBwc6rMjECmFlyPn5edVcnj3SP72rA8R_Pyjzqbog-
Received: from [24.91.148.40] by web63601.mail.re1.yahoo.com via HTTP; Fri, 13 Nov 2009 14:30:13 PST
X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.7.361.4
Date: Fri, 13 Nov 2009 14:30:13 -0800
From: Gerald Ash <gash5107@yahoo.com>
To: NSIS <nsis@ietf.org>, Al Morton <acmorton@att.com>
In-Reply-To: <200911131954.nADJshfh007179@alpd052.aldc.att.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1974720766-1258151413=:72502"
Cc: draft-ietf-nsis-y1541-qosm@tools.ietf.org
Subject: Re: [NSIS] AD review of draft-ietf-nsis-y1541-qosm-07
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 22:29:47 -0000

I wasn't aware that Al Morton was taking this question to the list, so I would like to clarify the points I'm making regarding the dual token bucket parameter Bp:
 
1. The basis for including the parameter Bp is the ITU-T Recommendation "Signaling Requirements for IP-QoS" (available at http://www.itu.int/rec/T-REC-Q.Sup51/en), which REQUIRES the dual token bucket parameters (including Bp) for QoS signaling.  IMO if the the ITU doesn't want to require a dual token bucket for QoS signaling, they should revise the requirements.  Perhaps co-authors of the ITU-T QoS signaling requirements could comment.
 
2. Magnus only asked for a definition of Bp, which is readily available.  Magnus made no claim that Bp was too complex or any suggestion that the parameter should be removed.  But rather than simply providing the definition as requested, Al Morton has now decided that Bp is too complex and should be removed.
 
3. The intent of the Y.1541-QOSM document is to specify an NSIS QoS model (QOSM) based on all QoS signaling requirements contained in ITU-T recommendations, not only the Y.1541 QoS classes, but also the Q.Sup51 traffic model (TMOD) signaling requirements, and restoration priority signaling requirements.
 
Thanks,
Jerry 

--- On Fri, 11/13/09, Al Morton <acmorton@att.com> wrote:


From: Al Morton <acmorton@att.com>
Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>, draft-ietf-nsis-y1541-qosm@tools.ietf.org, "NSIS" <nsis@ietf.org>
Date: Friday, November 13, 2009, 2:54 PM


NSIS WG,

At 08:47 AM 10/16/2009, Magnus Westerlund wrote:
>3. Section 3.1: What are the definitions of the Bp and M parameter?

Those of us who have discussed Magnus' comment above are
trying to agree on a path forward.

Both parameters have standard definitions:
A reference definition for M, max datagram size, is in RFC 2212.
ITU-T Y.1221 seems to be the only standard where Bp,
the peak Bucket Size of a dual token bucket is specified.

I have proposed removing Bp because the additional complexity
of a dual token bucket is not essential to the main subject
of the draft (the Y.1541 classes).
I have asked at this week's ITU-T meeting, and the only implementors
of ITU-T Y.1221 indicated that they were not using Bp,
only the parameters for a single token bucket.

Jerry Ash would like to retain Bp, citing the informational
ITU-T Supplement referenced in the draft, and indicated that
dual token buckets are well-established and non-controversial.

Others have asked me to phrase the question to the list.
So, with the above background, should we simplify and drop Bp,
or keep it in?

thanks and regards,
Al