[NSIS] Maximum Packet Size Parameter <M> -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC
Gerald Ash <gash5107@yahoo.com> Mon, 30 November 2009 17:12 UTC
Return-Path: <gash5107@yahoo.com>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1564728C136 for <nsis@core3.amsl.com>; Mon, 30 Nov 2009 09:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.295
X-Spam-Level:
X-Spam-Status: No, score=-101.295 tagged_above=-999 required=5 tests=[AWL=-0.742, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 18p1VDsMNjEw for <nsis@core3.amsl.com>; Mon, 30 Nov 2009 09:12:44 -0800 (PST)
Received: from web63605.mail.re1.yahoo.com (web63605.mail.re1.yahoo.com [69.147.97.75]) by core3.amsl.com (Postfix) with SMTP id 3B65C3A67F2 for <nsis@ietf.org>; Mon, 30 Nov 2009 09:12:44 -0800 (PST)
Received: (qmail 33017 invoked by uid 60001); 30 Nov 2009 17:12:31 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1259601151; bh=GnB0gqZbfKoJ2PPhgCb7A2Q8pC+tmLmlFeLmc54aLVA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OI1y983NlevIskqBbH+N2WJ8mRRZmnWCmgOz6C1DbVkP1GgoMz0KWMfbYBZna82ziocpe/YksT8FZxJF3JQOb5AnQJOBKj4RZCnqg79VS+mQHmTn9+HEbkV9iQLszAgj/A+j24jtfpznke1BiFIMlQjcBvIzZEiAWbSrWrBIPLA=
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=dVkT0IaUWifkCCbFlCfelaOQx30FnsY0kZRY0qnQ1JJM2M+Wz1eSW8rLpBPeEaNPUcOno9JQV7YD7r4ftKxxHgt5w5Vos0wXLE0VrCxh51iyQcpGHxOH5yDRB5r6eW0D84yIAFF5I7h0N2hd869f4sWvj0LSj1DNezd965CCdLo=;
Message-ID: <58192.32970.qm@web63605.mail.re1.yahoo.com>
X-YMail-OSG: JHzAPWUVM1kjfzvkGwXr7DJAD3RhRsXki7i9qDfDEc.vjs_cVTzgOHSjrexkyq9ZhsdxcVsaOFf8lWDQBH2Qa_EboM2FN8LZkDlislQ4xYdjrqLoWedD4cwV5SH4GLK2nO4HmVZDwzHZOnTxur1bNME_MtfKz5XfA194zZxBoMgdp7VEC3wqntylT4Ew.O.tOW6j.f4BfZ.51cG3rlNUZSSf0Waa0q0iCV_.qOVl3J7RIiEW.Jnv7LUUQ5cbEnM1SMlvYPvXSHyH7naZShRoBP5Rr1FPkd0A_MY.Cs6NvuLiWtaA8oqRV7AiADBKhvBwQbmppPZcfiF7xmLi92xq1QdRiV51_Vvfhr_cG58r_if3roTa04n7u7m2esOipG6raML12SJZ8p6ce_ljJlF2.HjVJOvBfOfyHxOrIa.CxAPuC9v9YuKRnzaldHRdU55td5VMdZr5pRJbZFNpqKSF.3GHGFlTbPeiM7Oa7w3M6SHEKaw2GoPMslmh9CiNIIBFmARtktZ39JHVOouF2DLTb1hwvGej4l1m.U69vAtVlpYr1.zNmyUM076gmQ9hxY_eY78DvtGAzw57u4oeOygHmNz18m10NAXAJdEVyBkoni4RkXOFAyk5GGSxT7apaJvdYt53osGqIVpYbwTzbGXPr69pZ6ae374drJIZRUrS.UcVfbKwbQVo_6iS52EFJXyhfMPZWxFYDFWp1ISyYTv6iw2d4yUjrezwOxJJ8YJCD74TIsHMjp56tPkdItCYIkS6Bg3e3S3bKHtKLu6ryfsjrX52Ip4Od7GhrBs9kJdFu3Ne8PnufKm_KSxoVbzo
Received: from [24.91.148.40] by web63605.mail.re1.yahoo.com via HTTP; Mon, 30 Nov 2009 09:12:30 PST
X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964
Date: Mon, 30 Nov 2009 09:12:30 -0800
From: Gerald Ash <gash5107@yahoo.com>
To: IETF-Announce <ietf-announce@ietf.org>, ietf@ietf.org, nsis@ietf.org
In-Reply-To: <20091111090906.07B5F28C112@core3.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-889216674-1259601150=:32970"
Subject: [NSIS] Maximum Packet Size Parameter <M> -- 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 <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2009 17:12:54 -0000
All, Al Morton has recently raised concerns RE taking the Maximum Packet Size <M> parameter out of the QSPEC document. Based on his comments (given below, along with other background), it appears that 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, Jerry Background: The Maximum Packet Size Parameter <M> was taken out back in July 2005 in QSPEC version 5, with the following explanation in the change history: " 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 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" <bschloer at cs.uni-goettingen.de>, <nsis at ietf.org> Subject: AW: [NSIS] smallest path MTU - Maximum Packet Size [M] From: "Kappler, Cornelia" <cornelia.kappler 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?subject=help> List-id: Next Steps in Signaling <nsis.ietf.org> List-post: <mailto:nsis@ietf.org> List-subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe> List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=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 <M> 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 <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 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 <M> in the TMOD parameter. It appears that the <M> parameter should be put back in the QSPEC. It should not be a big issue since <M> 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 <iesg-secretary@ietf.org> wrote: From: The IESG <iesg-secretary@ietf.org> Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC To: "IETF-Announce" <ietf-announce@ietf.org> 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 ' <draft-ietf-nsis-qspec-22.txt> 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] Last Call: draft-ietf-nsis-qspec (QoS NSLP… The IESG
- [NSIS] Maximum Packet Size Parameter <M> -- Re: L… Gerald Ash
- [NSIS] Maximum Packet Size Parameter <M> -- Re: L… Georgios Karagiannis
- Re: [NSIS] Maximum Packet Size Parameter <M> -- R… Gerald Ash
- Re: [NSIS] Maximum Packet Size Parameter <M> -- R… Georgios Karagiannis