From karthikbalaguru79@gmail.com Wed Dec 2 09:08:58 2009 Return-Path: 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 B843A3A6ABC for ; Wed, 2 Dec 2009 09:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GJWCSPnPFmVx for ; Wed, 2 Dec 2009 09:08:58 -0800 (PST) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by core3.amsl.com (Postfix) with ESMTP id 07DBE3A6953 for ; Wed, 2 Dec 2009 09:08:57 -0800 (PST) Received: by pzk40 with SMTP id 40so298349pzk.7 for ; Wed, 02 Dec 2009 09:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=COnkG5V5lTnw0Wb5rnKgactZdmr7FeWWZwPHy2UcQTI=; b=aE34F7QTnd7NYb8BhWP99n1A0Q5I4vTFN3y8Dg4XFWT3duVW9S6XUQrLnVQV+qnnGr UR6vmtduaNDnzvuZampJAuI6ZD03BD7y3lS/CbM/jrKXUUPqfOfwtsXWyjxwAHr6DkSN 0hsieaCjr9wCZTDxyfZQbiPQawYCkaOZR5SGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=v75jE5N8wunuLQNkK7/Ap+pZic1NT0D+01PygFSxEbZzhBC3+OBCBQK3ZSTclkgGE4 CC2FiQqdMTzzfLJJHOEe2nMqKztKxgCfA45YD+EXvs1xOKpF72MgkSd2//C8WGugFDff rUebUwA44sONkMOfCdOAJlqhpw+qS0e1dk4tU= MIME-Version: 1.0 Received: by 10.143.26.36 with SMTP id d36mr37009wfj.217.1259773725725; Wed, 02 Dec 2009 09:08:45 -0800 (PST) Date: Wed, 2 Dec 2009 22:38:45 +0530 Message-ID: <53b627ea0912020908n41d94a8dw7f3304ed2b507fa7@mail.gmail.com> From: Karthik Balaguru To: nsis@ietf.org Content-Type: multipart/alternative; boundary=001636e0add76b54840479c1edf9 Subject: [NSIS] Regd 3GPP QoS Model for Networks Using 3GPP QoS Classes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 17:08:58 -0000 --001636e0add76b54840479c1edf9 Content-Type: text/plain; charset=ISO-8859-1 Hi, I find only the draft version of draft-jeong-nsis-3gpp-qosm-02.txt . What is the latest development w.r.t '3GPP QoS Model for Networks Using 3GPP QoS Classes'. Any other related/alternative RFC available for this ? Thx in advans, Karthik Balaguru --001636e0add76b54840479c1edf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
I find only the draft version of draft-jeong-nsis-3gpp-qosm-02.txt .=
What is the latest development w.r.t '3GPP QoS Model for Networks U= sing 3GPP QoS Classes'.
Any other related/alternative RFC available = for this ?
=A0
Thx in advans,
Karthik Balaguru --001636e0add76b54840479c1edf9-- From root@core3.amsl.com Thu Dec 3 08:30:02 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 379C73A67FA; Thu, 3 Dec 2009 08:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091203163002.379C73A67FA@core3.amsl.com> Date: Thu, 3 Dec 2009 08:30:02 -0800 (PST) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-tunnel-07.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 16:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : NSIS Operation Over IP Tunnels Author(s) : C. Shen, et al. Filename : draft-ietf-nsis-tunnel-07.txt Pages : 26 Date : 2009-12-03 NSIS QoS signaling enables applications to perform QoS reservation along a data flow path. When the data flow path contains IP tunnel segments, NSIS QoS signaling has no effect within those tunnel segments and the resulting QoS-untended tunnel segments could become the weakest QoS link and invalidate the QoS efforts in the rest of the end-to-end path. The problem with NSIS signaling within the tunnel is caused by the tunnel encapsulation which masks packets' original IP header fields. Those original IP header fields are needed to intercept NSIS signaling messages and classify QoS data packets. This document defines a solution to this problem by mapping end-to-end QoS session requests to corresponding QoS sessions in the tunnel, thus extending the end-to-end QoS signaling into the IP tunnel segments. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-nsis-tunnel-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-03082738.I-D@ietf.org> --NextPart-- From magnus.westerlund@ericsson.com Mon Dec 7 02:29:51 2009 Return-Path: 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 B1AF53A681F for ; Mon, 7 Dec 2009 02:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 ESnyotRP0Ijy for ; Mon, 7 Dec 2009 02:29:51 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6D8433A67BD for ; Mon, 7 Dec 2009 02:29:50 -0800 (PST) X-AuditID: c1b4fb3c-b7b8dae0000047e9-93-4b1cd80a50cd Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7F.64.18409.A08DC1B4; Mon, 7 Dec 2009 11:25:14 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 11:25:00 +0100 Received: from [147.214.183.163] ([147.214.183.163]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 11:25:00 +0100 Message-ID: <4B1CD7FB.20402@ericsson.com> Date: Mon, 07 Dec 2009 11:24:59 +0100 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: NSIS X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 07 Dec 2009 10:25:00.0055 (UTC) FILETIME=[87E08A70:01CA7727] X-Brightmail-Tracker: AAAAAA== Subject: [NSIS] Intended status for draft-ietf-nsis-qspec X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 10:29:51 -0000 Hi, It was raised by Joel Halpern in his Gen-art review and I personally have question marks about the intended status of Informational. I think it would make more sense to publish this document as Experimental. Please voice your opinion. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jmanner@cc.hut.fi Mon Dec 7 08:34:25 2009 Return-Path: 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 C299F3A6821 for ; Mon, 7 Dec 2009 08:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.372 X-Spam-Level: X-Spam-Status: No, score=-6.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 YQeLc02Yj9U7 for ; Mon, 7 Dec 2009 08:34:25 -0800 (PST) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by core3.amsl.com (Postfix) with ESMTP id C101E3A67F0 for ; Mon, 7 Dec 2009 08:34:24 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id nB7GYCj2010278; Mon, 7 Dec 2009 18:34:12 +0200 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 25055-236-7; Mon, 7 Dec 2009 18:34:11 +0200 (EET) Received: from vipunen.hut.fi (vipunen.hut.fi [130.233.228.9]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id nB7GPAlo008185; Mon, 7 Dec 2009 18:25:10 +0200 Date: Mon, 7 Dec 2009 18:25:10 +0200 (EET) From: Jukka MJ Manner To: Magnus Westerlund In-Reply-To: <2727_1260182045_ZZ0KUA000FL2O0FR.00_4B1CD7FB.20402@ericsson.com> Message-ID: References: <2727_1260182045_ZZ0KUA000FL2O0FR.00_4B1CD7FB.20402@ericsson.com> User-Agent: Alpine 1.99 (SOC 1136 2008-08-12) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: NSIS Subject: Re: [NSIS] Intended status for draft-ietf-nsis-qspec X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 16:34:25 -0000 I don't see that much difference. Since all nsis specs are going for exp, i guess qspec might as well. Jukka On Mon, 7 Dec 2009, Magnus Westerlund wrote: > Hi, > > It was raised by Joel Halpern in his Gen-art review and I personally > have question marks about the intended status of Informational. I think > it would make more sense to publish this document as Experimental. > > Please voice your opinion. > > Cheers > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis > From jukka.manner@tkk.fi Mon Dec 7 21:24:21 2009 Return-Path: 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 7EEEC3A6847 for ; Mon, 7 Dec 2009 21:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.772 X-Spam-Level: X-Spam-Status: No, score=-5.772 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] 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 2l18BdVk9TrI for ; Mon, 7 Dec 2009 21:24:19 -0800 (PST) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by core3.amsl.com (Postfix) with ESMTP id A76573A6800 for ; Mon, 7 Dec 2009 21:24:18 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id nB85O6mt019283; Tue, 8 Dec 2009 07:24:06 +0200 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 08825-279-3; Tue, 8 Dec 2009 07:24:06 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id nB85N2Gm019152; Tue, 8 Dec 2009 07:23:02 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id D7EB01E159; Tue, 8 Dec 2009 07:23:01 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7qAMdL0wEugU; Tue, 8 Dec 2009 07:22:57 +0200 (EET) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 3701F1E018; Tue, 8 Dec 2009 07:22:57 +0200 (EET) Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 9AC9E120050; Tue, 8 Dec 2009 07:22:51 +0200 (EET) Message-ID: <4B1DE2B1.6040302@tkk.fi> Date: Tue, 08 Dec 2009 07:22:57 +0200 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerald Ash References: <1890_1259601258_ZZ0KTX0090EMJ97W.00_58192.32970.qm@web63605.mail.re1.yahoo.com> In-Reply-To: <1890_1259601258_ZZ0KTX0090EMJ97W.00_58192.32970.qm@web63605.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: nsis@ietf.org Subject: Re: [NSIS] Maximum Packet Size Parameter -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 05:24:21 -0000 To me it seems like we need it back, although I'm no expert in formal QoS specifications. Jukka Gerald Ash wrote: > All, > > Al Morton has recently raised concerns RE taking the Maximum Packet > Size parameter out of the QSPEC document. Based on his comments > (given below, along with other background), it appears that the > parameter should be put back into the QSPEC. > > Please comment on whether the parameter should be put back into the > QSPEC. > > Thanks, > Jerry > > _Background:_ > > The Maximum Packet Size Parameter was taken out back in July 2005 in > QSPEC version 5, with the following explanation in the change history: > > " Version -05: > > - discarded QSPEC parameter (Maximum packet size) since MTU > discovery is expected to be handled by procedure currently defined > by PMTUD WG" > > Some further explanation for removing the parameter is given in a > message posted by Cornelia Kappler on the IETF web-site at > http://www.ietf.org/mail-archive/web/nsis/current/msg07923.html: > > "AW: [NSIS] smallest path MTU - Maximum Packet Size [M] > ------------------------------------------------------------------------ > > * /To/: "ext Bernd Schloer" , > > * /Subject/: AW: [NSIS] smallest path MTU - Maximum Packet Size [M] > * /From/: "Kappler, Cornelia" > * /Date/: Fri, 1 Jun 2007 09:53:50 +0200 > * /Cc/: > * /In-reply-to/: <465C9BAE.1050505@cs.uni-goettingen.de > > > * /List-help/: > * /List-id/: Next Steps in Signaling > > * /List-post/: > * /List-subscribe/: , > > * /List-unsubscribe/: , > > * /References/: <465C9BAE.1050505@cs.uni-goettingen.de > > > * /Thread-index/: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Qufg > * /Thread-topic/: [NSIS] smallest path MTU - Maximum Packet Size [M] > > ------------------------------------------------------------------------ > > Hi all, > > at the Interim meeting in May 2005 we decided to drop the MTU, see http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html > > Cornelia > >> -----Ursprüngliche Nachricht----- >> Von: ext Bernd Schloer [mailto:bschloer at cs.uni-goettingen.de ] >> Gesendet: Dienstag, 29. Mai 2007 23:31 >> An: nsis at ietf.org >> Betreff: [NSIS] smallest path MTU - Maximum Packet Size [M] >> >> Hi, >> >> in version 13 of the QSPEC-draft the Maximum Packet Size [M] >> was removed from the >> TMOD parameter (former Traffic parameter). >> >> RFC2211 mentions, that links are not permitted to fragment >> packets which receive >> the controlled-load service and packets larger than the MTU >> of the link are treated >> as non-conformant to the TSPEC. >> >> What was the reason to omit this parameter? >> >> Best regards, >> Bernd" > > Hannes Tschofenig kindly provided links to the Munich Interim Meeting > Minutes at > http://www.tschofenig.priv.at/nsis/munich/MeetingMinutes.html > > It appears that the discussion of MTU discovery somehow led to a > conclusion that the maximum packet size parameter should be > eliminated as well, as documented in this portion of the minutes: > > "A QoS Model for Signaling IntServ Controlled-Load Service with NSIS > =================================================================== > > http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledload-01.txt > > Slides: > http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/Ctrld_Load_QOSM_Interim_Munich.ppt > > Cornelia Kappler presents and she starts with an overview of IntServ. > > What is IntServ Controlled-Load service? > -IntServ Controlled Load Service is (in NSIS terms) a QoS Model > -RFC 2210 specifies how to signal for Controled load using RSVP > -This ID specifies how to signal for Controled Load using NSIS > -Controlled-Load Service (RFC 2211) > -Provides approximatively service of an unloaded best-effort network > -QoS parameters signaled are Token Bucket and MTU > -Implemented per "network element", i.e. per-router or per-subnet > Can be used for > Reserving resources per-flow per-router > Admission control at edge of Diffserv domains > Admission control into MPLS clouds > > How to signal for Controlled Load service with NSIS > -Role of QNEs > -One or more QNR per "network element" > -Stateless QNEs? > -Provide approximatively service of an uiloaded best-effort network may > also be possible with stateless QNEs > > Discussion started about MTU insertion in the QoS NSLP since not all > routers would be supporting the NSIS Qos NSLP it was decided to remove > the MTU discovery from controlled load and Qos-NSLP draft. If required > MTU discovery would be using mechanisms out of scope of NSIS (PMTUD or > other)" > > Bernd Schloer raised the concern of eliminating in his message > referenced above: > > "In version 13 of the QSPEC-draft the Maximum Packet Size [M] was > removed from the TMOD parameter (former Traffic parameter). > RFC2211 mentions, that links are not permitted to fragment packets which > receive the controlled-load service and packets larger than the MTU of > the link are treated as non-conformant to the TSPEC. > What was the reason to omit this parameter?" > > Al Morton raised the same and additional concerns in a recent discussion: > > "It seems to me that several points were missed > by citing the Packetization Layer Path MTU Discovery (PLPMTUD) > [note: see RFC 4821 http://www.rfc-editor.org/rfc/rfc4821.txt] > as a replacement for specifying M, Max Pkt size: > > - only the sending end-point will store what PLPMTUD discovers, > intermediate points where shaping or policing reside will not > know the Max pkt size the sender intends to use. > > - the Max packet size that a sender uses may be much less than MTU, > VoIP is the most obvious example. > > Or, it wasn't understood that M was a critical part of the peak > rate definition. From RFC 2212: > The peak rate, p, is measured in bytes of IP datagrams per second and > has the same range and suggested representation as the bucket rate. > The peak rate is the maximum rate at which the source and any > reshaping points (reshaping points are defined below) may inject > bursts of traffic into the network. More precisely, it is a > requirement that for all time periods the amount of data sent cannot > exceed M+pT where M is the maximum datagram size and T is the length > of the time period. > > Note that parameter M is part of the RFC 2212 TSPEC, and M is apparently > different from the MTU: > Links are not permitted to fragment datagrams as part of guaranteed > service. Datagrams larger than the MTU of the link MUST be policed > as non-conformant which means that they will be policed according to > the rules described in the Policing section below." > > It seems that Bernd and Al have raised valid concerns: discovery of MTU > does not eliminate the need to specify in the TMOD parameter. It > appears that the parameter should be put back in the QSPEC. It > should not be a big issue since was already there in the QSPEC up > through version 4 (see > http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-04.txt). > > > > --- On *Wed, 11/11/09, The IESG //* wrote: > > > From: The IESG > Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC > Template) to Informational RFC > To: "IETF-Announce" > Cc: nsis@ietf.org > Date: Wednesday, November 11, 2009, 4:09 AM > > The IESG has received a request from the Next Steps in Signaling WG > (nsis) to consider the following document: > > - 'QoS NSLP QSPEC Template ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org > mailing > lists by 2009-11-25. Exceptionally, > comments may be sent to iesg@ietf.org > > instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-22.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12323&rfc_flag=0 > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > > https://www.ietf.org/mailman/listinfo/nsis > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+451 2474 and Networking (Comnet) Office: G320 (Otakaari 5A) P.O. Box 3000, FIN-02015 TKK E-mail: jukka.manner@tkk.fi Finland WWW: www.comnet.tkk.fi From jukka.manner@tkk.fi Mon Dec 7 21:28:08 2009 Return-Path: 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 E195D3A6800 for ; Mon, 7 Dec 2009 21:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 5ErN3AEKK3Oy for ; Mon, 7 Dec 2009 21:28:07 -0800 (PST) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id 427603A67B4 for ; Mon, 7 Dec 2009 21:28:06 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id nB85RmuB027079; Tue, 8 Dec 2009 07:27:48 +0200 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 06123-228; Tue, 8 Dec 2009 07:27:48 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id nB85RYKG027045; Tue, 8 Dec 2009 07:27:34 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id E597F1E159; Tue, 8 Dec 2009 07:27:33 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ldAZBy0K6HA6; Tue, 8 Dec 2009 07:27:29 +0200 (EET) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id A3B751E018; Tue, 8 Dec 2009 07:27:29 +0200 (EET) Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id 1D590120050; Tue, 8 Dec 2009 07:27:24 +0200 (EET) Message-ID: <4B1DE3C1.7040209@tkk.fi> Date: Tue, 08 Dec 2009 07:27:29 +0200 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gerald Ash References: <2727_1259611345_ZZ0KTX000RBUBSGV.00_53366.64256.qm@web63604.mail.re1.yahoo.com> In-Reply-To: <2727_1259611345_ZZ0KTX000RBUBSGV.00_53366.64256.qm@web63604.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: draft-ietf-nsis-y1541-qosm@tools.ietf.org, NSIS , David Black Subject: Re: [NSIS] Dual Token Bucket Requirements -- Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 05:28:09 -0000 As long as an implementer is able to leave with the dual token bucket spec, that is enough for me. If I need to choose, I'd typically take the simpler approach of two options, and would remove the Bp, but I don't have a strong opinion either way. If no one really objects, we'll just keep the Bp since it is has been in the spec for quite some time. Jukka Gerald Ash wrote: > All, > > The draft > http://www.ietf.org/id/draft-ietf-nsis-y1541-qosm-07.txt currently > requires a dual token bucket and peak bucket size parameter (Rp) be > specified. However, in expired draft > http://tools.ietf.org/id/draft-vaananen-mpls-svc-diff-framework-00.txt, > it says: > > " - Three color marker based service [RFC 2697, RFC 2698]: Here the > customerÆs traffic is marked with one of three colors (using a dual > token bucket scheme) and the packets marked with each color are > guaranteed a certain maximum loss probability. Practically this > could mean that packets conforming to committed rate specification > have better delivery guarantee than those that exceed it." > > Since the QSPEC draft > (http://www.ietf.org/id/draft-ietf-nsis-qspec-22.txt) currently provides > 2 TMOD parameters to accommodate the 3-color marker based service, it > appears that a dual token bucket capability is already provided by the > QSPEC and there is no further need to specify the Rp parameter in the > Y.1541-QOSM draft. It would be up to an individual QOSM specification > to detail the use of the 2 TMOD parameters to achieve a dual token bucket. > > Comments? > > Thanks, > Jerry > > > --- On *Fri, 11/13/09, Gerald Ash //* wrote: > > > From: Gerald Ash > Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07 > To: "NSIS" , "Al Morton" > Cc: "Jerry Ash" , "Magnus Westerlund" > , > draft-ietf-nsis-y1541-qosm@tools.ietf.org > Date: Friday, November 13, 2009, 5:30 PM > > 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 //* wrote: > > > From: Al Morton > Subject: Re: AD review of draft-ietf-nsis-y1541-qosm-07 > To: "Magnus Westerlund" , > draft-ietf-nsis-y1541-qosm@tools.ietf.org, "NSIS" > 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 > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www.ietf.org/mailman/listinfo/nsis -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Mobile: +358+(0)50+5112973 Department of Communications Fax: +358+(0)9+451 2474 and Networking (Comnet) Office: G320 (Otakaari 5A) P.O. Box 3000, FIN-02015 TKK E-mail: jukka.manner@tkk.fi Finland WWW: www.comnet.tkk.fi From karagian@cs.utwente.nl Mon Dec 7 22:51:16 2009 Return-Path: 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 7D1C128C0FD; Mon, 7 Dec 2009 22:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.719 X-Spam-Level: * X-Spam-Status: No, score=1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227] 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 cBEjzg+MBMDd; Mon, 7 Dec 2009 22:51:14 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 7947B3A69D1; Mon, 7 Dec 2009 22:51:13 -0800 (PST) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id nB86ou1c021314; Tue, 8 Dec 2009 07:50:56 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 08 Dec 2009 06:50:56 +0000 To: "Gerald Ash" , "IETF-Announce" , "ietf@ietf.org" , "nsis@ietf.org" Date: Tue, 08 Dec 2009 06:50:56 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <58192.32970.qm@web63605.mail.re1.yahoo.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 08 Dec 2009 07:51:00 +0100 (MET) Subject: [NSIS] Maximum Packet Size Parameter -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 06:51:17 -0000 Hi Jerry I think that the reason of removing the "Maximum Packet Size [M] (32-bit unsigned integer)" parameter from the QSPEC specification was that this parameter is only relevant for some QoS models that are used on an end-to-end basis, such as Y.1541 QOSM. I would therefore prefer that this parameter should not be specified in the QSPEC draft. In my opinion this parameter should be specified as an TMOD extension in any QoS model that needs it. I believe that Y.1541 QOSM already does specify the "Maximum Packet Size [M] (32-bit unsigned integer)" parameter in Section 3.1. Best regards, Georgios On 11/30/2009, "Gerald Ash" wrote: >All, >=A0 >Al Morton has recently raised=A0concerns=A0RE taking the Maximum Packet Size= =A0 parameter out of the QSPEC document.=A0 Based on his comments (given b= elow, along with other background), it appears that the parameter should = be put back into the QSPEC. >=A0 > >Please comment on=A0whether=A0the parameter should be put back into the = QSPEC. >=A0 >Thanks, >Jerry >=A0 >Background: >=A0 >The Maximum Packet Size Parameter =A0was taken out back in July 2005 in Q= SPEC version 5, with the following explanation in the change history: > > >=A0 >" =A0 Version -05: > >=A0=A0 - discarded QSPEC parameter (Maximum packet size) since MTU >=A0=A0=A0=A0 discovery is expected to be handled by procedure currently defi= ned >=A0=A0=A0=A0 by PMTUD WG" >=A0 >Some further=A0explanation for removing the parameter =A0is=A0given=A0in = a message posted by=A0Cornelia Kappler on the IETF web-site=A0at http://www.i= etf.org/mail-archive/web/nsis/current/msg07923.html: >=A0 >"AW: [NSIS] smallest path MTU - Maximum Packet Size [M] > > > > >To: "ext Bernd Schloer" , =20 >Subject: AW: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 >From: "Kappler, Cornelia" =20 >Date: Fri, 1 Jun 2007 09:53:50 +0200=20 >Cc:=20 >In-reply-to: <465C9BAE.1050505@cs.uni-goettingen.de>=20 >List-help: =20 >List-id: Next Steps in Signaling =20 >List-post: =20 >List-subscribe: , =20 >List-unsubscribe: , =20 >References: <465C9BAE.1050505@cs.uni-goettingen.de>=20 >Thread-index: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Qufg=20 >Thread-topic: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 > >Hi all,=20 > >at the Interim meeting in May 2005 we decided to drop the MTU, see http://w= ww.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html=20 > >Cornelia=20 > >> -----Urspr=FCngliche Nachricht----- >> Von: ext Bernd Schloer [mailto:bschloer at cs.uni-goettingen.de]=20 >> Gesendet: Dienstag, 29. Mai 2007 23:31 >> An: nsis at ietf.org >> Betreff: [NSIS] smallest path MTU - Maximum Packet Size [M] >>=20 >> Hi, >>=20 >> in version 13 of the QSPEC-draft the Maximum Packet Size [M]=20 >> was removed from the >> TMOD parameter (former Traffic parameter). >>=20 >> RFC2211 mentions, that links are not permitted to fragment=20 >> packets which receive >> the controlled-load service and packets larger than the MTU=20 >> of the link are treated >> as non-conformant to the TSPEC. >>=20 >> What was the reason to omit this parameter? >>=20 >> Best regards, >> Bernd" >Hannes Tschofenig kindly provided links to the Munich Interim Meeting Minute= s at > >http://www.tschofenig.priv.at/nsis/munich/MeetingMinutes.html >=A0 >It appears that the discussion of MTU discovery somehow led to a conclusion = that the maximum packet size parameter should be eliminated as well, as d= ocumented in this portion of the minutes: >=A0 >"A QoS Model for Signaling IntServ Controlled-Load Service with NSIS >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledlo= ad-01.txt=20 >Slides: http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/Ctrld_Load_QOSM= _Interim_Munich.ppt > >Cornelia Kappler presents and she starts with an overview of IntServ. > >What is IntServ Controlled-Load service? >-IntServ Controlled Load Service is (in NSIS terms) a QoS Model >-RFC 2210 specifies how to signal for Controled load using RSVP >-This ID specifies how to signal for Controled Load using NSIS >-Controlled-Load Service (RFC 2211) >-Provides approximatively service of an unloaded best-effort network >-QoS parameters signaled are Token Bucket and MTU >-Implemented per "network element", i.e. per-router or per-subnet >Can be used for=20 >Reserving resources per-flow per-router >Admission control at edge of Diffserv domains >Admission control into MPLS clouds > >How to signal for Controlled Load service with NSIS >-Role of QNEs >-One or more QNR per "network element" >-Stateless QNEs? >-Provide approximatively service of an uiloaded best-effort network may also= be possible with stateless QNEs > >Discussion started about MTU insertion in the QoS NSLP since not all routers= would be supporting the NSIS Qos NSLP it was decided to remove the MTU disco= very from controlled load and Qos-NSLP draft. If required MTU discovery would= be using mechanisms out of scope of NSIS (PMTUD or other)" >=A0 >Bernd Schloer raised the concern of eliminating in his message reference= d above: >=A0 >"In version 13 of the QSPEC-draft the Maximum Packet Size [M]=A0was removed = from the TMOD parameter (former Traffic parameter). > >RFC2211 mentions, that links are not permitted to fragment=A0packets which r= eceive the controlled-load service and packets larger than the MTU=A0of the l= ink are treated as non-conformant to the TSPEC. > >What was the reason to omit this parameter?" >=A0 >Al Morton raised=A0the same and additional concerns in a recent discussion: >=A0 >"It seems to me that=A0 several points were missed >by citing the Packetization Layer Path MTU Discovery (PLPMTUD) >[note: see RFC 4821 http://www.rfc-editor.org/rfc/rfc4821.txt] >as a replacement for specifying M, Max Pkt size: > >=A0-=A0 only the sending end-point will store what PLPMTUD discovers, >=A0=A0=A0 intermediate points where shaping or policing reside will not >=A0=A0=A0 know the Max pkt size the sender intends to use. > >=A0-=A0 the Max packet size that a sender uses may be much less than MTU, >=A0=A0=A0 VoIP is the most obvious example. > >Or, it wasn't understood that M was a critical part of the peak=20 >rate definition.=A0 From RFC 2212: >=A0=A0 The peak rate, p, is measured in bytes of IP datagrams per second and >=A0=A0 has the same range and suggested representation as the bucket rate. >=A0=A0 The peak rate is the maximum rate at which the source and any >=A0=A0 reshaping points (reshaping points are defined below) may inject >=A0=A0 bursts of traffic into the network.=A0 More precisely, it is a >=A0=A0 requirement that for all time periods the amount of data sent cannot >=A0=A0 exceed M+pT where M is the maximum datagram size and T is the length >=A0=A0 of the time period.=20 > >Note that parameter M is part of the RFC 2212 TSPEC, and M is apparently >different from the MTU: >=A0=A0 Links are not permitted to fragment datagrams as part of guaranteed >=A0=A0 service.=A0 Datagrams larger than the MTU of the link MUST be policed >=A0=A0 as non-conformant which means that they will be policed according to >=A0=A0 the rules described in the Policing section below." >=A0 >It seems that Bernd and Al have=A0raised valid concerns: discovery of MTU do= es not=A0eliminate the need to specify in the TMOD parameter.=A0 It appea= rs that the parameter should be put back in the QSPEC.=A0 It should not b= e a big issue since=A0 was already there in the QSPEC up through version 4= (see http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-04.txt). >=A0=A0 > > >--- On Wed, 11/11/09, The IESG wrote: > > >From: The IESG >Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) t= o Informational RFC >To: "IETF-Announce" >Cc: nsis@ietf.org >Date: Wednesday, November 11, 2009, 4:09 AM > > >The IESG has received a request from the Next Steps in Signaling WG=20 >(nsis) to consider the following document: > >- 'QoS NSLP QSPEC Template ' >=A0=A0=A0 as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action.=A0 Please send substantive comments to the >ietf@ietf.org mailing lists by 2009-11-25. Exceptionally,=20 >comments may be sent to iesg@ietf.org instead. In either case, please=20 >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-22.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=3D= 12323&rfc_flag=3D0 > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www.ietf.org/mailman/listinfo/nsis > > > > ) From gash5107@yahoo.com Thu Dec 10 08:39:33 2009 Return-Path: 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 B0D3B3A6A0D for ; Thu, 10 Dec 2009 08:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.58 X-Spam-Level: X-Spam-Status: No, score=-101.58 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=0.6, SARE_SUB_OBFU_Q1=0.227, 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 TJDNoawDnebm for ; Thu, 10 Dec 2009 08:39:30 -0800 (PST) Received: from web63608.mail.re1.yahoo.com (web63608.mail.re1.yahoo.com [69.147.97.78]) by core3.amsl.com (Postfix) with SMTP id 96C103A69F4 for ; Thu, 10 Dec 2009 08:39:30 -0800 (PST) Received: (qmail 51122 invoked by uid 60001); 10 Dec 2009 16:39:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260463156; bh=x9COfjP3Qw3rz7eDCKe+sxDsZ5CnxFEcXg7WslSuDfM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kTgs9jkydxsiwbCoN6Jc+X39MVAR/EZgyzYCSfTI3FjbfHQ1dhsvlEaFbwMp+LbKv+rEdQiVEhA2irTeT0SXm72ouRnv1U80qXAs1acIZXsa094MVctBcnPD5VOilgDf928Xqqc4aRpDjd6CVqI8u1gKaHttJEIEsql6kTTjcJM= 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=HYwQa5J5M3vqN9gDGbU9jg/nfzypTFb1m42sKGFPjTVa5iAICIkojOUGpx6poVGKLAjTdJAB6ogd7PUOKv2HjhTIIRuYvRFN5srf067E6fRLUsJfFF8TasxLg+173LC6v29HF9vSS+o3IPnSru7A6JX6MLeQipRxew60ztwph+U=; Message-ID: <571767.51018.qm@web63608.mail.re1.yahoo.com> X-YMail-OSG: 0EdrolgVM1m.74C.43z8YgyXXepTAOrDZFZ6mxcVOKNACcdONvkrnGV1gZW49yvJnXWahVTW20tWYa9t94HMo4lbPFc4.JwNeXic3JjvdYYe9tOFkNA_N_Vk4IW.fA9_5seKqZTPL7EodicwhT06_wIpM0__U8SxHHJ2hF2Bk7XMr0iY1Pl9AVoaqzcVfR5Cg5eXj0NjNAfMHu2eTVOkfv4v7dSnDQHjNtXfTO9svfNVxfhv2itm_qVKkJn_ZIrHUxxVcEMe5rUX1sbhYTgKjKGf8WiQZneMHjKa8EAnzuQeTUhtVOnnLozYH5.i_iL.W6ybEi_5OdL6T5.Bgs1cKMj4EkxjdrYqeF99TuemPNnQgv.gm7Pb7Vsu5wO4lpul7TdRg_ONF20VAnIej1fkrVaqlsi8S.435XaF1hj544uPg14jLsy.RldBm1amPegRs90hagSQ3f06SgEBoePPaD3LWnzEyEAypV_16kZTsJIfkzy2v1U6JEknywO2rcC0IWKYCZ5m9OZrvDMtfQPIQKH151YVlHH3rXPTsKlKJhg6qBpfzNy_02fkIAOdi97qoH0C9oJZh6z2jGR0AlXk5s29.H9TNwoBYzBk7EYo27.opchpaT9F2tyIR2u3l5k43Uv__tqoKwWRum9NTIh78yuIalV9U693g7c_EDxdBFslm5H.QhyACJENPHrcO23RAKrWXR0q1goT8Y27HbURgdM3MyGTiPyPz_i0nVwQN9avF.xOuG7XeFsx0E6gQDKqvnbVAIhZhwtdm9WNV4FYu6ZtFDs9MFJb1ZEPypeLLy3j86lk50jO2pzFk26fb193A3U1lzLg1JpmmQtAOJculNCICdraCJWg03eHIsnFhh0duc_KvdeZqrGpnFeycNp6dm53FtU08QGzt0aOnqWY4t5JPpoaGeTapOmKGUZAugGmVc58PskTS4V2hfl.EyiWOBQ- Received: from [24.91.148.40] by web63608.mail.re1.yahoo.com via HTTP; Thu, 10 Dec 2009 08:39:16 PST X-Mailer: YahooMailClassic/9.0.19 YahooMailWebService/0.8.100.260964 Date: Thu, 10 Dec 2009 08:39:16 -0800 (PST) From: Gerald Ash To: Georgios Karagiannis In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1500372816-1260463156=:51018" Cc: "nsis@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [NSIS] Maximum Packet Size Parameter -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:39:33 -0000 --0-1500372816-1260463156=:51018 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Georgios, =A0 The maximum packet size (M) sub-parameter is a required element of the traf= fic model (TMOD) parameter specified in the QSPEC.=A0 TMOD is modeled after= the RSVP Tspec parameter (see RFC 2210=A0http://www.rfc-editor.org/rfc/rfc= 2210.txt=A0and RFC 2212 http://www.rfc-editor.org/rfc/rfc2212.txt), which c= onsists of 5 sub-parameters:=20 =A0 rate (r) bucket size (b) peak rate (p) minimum policed unit (m) maximum packet size (M) =A0 The TMOD parameter=A0is mandatory for the QNI to include in the initiator Q= SPEC and mandatory for downstream QNEs to interpret.=A0 As such, the TMOD p= arameter and M sub-parameter apply to ALL QOSM's, including Y.1541, RMD, et= c., and must be used by them. =A0 As explained in the attached email below, the M sub-parameter was erroneous= ly=A0removed from the QSPEC in version 5 when it was incorrectly assumed th= at automatic discovery of MTU would also apply to M.=A0 It does not, MTU=A0= and M are not the same parameter.=A0 Fortunately this error was recently br= ought to our attention by Al Morton (and earlier by Bernd Schloer). =A0 Therefore M needs to be put back in the QSPEC, as Jukka has correctly agree= d. =A0 Thanks, Jerry --- On Tue, 12/8/09, Georgios Karagiannis wrote: From: Georgios Karagiannis Subject: [NSIS] Maximum Packet Size Parameter -- Re: Last Call: draft-i= etf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC To: "Gerald Ash" , "IETF-Announce" , "ietf@ietf.org" , "nsis@ietf.org" Date: Tuesday, December 8, 2009, 1:50 AM Hi Jerry I think that the reason of removing the=A0 "Maximum Packet Size [M] (32-bit unsigned integer)" parameter from the QSPEC specification was that this parameter is only relevant for some QoS models that are used on an end-to-end basis, such as Y.1541 QOSM. I would therefore prefer that this parameter should not be specified in the QSPEC draft. In my opinion this parameter should be specified as an TMOD extension in any QoS model that needs it. I believe that Y.1541 QOSM already does specify the "Maximum Packet Size [M] (32-bit unsigned integer)" parameter in Section 3.1. Best regards, Georgios On 11/30/2009, "Gerald Ash" wrote: >All, >=A0 >Al Morton has recently raised=A0concerns=A0RE taking the Maximum Packet Si= ze=A0 parameter out of the QSPEC document.=A0 Based on his comments (giv= en below, along with other background), it appears that the parameter s= hould be put back into the QSPEC. >=A0 > >Please comment on=A0whether=A0the parameter should be put back into th= e QSPEC. >=A0 >Thanks, >Jerry >=A0 >Background: >=A0 >The Maximum Packet Size Parameter =A0was taken out back in July 2005 in= QSPEC version 5, with the following explanation in the change history: > > >=A0 >" =A0 Version -05: > >=A0=A0 - discarded QSPEC parameter (Maximum packet size) since MTU >=A0=A0=A0=A0 discovery is expected to be handled by procedure currently de= fined >=A0=A0=A0=A0 by PMTUD WG" >=A0 >Some further=A0explanation for removing the parameter =A0is=A0given=A0i= n a message posted by=A0Cornelia Kappler on the IETF web-site=A0at http://w= ww.ietf.org/mail-archive/web/nsis/current/msg07923.html: >=A0 >"AW: [NSIS] smallest path MTU - Maximum Packet Size [M] > > > > >To: "ext Bernd Schloer" , =20 >Subject: AW: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 >From: "Kappler, Cornelia" =20 >Date: Fri, 1 Jun 2007 09:53:50 +0200=20 >Cc:=20 >In-reply-to: <465C9BAE.1050505@cs.uni-goettingen.de>=20 >List-help: =20 >List-id: Next Steps in Signaling =20 >List-post: =20 >List-subscribe: , =20 >List-unsubscribe: , =20 >References: <465C9BAE.1050505@cs.uni-goettingen.de>=20 >Thread-index: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Qufg=20 >Thread-topic: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 > >Hi all,=20 > >at the Interim meeting in May 2005 we decided to drop the MTU, see=A0 http= ://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html=20 > >Cornelia=20 > >> -----Urspr=FCngliche Nachricht----- >> Von: ext Bernd Schloer [mailto:bschloer at cs.uni-goettingen.de]=20 >> Gesendet: Dienstag, 29. Mai 2007 23:31 >> An: nsis at ietf.org >> Betreff: [NSIS] smallest path MTU - Maximum Packet Size [M] >>=20 >> Hi, >>=20 >> in version 13 of the QSPEC-draft the Maximum Packet Size [M]=20 >> was removed from the >> TMOD parameter (former Traffic parameter). >>=20 >> RFC2211 mentions, that links are not permitted to fragment=20 >> packets which receive >> the controlled-load service and packets larger than the MTU=20 >> of the link are treated >> as non-conformant to the TSPEC. >>=20 >> What was the reason to omit this parameter? >>=20 >> Best regards, >> Bernd" >Hannes Tschofenig kindly provided links to the Munich Interim Meeting Minu= tes at > >http://www.tschofenig.priv.at/nsis/munich/MeetingMinutes.html >=A0 >It appears that the discussion of MTU discovery somehow led to a conclusio= n that the maximum packet size parameter should be eliminated as well, = as documented in this portion of the minutes: >=A0 >"A QoS Model for Signaling IntServ Controlled-Load Service with NSIS >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlled= load-01.txt=20 >Slides: http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/Ctrld_Load_QO= SM_Interim_Munich.ppt > >Cornelia Kappler presents and she starts with an overview of IntServ. > >What is IntServ Controlled-Load service? >-IntServ Controlled Load Service is (in NSIS terms) a QoS Model >-RFC 2210 specifies how to signal for Controled load using RSVP >-This ID specifies how to signal for Controled Load using NSIS >-Controlled-Load Service (RFC 2211) >-Provides approximatively service of an unloaded best-effort network >-QoS parameters signaled are Token Bucket and MTU >-Implemented per "network element", i.e. per-router or per-subnet >Can be used for=20 >Reserving resources per-flow per-router >Admission control at edge of Diffserv domains >Admission control into MPLS clouds > >How to signal for Controlled Load service with NSIS >-Role of QNEs >-One or more QNR per "network element" >-Stateless QNEs? >-Provide approximatively service of an uiloaded best-effort network may al= so be possible with stateless QNEs > >Discussion started about MTU insertion in the QoS NSLP since not all route= rs would be supporting the NSIS Qos NSLP it was decided to remove the MTU d= iscovery from controlled load and Qos-NSLP draft. If required MTU discovery= would be using mechanisms out of scope of NSIS (PMTUD or other)" >=A0 >Bernd Schloer raised the concern of eliminating in his message referen= ced above: >=A0 >"In version 13 of the QSPEC-draft the Maximum Packet Size [M]=A0was remove= d from the TMOD parameter (former Traffic parameter). > >RFC2211 mentions, that links are not permitted to fragment=A0packets which= receive the controlled-load service and packets larger than the MTU=A0of t= he link are treated as non-conformant to the TSPEC. > >What was the reason to omit this parameter?" >=A0 >Al Morton raised=A0the same and additional concerns in a recent discussion= : >=A0 >"It seems to me that=A0 several points were missed >by citing the Packetization Layer Path MTU Discovery (PLPMTUD) >[note: see RFC 4821 http://www.rfc-editor.org/rfc/rfc4821.txt] >as a replacement for specifying M, Max Pkt size: > >=A0-=A0 only the sending end-point will store what PLPMTUD discovers, >=A0=A0=A0 intermediate points where shaping or policing reside will not >=A0=A0=A0 know the Max pkt size the sender intends to use. > >=A0-=A0 the Max packet size that a sender uses may be much less than MTU, >=A0=A0=A0 VoIP is the most obvious example. > >Or, it wasn't understood that M was a critical part of the peak=20 >rate definition.=A0 From RFC 2212: >=A0=A0 The peak rate, p, is measured in bytes of IP datagrams per second a= nd >=A0=A0 has the same range and suggested representation as the bucket rate. >=A0=A0 The peak rate is the maximum rate at which the source and any >=A0=A0 reshaping points (reshaping points are defined below) may inject >=A0=A0 bursts of traffic into the network.=A0 More precisely, it is a >=A0=A0 requirement that for all time periods the amount of data sent canno= t >=A0=A0 exceed M+pT where M is the maximum datagram size and T is the lengt= h >=A0=A0 of the time period.=20 > >Note that parameter M is part of the RFC 2212 TSPEC, and M is apparently >different from the MTU: >=A0=A0 Links are not permitted to fragment datagrams as part of guaranteed >=A0=A0 service.=A0 Datagrams larger than the MTU of the link MUST be polic= ed >=A0=A0 as non-conformant which means that they will be policed according t= o >=A0=A0 the rules described in the Policing section below." >=A0 >It seems that Bernd and Al have=A0raised valid concerns: discovery of MTU = does not=A0eliminate the need to specify in the TMOD parameter.=A0 It a= ppears that the parameter should be put back in the QSPEC.=A0 It should= not be a big issue since=A0 was already there in the QSPEC up through v= ersion 4 (see http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-04.t= xt). >=A0=A0 > > >--- On Wed, 11/11/09, The IESG wrote: > > >From: The IESG >Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template)= to Informational RFC >To: "IETF-Announce" >Cc: nsis@ietf.org >Date: Wednesday, November 11, 2009, 4:09 AM > > >The IESG has received a request from the Next Steps in Signaling WG=20 >(nsis) to consider the following document: > >- 'QoS NSLP QSPEC Template ' >=A0=A0=A0 as an Informational RFC > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action.=A0 Please send substantive comments to the >ietf@ietf.org mailing lists by 2009-11-25. Exceptionally,=20 >comments may be sent to iesg@ietf.org instead. In either case, please=20 >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-22.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D12323&rfc_flag=3D0 > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www.ietf.org/mailman/listinfo/nsis > > > >=A0 =A0 =A0 ) =0A=0A=0A --0-1500372816-1260463156=:51018 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Georgios,
 
The maximum packet size (M) sub-parameter is a required element of the= traffic model (TMOD) parameter specified in the QSPEC.  TMOD is model= ed after the RSVP Tspec parameter (see RFC 2210 http://www.rfc-editor.org/rfc/rfc2210.txt and RFC 2212 = http://www.rfc-editor.org/rfc/rfc2212.txt), which consists of 5 sub-par= ameters:
 
rate (r)
bucket size (b)
peak rate (p)
minimum policed unit (m)
maximum packet size (M)
 
The TMOD parameter is mandatory for = the QNI to include in the initia= tor QSPEC and mandatory for downstream QNEs to interpret.=   As such, the TMOD parameter and M sub-parameter apply to ALL QOSM's,= including Y.1541, RMD, etc., and must be used by them.
&n= bsp;
As explained in = the attached email below, the M sub-parameter was erroneously removed = from the QSPEC in version 5 when it was incorrectly assumed that automatic = discovery of MTU would also apply to M.  It does not, MTU and M a= re not the same parameter.  Fortunately this error was recently brough= t to our attention by Al Morton (and earlier by Bernd Schloer).
&n= bsp;
Therefore M need= s to be put back in the QSPEC, as Jukka has correctly agreed.=
&n= bsp;
Thanks,
Jerry


--- On Tue, 12/8/09, Georgios Karagiannis &= lt;karagian@cs.utwente.nl> wrote:

From: Georgios Karagiannis <karagian@cs.utwent= e.nl>
Subject: [NSIS] Maximum Packet Size Parameter <M> -- Re: = Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational= RFC
To: "Gerald Ash" <gash5107@yahoo.com>, "IETF-Announce" <ie= tf-announce@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "nsis@ietf= .org" <nsis@ietf.org>
Date: Tuesday, December 8, 2009, 1:50 AM
=
Hi Jerry

I think that the reason of removing = the  "Maximum Packet Size [M]
(32-bit unsigned integer)" parameter = from the QSPEC specification was
that this parameter is only relevant fo= r some QoS models that are used
on an end-to-end basis, such as Y.1541 Q= OSM. I would therefore prefer
that this parameter should not be specifie= d in the QSPEC draft.
In my opinion this parameter should be specified a= s an TMOD extension in
any QoS model that needs it. I believe that Y.154= 1 QOSM already does
specify the "Maximum Packet Size [M] (32-bit unsigne= d integer)"
parameter in Section 3.1.

Best regards,
Georgios
On 11/30/2009, "Gerald Ash" <gash5107@yahoo.com> wrote:

>All,
> 
>= Al Morton has recently raised concerns RE taking the Maximum Packet Size <M> parameter out of the QSPEC document.  Base= d on his comments (given below, along with other background), it appears th= at the <M> parameter should be put back into the QSPEC.
> =
>
>Please comment on whether the <M> parameter= should be put back into the QSPEC.
> 
>Thanks,
>Jer= ry
> 
>Background:
> 
>The Maximum Packet= Size Parameter <M> was taken out back in July 2005 in QSPEC ver= sion 5, with the following explanation in the change history:
>
&g= t;
> 
>"   Version -05:
>
>   -= discarded QSPEC parameter <M> (Maximum packet size) since MTU
>= ;     discovery is expected to be handled by procedure = currently defined
>     by PMTUD WG"
> = ;
>Some further explanation for removing the parameter <M> is given in a message posted by Cornelia Kap= pler on the IETF web-site at http://www.ietf.org/mail= -archive/web/nsis/current/msg07923.html:
> 
>"AW: [NSI= S] smallest path MTU - Maximum Packet Size [M]
>
>
>
&= gt;
>To: "ext Bernd Schloer" <bschloer at cs.uni-goettingen.de>= , <nsis at ietf.org>
>Subject: AW: [NSIS] smallest path MTU - = Maximum Packet Size [M]
>From: "Kappler, Cornelia" <cornelia.kapp= ler at nsn.com>
>Date: Fri, 1 Jun 2007 09:53:50 +0200
>Cc:=
>In-reply-to: <465C9BAE.1050505@cs.uni-goettingen.de>=
>List-help: <mailto:nsis-request@ietf.org?subj= ect=3Dhelp>
>List-id: Next Steps in Signaling <nsis.ietf.org&g= t;
>List-post: <mailto:nsis@ietf.o= rg>
>List-subscribe: <https://www1.ietf.org/mailman/listinfo/= nsis>, <mailto:nsi= s-request@ietf.org?subject=3Dsubscribe>
>List-unsubscribe: &l= t;h= ttps://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject= =3Dunsubscribe>
>References: <465C9BAE.1050505@cs.uni-goet= tingen.de>
>Thread-index: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Quf= g
>Thread-topic: [NSIS] smallest path MTU - Maximum Packet Size [M] =
>
>Hi all,
>
>at the Interim meeting in May 2005 = we decided to drop the MTU, see  http://www.= ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html
><= BR>>Cornelia
>
>> -----Urspr=FCngliche Nachricht----->> Von: ext Bernd Schloer [mailto:bschloer at cs.uni-goettingen.de] =
>> Gesendet: Dienstag, 29. Mai 2007 23:31
>> An: nsis at ietf.org
>> Betreff: [NSIS] smallest path MTU - Maximum Packet Si= ze [M]
>>
>> Hi,
>>
>> in version 13 = of the QSPEC-draft the Maximum Packet Size [M]
>> was removed fro= m the
>> TMOD parameter (former Traffic parameter).
>> >> RFC2211 mentions, that links are not permitted to fragment
&= gt;> packets which receive
>> the controlled-load service and p= ackets larger than the MTU
>> of the link are treated
>>= as non-conformant to the TSPEC.
>>
>> What was the reas= on to omit this parameter?
>>
>> Best regards,
>&g= t; Bernd"
>Hannes Tschofenig kindly provided links to the Munich Inte= rim Meeting Minutes at
>
>http://www.tschofenig.= priv.at/nsis/munich/MeetingMinutes.html
> 
>It appears that the discussion of MTU discovery somehow led to a conclusion t= hat the maximum packet size parameter <M> should be eliminated as wel= l, as documented in this portion of the minutes:
> 
>"A Qo= S Model for Signaling IntServ Controlled-Load Service with NSIS
>=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>http://www.ietf.org/internet-drafts/draft-kappl= er-nsis-qosmodel-controlledload-01.txt
>Slides: http://www.ietf-nsis.org/nsis/Munich_Interim_Meeti= ng/Ctrld_Load_QOSM_Interim_Munich.ppt
>
>Cornelia Kappler p= resents and she starts with an overview of IntServ.
>
>What is = IntServ Controlled-Load service?
>-IntServ Controlled Load Service is (in NSIS terms) a QoS Model
>-RFC 2210 specifies how= to signal for Controled load using RSVP
>-This ID specifies how to s= ignal for Controled Load using NSIS
>-Controlled-Load Service (RFC 22= 11)
>-Provides approximatively service of an unloaded best-effort net= work
>-QoS parameters signaled are Token Bucket and MTU
>-Imple= mented per "network element", i.e. per-router or per-subnet
>Can be u= sed for
>Reserving resources per-flow per-router
>Admission co= ntrol at edge of Diffserv domains
>Admission control into MPLS clouds=
>
>How to signal for Controlled Load service with NSIS
>= -Role of QNEs
>-One or more QNR per "network element"
>-Statele= ss QNEs?
>-Provide approximatively service of an uiloaded best-effort= network may also be possible with stateless QNEs
>
>Discussion= started about MTU insertion in the QoS NSLP since not all routers would be supporting the NSIS Qos NSLP it was decided to remove the MTU dis= covery from controlled load and Qos-NSLP draft. If required MTU discovery w= ould be using mechanisms out of scope of NSIS (PMTUD or other)"
>&nbs= p;
>Bernd Schloer raised the concern of eliminating <M> in his = message referenced above:
> 
>"In version 13 of the QSPEC-= draft the Maximum Packet Size [M] was removed from the TMOD parameter = (former Traffic parameter).
>
>RFC2211 mentions, that links are= not permitted to fragment packets which receive the controlled-load s= ervice and packets larger than the MTU of the link are treated as non-= conformant to the TSPEC.
>
>What was the reason to omit this pa= rameter?"
> 
>Al Morton raised the same and additiona= l concerns in a recent discussion:
> 
>"It seems to me tha= t  several points were missed
>by citing the Packetization Layer Path MTU Discovery (PLPMTUD)
>[note: see RFC 482= 1 htt= p://www.rfc-editor.org/rfc/rfc4821.txt]
>as a replacement for spe= cifying M, Max Pkt size:
>
> -  only the sending end-= point will store what PLPMTUD discovers,
>    intermed= iate points where shaping or policing reside will not
>  &n= bsp; know the Max pkt size the sender intends to use.
>
> = -  the Max packet size that a sender uses may be much less than MTU,>    VoIP is the most obvious example.
>
>O= r, it wasn't understood that M was a critical part of the peak
>rate= definition.  From RFC 2212:
>   The peak rate, p, is = measured in bytes of IP datagrams per second and
>   has th= e same range and suggested representation as the bucket rate.
>   The peak rate is the maximum rate at which the s= ource and any
>   reshaping points (reshaping points are de= fined below) may inject
>   bursts of traffic into the netw= ork.  More precisely, it is a
>   requirement that for= all time periods the amount of data sent cannot
>   exceed= M+pT where M is the maximum datagram size and T is the length
> = ;  of the time period.
>
>Note that parameter M is part o= f the RFC 2212 TSPEC, and M is apparently
>different from the MTU:>   Links are not permitted to fragment datagrams as part of = guaranteed
>   service.  Datagrams larger than the MTU= of the link MUST be policed
>   as non-conformant which me= ans that they will be policed according to
>   the rules de= scribed in the Policing section below."
> 
>It seems that Bernd and Al have raised valid concerns: discovery of MTU = does not eliminate the need to specify <M> in the TMOD parameter= .  It appears that the <M> parameter should be put back in the Q= SPEC.  It should not be a big issue since <M> was already t= here in the QSPEC up through version 4 (see http://www.wat= ersprings.org/pub/id/draft-ietf-nsis-qspec-04.txt).
>  =
>
>
>--- On Wed, 11/11/09, The IESG <iesg-secretary@ietf.org> wrote:<= BR>>
>
>From: The IESG <iesg-secretary@ietf.org>
>Subject: [NSIS] La= st Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC
&g= t;To: "IETF-Announce" <= ietf-announce@ietf.org>
>Cc: ns= is@ietf.org
>Date: Wednesday, November 11, 2009, 4:09 AM
><= BR>>
>The IESG has received a request from the Next Steps in Signa= ling WG
>(nsis) to consider the following document:
>
>-= 'QoS NSLP QSPEC Template '
>   <draft-ietf-nsis-qs= pec-22.txt> as an Informational RFC
>
>The IESG plans to mak= e a decision in the next few weeks, and solicits
>final comments on t= his action.  Please send substantive comments to the
>ietf@ietf.org mailing lists by 2009-1= 1-25. Exceptionally,
>comments may be sent to iesg@ietf.org instead. In either case, please
>retain t= he beginning of the Subject line to allow automated sorting.
>
>= ;The file can be obtained via
>http://www.ietf.org/= internet-drafts/draft-ietf-nsis-qspec-22.txt
>
>
>IES= G discussion can be tracked via
>https://datatracker.ietf.org/public/pidtracker.cgi?co= mmand=3Dview_id&dTag=3D12323&rfc_flag=3D0
>
>______= _________________________________________
>nsis mailing list
><= A href=3D"http://us.mc636.mail.yahoo.com/mc/compose?to=3Dnsis@ietf.org" ymai= lto=3D"mailto:nsis@ietf.org">nsis@ietf.org
>https://www.ietf.org/mail= man/listinfo/nsis
>
>
>
>      )=

=0A=0A --0-1500372816-1260463156=:51018-- From gash5107@yahoo.com Thu Dec 10 08:56:39 2009 Return-Path: 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 29B0728C116 for ; Thu, 10 Dec 2009 08:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.851 X-Spam-Level: X-Spam-Status: No, score=-101.851 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227, 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 9u4cozSVV7z2 for ; Thu, 10 Dec 2009 08:56:38 -0800 (PST) Received: from web63603.mail.re1.yahoo.com (web63603.mail.re1.yahoo.com [69.147.97.73]) by core3.amsl.com (Postfix) with SMTP id 334913A67F5 for ; Thu, 10 Dec 2009 08:56:38 -0800 (PST) Received: (qmail 38692 invoked by uid 60001); 10 Dec 2009 16:56:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260464184; bh=5mPAYXl+XWSvMbW4yCUkGfispMg8q21h8nV92bOWE/0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=0hfojqDh4oKodjS2V8t8DpiwpAH7oB8+BiniHNIck9eJrEtg4Ry+Ok1+5GF+hK2l1P9D1ItUle6glZcGljlgQOU6XbFCFsckCICCLM+ayba5cIpGPH4BodEOW53eB49xw85/VuqBzaOL3e3DxtQ/I53BZ0D32cOrlz0KJzzDJVs= 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=0FytXcUQTyVGK181Tl5qQArfw2j2dzS2BYKJNheH8cs682qAcZgG8iL6IGEmCWRj3xb+oQBLUIYaKRkJpNcyFIYRJpL6jWINzlHs3Rx2IJaTPeGOXN/lNAJnakzpNr+CAU95EH9t3McWhGZs41V5LO8XyopmCa0Ufq/pjl/WspM=; Message-ID: <144670.38204.qm@web63603.mail.re1.yahoo.com> X-YMail-OSG: 4mgh21EVM1k.uMoOn.7R7zR0EADmJvfQLVeLJpM.oKhxsXZ.TrXaEWzeMWlGsU_uK27nzoB7nibBFgHYE8gVw4sf1t0v0yRzYj0zaCcPZmriRzFhHZn2kwJrN10W_9FR1SDaYPXGLe7k4pGao.6STKD02ETnuldnDfru4vKZUJiVt.n30j2oXuxNQqJBgjXxXfGDfNvxG9rRbPdpHTe5s.zRfXPjrDqe2opwXsQDhHl0Bk9tOhCEoJs.1mmTT0_p5YWkhiCtndFcY.ktGCY9oDPyVupa5p7g7h6819h.S3yC9dZSRj5VskTz3cfoTj0ynOSFtZ7iEyyfa0RTx5QbcROiMR4SQ6J64_dxT7y3xfzdltuJ9J262dUIgLeOZeNidz1Dr7SkR6p77rKeSxeUBXhH1g-- Received: from [24.91.148.40] by web63603.mail.re1.yahoo.com via HTTP; Thu, 10 Dec 2009 08:56:23 PST X-Mailer: YahooMailClassic/9.0.19 YahooMailWebService/0.8.100.260964 Date: Thu, 10 Dec 2009 08:56:23 -0800 (PST) From: Gerald Ash To: Magnus Westerlund In-Reply-To: <4B1CD7FB.20402@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-377297473-1260464183=:38204" Cc: NSIS Subject: Re: [NSIS] Intended status for draft-ietf-nsis-qspec X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 16:56:39 -0000 --0-377297473-1260464183=:38204 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Magnus, =A0 I agree with you and Joel=A0that the QSPEC document should be published as = Experimental.=A0 QoS-NSLP (Experimental) and QSPEC are companion documents = to a common specification; I've never understood why the QSPEC was designat= ed Informational. =A0 Thanks, Jerry --- On Mon, 12/7/09, Magnus Westerlund wro= te: From: Magnus Westerlund Subject: [NSIS] Intended status for draft-ietf-nsis-qspec To: "NSIS" Date: Monday, December 7, 2009, 5:24 AM Hi, It was raised by Joel Halpern in his Gen-art review and I personally have question marks about the intended status of Informational. I think it would make more sense to publish this document as Experimental. Please voice your opinion. Cheers Magnus Westerlund IETF Transport Area Director ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Phone=A0 +46 10 7148287 F=E4r=F6gatan 6=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ nsis mailing list nsis@ietf.org https://www.ietf.org/mailman/listinfo/nsis =0A=0A=0A --0-377297473-1260464183=:38204 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Magnus,
 
I agree with you and Joel that the QSPEC document should be publi= shed as Experimental.  QoS-NSLP (Experimental) and QSPEC are companion= documents to a common specification; I've never understood why the QSPEC w= as designated Informational.
 
Thanks,
Jerry

--- On Mon, 12/7/09, Magnus Westerlund <magnus.w= esterlund@ericsson.com> wrote:

From: Magnus Westerlund <magnus.westerlund@eri= csson.com>
Subject: [NSIS] Intended status for draft-ietf-nsis-qspec<= BR>To: "NSIS" <nsis@ietf.org>
Date: Monday, December 7, 2009, 5:24= AM

Hi,

It was raised by Joel Halpern in his Gen-= art review and I personally
have question marks about the intended statu= s of Informational. I think
it would make more sense to publish this doc= ument as Experimental.

Please voice your opinion.

Cheers
<= BR>Magnus Westerlund

IETF Transport Area Director
---------------= -------------------------------------------------------
Multimedia Techn= ologies, Ericsson Research EAB/TVM
-------------------------------------= ---------------------------------
Ericsson AB       =         | Phone  +46 10 7148287
F=E4r=F6gatan = 6                | Mobile +46 73 09= 49079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericss= on.com
-------------------------------------------------------------= ---------
_______________________________________________
nsis mailin= g list
nsis@ietf.org
https://www.ietf.= org/mailman/listinfo/nsis

= =0A=0A --0-377297473-1260464183=:38204-- From gash5107@yahoo.com Thu Dec 10 09:22:33 2009 Return-Path: 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 02A6E3A69AC for ; Thu, 10 Dec 2009 09:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.975 X-Spam-Level: X-Spam-Status: No, score=-101.975 tagged_above=-999 required=5 tests=[AWL=0.289, 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 F8aVTLsuh7gs for ; Thu, 10 Dec 2009 09:22:31 -0800 (PST) Received: from web63608.mail.re1.yahoo.com (web63608.mail.re1.yahoo.com [69.147.97.78]) by core3.amsl.com (Postfix) with SMTP id 876B83A699D for ; Thu, 10 Dec 2009 09:22:31 -0800 (PST) Received: (qmail 74978 invoked by uid 60001); 10 Dec 2009 17:22:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1260465737; bh=5zKEL65nWu+XT32T39PSoU+A9LX+LI5m6jXnmS2xosE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KnBy+ij8cSFD1pB2g447/JQiRsh3kQhLlz1M6gVQpojdsuIzX2Vdaw4331HKHtS6iHuum2O91MCQaS/KlieVli5cVgEVq6H7tAXBQjQwXqARFbdfThbP9SIhEMopu+tuHAFgmv1nHZC4I6n0V42GFPgapBRaWUDFeDHq7KsGCjk= 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=VVlrBvYM84JPdfM8biEOA/G3q/LgOPekXJoZiAqHmo3k9ugEuepYcgKWWp/hZmRMwK+PwSj+f5qZHGfLb20/IOq8surbYxlx4BKw5jZzdqhFpYSPZY55FgiLPDwXA1W4Jjs0DA7T36Gp2+NaXLOUR2PAjHNuDvQVKkpUm3YxEW8=; Message-ID: <748170.74456.qm@web63608.mail.re1.yahoo.com> X-YMail-OSG: _ahnD20VM1knkiO0Gsqbyo3K8t0rMgLA67tgJdqbd8iaJtCM0ahS6S0_.7Tg7DQlM6MrmocjJvNnDLjsOSpTCp842RpB_lR353Ree1r4e6N04.lNapXUMWkg3RH6uP2M652UMoyT1I7yedtxyWHXrqN3ajdyOIj64K1YiWRmUhdAUOYniLApSMAtamdf5FJt_kPA_ZRvuMGt.hQlgMelol7D7fyWNZYTw.vfi3tGQ5ag.e.lXzop1VOPGHFKqhVSnB2WcdpZOazntWPXG4joSVJp8FKQRNy9x7VpbYe7Th9gEJxxmNiMjGTlKsF2QGh2b_EJTqRTyNAcnuKiBpdZgAlx75j_L1Wohz9vO4IF2144alBKyHkozuYMeVocs7vlXA_VqruD9a1aCoxKmSU1lB18KTta.tImdDNARCzHhFiAKX96 Received: from [24.91.148.40] by web63608.mail.re1.yahoo.com via HTTP; Thu, 10 Dec 2009 09:22:17 PST X-Mailer: YahooMailClassic/9.0.19 YahooMailWebService/0.8.100.260964 Date: Thu, 10 Dec 2009 09:22:17 -0800 (PST) From: Gerald Ash To: Karthik Balaguru In-Reply-To: <53b627ea0912020908n41d94a8dw7f3304ed2b507fa7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2005746060-1260465737=:74456" Cc: nsis@ietf.org Subject: Re: [NSIS] Regd 3GPP QoS Model for Networks Using 3GPP QoS Classes X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 17:22:33 -0000 --0-2005746060-1260465737=:74456 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Yes, that is the latest version of the 3GPP-QOSM draft.=A0 Seong-Ho posted = these messages following publication of the version 2 draft: =A0 http://www.ietf.org/mail-archive/web/nsis/current/msg05611.html http://www.ietf.org/mail-archive/web/nsis/current/msg06424.html =A0 There has been no discussion or follow-up since then that I can find.=A0=A0= This was a good draft and IMO=A0it would be good to finish the work on the = 3GPP-QOSM. =A0 Thanks, Jerry --- On Wed, 12/2/09, Karthik Balaguru wrote: From: Karthik Balaguru Subject: [NSIS] Regd 3GPP QoS Model for Networks Using 3GPP QoS Classes To: nsis@ietf.org Date: Wednesday, December 2, 2009, 12:08 PM Hi, I find only the draft version of draft-jeong-nsis-3gpp-qosm-02.txt . What is the latest development w.r.t '3GPP QoS Model for Networks Using 3GP= P QoS Classes'. Any other related/alternative RFC available for this ? =A0 Thx in advans, Karthik Balaguru=20 -----Inline Attachment Follows----- _______________________________________________ nsis mailing list nsis@ietf.org https://www.ietf.org/mailman/listinfo/nsis =0A=0A=0A --0-2005746060-1260465737=:74456 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A=0A --0-2005746060-1260465737=:74456-- From karagian@cs.utwente.nl Fri Dec 11 01:11:00 2009 Return-Path: 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 8BB173A69CD; Fri, 11 Dec 2009 01:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.719 X-Spam-Level: * X-Spam-Status: No, score=1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227] 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 0G4T+lF6x6Vx; Fri, 11 Dec 2009 01:10:58 -0800 (PST) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id D0AD53A6818; Fri, 11 Dec 2009 01:10:57 -0800 (PST) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id nBB9AY9V001700; Fri, 11 Dec 2009 10:10:35 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 11 Dec 2009 09:10:35 +0000 To: "Gerald Ash" Date: Fri, 11 Dec 2009 09:10:35 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <0c0jUEda.1260522635.1921410.karagian@ewi.utwente.nl> In-Reply-To: <571767.51018.qm@web63608.mail.re1.yahoo.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Fri, 11 Dec 2009 10:10:39 +0100 (MET) Cc: "nsis@ietf.org" , "ietf@ietf.org" , IETF-Announce Subject: Re: [NSIS] Maximum Packet Size Parameter -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2009 09:11:00 -0000 Hi Jerry As long as the current specified QSPEC processing rules are not affected it is okay with me to include the maximum packet size (M) subparameter into TMOD. Furthermore, please see in line! On 12/10/2009, "Gerald Ash" wrote: >Georgios, >=A0 >The maximum packet size (M) sub-parameter is a required element of the traff= ic model (TMOD) parameter specified in the QSPEC.=A0 TMOD is modeled after th= e RSVP Tspec parameter (see RFC 2210=A0http://www.rfc-editor.org/rfc/rfc2210.= txt=A0and RFC 2212 http://www.rfc-editor.org/rfc/rfc2212.txt), which consists= of 5 sub-parameters:=20 >=A0 >rate (r) >bucket size (b) >peak rate (p) >minimum policed unit (m) >maximum packet size (M) Georgios: The NSIS WG had decided to use only 4 parameters, see QSPEC draft (v.22):, section 3.3.1: o rate (r) specified in octets per second o bucket size (b) specified in octets o peak rate (p) specified in octets per second o minimum policed unit (m) specified in octets >=A0 >The TMOD parameter=A0is mandatory for the QNI to include in the initiator QS= PEC and mandatory for downstream QNEs to interpret.=A0 As such, the TMOD para= meter and M sub-parameter apply to ALL QOSM's, including Y.1541, RMD, etc., a= nd must be used by them. Georgios: I think that the QSPEC draft describes in a good way how TMOD is processed by QNEs and local QoS models. >=A0 >As explained in the attached email below, the M sub-parameter was erroneousl= y=A0removed from the QSPEC in version 5 when it was incorrectly assumed that = automatic discovery of MTU would also apply to M.=A0 It does not, MTU=A0and M= are not the same parameter.=A0 Fortunately this error was recently brought t= o our attention by Al Morton (and earlier by Bernd Schloer). Georgios: Please note that the maximum packet size (M) subparameter was removed in v.13 of the QSPEC draft. In v.12 of the QSPEC draft the maximum packet size (M) subparameter was specified, see Section 7.2.2 of version 12 of the QSPEC. So I do not know what was the reason of removing the M subparameter from TMOD. However, as long as the current QSPEC/TMOD processing rules are not affected it is okay with me to include the maximum packet size (M) subparameter into TMOD. Best regards, Georgios >=A0 >Therefore M needs to be put back in the QSPEC, as Jukka has correctly agreed= . >=A0 >Thanks, >Jerry > > >--- On Tue, 12/8/09, Georgios Karagiannis wrote: > > >From: Georgios Karagiannis >Subject: [NSIS] Maximum Packet Size Parameter -- Re: Last Call: draft-ie= tf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC >To: "Gerald Ash" , "IETF-Announce" , "ietf@ietf.org" , "nsis@ietf.org" >Date: Tuesday, December 8, 2009, 1:50 AM > > >Hi Jerry > >I think that the reason of removing the=A0 "Maximum Packet Size [M] >(32-bit unsigned integer)" parameter from the QSPEC specification was >that this parameter is only relevant for some QoS models that are used >on an end-to-end basis, such as Y.1541 QOSM. I would therefore prefer >that this parameter should not be specified in the QSPEC draft. >In my opinion this parameter should be specified as an TMOD extension in >any QoS model that needs it. I believe that Y.1541 QOSM already does >specify the "Maximum Packet Size [M] (32-bit unsigned integer)" >parameter in Section 3.1. > >Best regards, >Georgios > >On 11/30/2009, "Gerald Ash" wrote: > >>All, >>=A0 >>Al Morton has recently raised=A0concerns=A0RE taking the Maximum Packet Siz= e=A0 parameter out of the QSPEC document.=A0 Based on his comments (given = below, along with other background), it appears that the parameter should= be put back into the QSPEC. >>=A0 >> >>Please comment on=A0whether=A0the parameter should be put back into the= QSPEC. >>=A0 >>Thanks, >>Jerry >>=A0 >>Background: >>=A0 >>The Maximum Packet Size Parameter =A0was taken out back in July 2005 in = QSPEC version 5, with the following explanation in the change history: >> >> >>=A0 >>" =A0 Version -05: >> >>=A0=A0 - discarded QSPEC parameter (Maximum packet size) since MTU >>=A0=A0=A0=A0 discovery is expected to be handled by procedure currently def= ined >>=A0=A0=A0=A0 by PMTUD WG" >>=A0 >>Some further=A0explanation for removing the parameter =A0is=A0given=A0in= a message posted by=A0Cornelia Kappler on the IETF web-site=A0at http://www.= ietf.org/mail-archive/web/nsis/current/msg07923.html: >>=A0 >>"AW: [NSIS] smallest path MTU - Maximum Packet Size [M] >> >> >> >> >>To: "ext Bernd Schloer" , =20 >>Subject: AW: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 >>From: "Kappler, Cornelia" =20 >>Date: Fri, 1 Jun 2007 09:53:50 +0200=20 >>Cc:=20 >>In-reply-to: <465C9BAE.1050505@cs.uni-goettingen.de>=20 >>List-help: =20 >>List-id: Next Steps in Signaling =20 >>List-post: =20 >>List-subscribe: , =20 >>List-unsubscribe: , =20 >>References: <465C9BAE.1050505@cs.uni-goettingen.de>=20 >>Thread-index: AceiOM3OwdCeaEOuS267eWNZJzBL6QB6Qufg=20 >>Thread-topic: [NSIS] smallest path MTU - Maximum Packet Size [M]=20 >> >>Hi all,=20 >> >>at the Interim meeting in May 2005 we decided to drop the MTU, see=A0 http:= //www.ietf-nsis.org/nsis/Munich_Interim_Meeting/MeetingMinutes.html=20 >> >>Cornelia=20 >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: ext Bernd Schloer [mailto:bschloer at cs.uni-goettingen.de]=20 >>> Gesendet: Dienstag, 29. Mai 2007 23:31 >>> An: nsis at ietf.org >>> Betreff: [NSIS] smallest path MTU - Maximum Packet Size [M] >>>=20 >>> Hi, >>>=20 >>> in version 13 of the QSPEC-draft the Maximum Packet Size [M]=20 >>> was removed from the >>> TMOD parameter (former Traffic parameter). >>>=20 >>> RFC2211 mentions, that links are not permitted to fragment=20 >>> packets which receive >>> the controlled-load service and packets larger than the MTU=20 >>> of the link are treated >>> as non-conformant to the TSPEC. >>>=20 >>> What was the reason to omit this parameter? >>>=20 >>> Best regards, >>> Bernd" >>Hannes Tschofenig kindly provided links to the Munich Interim Meeting Minut= es at >> >>http://www.tschofenig.priv.at/nsis/munich/MeetingMinutes.html >>=A0 >>It appears that the discussion of MTU discovery somehow led to a conclusion= that the maximum packet size parameter should be eliminated as well, as = documented in this portion of the minutes: >>=A0 >>"A QoS Model for Signaling IntServ Controlled-Load Service with NSIS >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>http://www.ietf.org/internet-drafts/draft-kappler-nsis-qosmodel-controlledl= oad-01.txt=20 >>Slides: http://www.ietf-nsis.org/nsis/Munich_Interim_Meeting/Ctrld_Load_QOS= M_Interim_Munich.ppt >> >>Cornelia Kappler presents and she starts with an overview of IntServ. >> >>What is IntServ Controlled-Load service? >>-IntServ Controlled Load Service is (in NSIS terms) a QoS Model >>-RFC 2210 specifies how to signal for Controled load using RSVP >>-This ID specifies how to signal for Controled Load using NSIS >>-Controlled-Load Service (RFC 2211) >>-Provides approximatively service of an unloaded best-effort network >>-QoS parameters signaled are Token Bucket and MTU >>-Implemented per "network element", i.e. per-router or per-subnet >>Can be used for=20 >>Reserving resources per-flow per-router >>Admission control at edge of Diffserv domains >>Admission control into MPLS clouds >> >>How to signal for Controlled Load service with NSIS >>-Role of QNEs >>-One or more QNR per "network element" >>-Stateless QNEs? >>-Provide approximatively service of an uiloaded best-effort network may als= o be possible with stateless QNEs >> >>Discussion started about MTU insertion in the QoS NSLP since not all router= s would be supporting the NSIS Qos NSLP it was decided to remove the MTU disc= overy from controlled load and Qos-NSLP draft. If required MTU discovery woul= d be using mechanisms out of scope of NSIS (PMTUD or other)" >>=A0 >>Bernd Schloer raised the concern of eliminating in his message referenc= ed above: >>=A0 >>"In version 13 of the QSPEC-draft the Maximum Packet Size [M]=A0was removed= from the TMOD parameter (former Traffic parameter). >> >>RFC2211 mentions, that links are not permitted to fragment=A0packets which = receive the controlled-load service and packets larger than the MTU=A0of the = link are treated as non-conformant to the TSPEC. >> >>What was the reason to omit this parameter?" >>=A0 >>Al Morton raised=A0the same and additional concerns in a recent discussion: >>=A0 >>"It seems to me that=A0 several points were missed >>by citing the Packetization Layer Path MTU Discovery (PLPMTUD) >>[note: see RFC 4821 http://www.rfc-editor.org/rfc/rfc4821.txt] >>as a replacement for specifying M, Max Pkt size: >> >>=A0-=A0 only the sending end-point will store what PLPMTUD discovers, >>=A0=A0=A0 intermediate points where shaping or policing reside will not >>=A0=A0=A0 know the Max pkt size the sender intends to use. >> >>=A0-=A0 the Max packet size that a sender uses may be much less than MTU, >>=A0=A0=A0 VoIP is the most obvious example. >> >>Or, it wasn't understood that M was a critical part of the peak=20 >>rate definition.=A0 From RFC 2212: >>=A0=A0 The peak rate, p, is measured in bytes of IP datagrams per second an= d >>=A0=A0 has the same range and suggested representation as the bucket rate. >>=A0=A0 The peak rate is the maximum rate at which the source and any >>=A0=A0 reshaping points (reshaping points are defined below) may inject >>=A0=A0 bursts of traffic into the network.=A0 More precisely, it is a >>=A0=A0 requirement that for all time periods the amount of data sent cannot >>=A0=A0 exceed M+pT where M is the maximum datagram size and T is the length >>=A0=A0 of the time period.=20 >> >>Note that parameter M is part of the RFC 2212 TSPEC, and M is apparently >>different from the MTU: >>=A0=A0 Links are not permitted to fragment datagrams as part of guaranteed >>=A0=A0 service.=A0 Datagrams larger than the MTU of the link MUST be police= d >>=A0=A0 as non-conformant which means that they will be policed according to >>=A0=A0 the rules described in the Policing section below." >>=A0 >>It seems that Bernd and Al have=A0raised valid concerns: discovery of MTU d= oes not=A0eliminate the need to specify in the TMOD parameter.=A0 It appe= ars that the parameter should be put back in the QSPEC.=A0 It should not = be a big issue since=A0 was already there in the QSPEC up through version = 4 (see http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-04.txt). >>=A0=A0 >> >> >>--- On Wed, 11/11/09, The IESG wrote: >> >> >>From: The IESG >>Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) = to Informational RFC >>To: "IETF-Announce" >>Cc: nsis@ietf.org >>Date: Wednesday, November 11, 2009, 4:09 AM >> >> >>The IESG has received a request from the Next Steps in Signaling WG=20 >>(nsis) to consider the following document: >> >>- 'QoS NSLP QSPEC Template ' >>=A0=A0=A0 as an Informational RFC >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action.=A0 Please send substantive comments to the >>ietf@ietf.org mailing lists by 2009-11-25. Exceptionally,=20 >>comments may be sent to iesg@ietf.org instead. In either case, please=20 >>retain the beginning of the Subject line to allow automated sorting. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-22.txt >> >> >>IESG discussion can be tracked via >>https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D12323&rfc_flag=3D0 >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www.ietf.org/mailman/listinfo/nsis >> >> >> >>=A0 =A0 =A0 ) > > > > ) From root@core3.amsl.com Thu Dec 17 11:45:02 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2BD6A28C129; Thu, 17 Dec 2009 11:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091217194502.2BD6A28C129@core3.amsl.com> Date: Thu, 17 Dec 2009 11:45:02 -0800 (PST) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ext-05.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Next Steps in Signaling Working Group of the IETF. Title : Using and Extending the NSIS Protocol Family Author(s) : J. Manner, et al. Filename : draft-ietf-nsis-ext-05.txt Pages : 29 Date : 2009-12-17 This document gives an overview of the Next Steps in Signaling (NSIS) framework and protocol suite created by the NSIS working group during the period 2001-2009 together with suggestions on how the industry can make use of the new protocols, and how the community can exploit the extensibility of both the framework and existing protocols to address future signaling needs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 20, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-ext-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-nsis-ext-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-17114224.I-D@ietf.org> --NextPart--
Yes, that is the latest version of the 3= GPP-QOSM draft.  Seong-Ho posted these messages following publication = of the version 2 draft:
 
http://www.ietf.org/mail-archive/web/nsis/current/msg05611.html
http://www.ietf.org/mail-archive/web/nsis/current/msg06424.html
 
There has been no discussion or follow-up since then that I can find.&= nbsp; This was a good draft and IMO it would be good to finish th= e work on the 3GPP-QOSM.
 
Thanks,
Jerry


--- On Wed, 12/2/09, Karthik Balaguru <karthikbalagur= u79@gmail.com> wrote:

From: Karthik Balaguru <karthikbalaguru79@gmai= l.com>
Subject: [NSIS] Regd 3GPP QoS Model for Networks Using 3GPP Qo= S Classes
To: nsis@ietf.org
Date: Wednesday, December 2, 2009, 12:08 = PM

Hi,
I find only the draft version of draft-jeong= -nsis-3gpp-qosm-02.txt .
What is the latest development w.r.t '3GPP QoS = Model for Networks Using 3GPP QoS Classes'.
Any other related/alternativ= e RFC available for this ?
 
Thx in advans,
Karthik Balaguru =

-----Inline Attachment Follows-----

_______________________________________________
n= sis mailing list
nsis@ietf.org
https:/= /www.ietf.org/mailman/listinfo/nsis