Re: Maximum Packet Size Parameter <M> -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC
Jukka Manner <[email protected]> Tue, 08 Dec 2009 07:22:57 +0200
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
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 <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/: <[email protected] > <http://www.ietf.org/mail-archive/web/nsis/current/msg07916.html>> > * /List-help/: <mailto:[email protected]?subject=help> > * /List-id/: Next Steps in Signaling <nsis.ietf.org > <http://nsis.ietf.org>> > * /List-post/: <mailto:[email protected]> > * /List-subscribe/: <https://www1.ietf.org/mailman/listinfo/nsis>, > <mailto:[email protected]?subject=subscribe> > * /List-unsubscribe/: <https://www1.ietf.org/mailman/listinfo/nsis>, > <mailto:[email protected]?subject=unsubscribe> > * /References/: <[email protected] > <http://www.ietf.org/mail-archive/web/nsis/current/msg07916.html>> > * /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 <http://cs.uni-goettingen.de>] >> Gesendet: Dienstag, 29. Mai 2007 23:31 >> An: nsis at ietf.org <http://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 /<[email protected]>/* wrote: > > > From: The IESG <[email protected]> > Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC > Template) to Informational RFC > To: "IETF-Announce" <[email protected]> > Cc: [email protected] > 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 > [email protected] > <http://us.mc636.mail.yahoo.com/mc/[email protected]> mailing > lists by 2009-11-25. Exceptionally, > comments may be sent to [email protected] > <http://us.mc636.mail.yahoo.com/mc/[email protected]> > 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 > <https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12323&rfc_flag=0> > > _______________________________________________ > nsis mailing list > [email protected] > <http://us.mc636.mail.yahoo.com/mc/[email protected]> > https://www.ietf.org/mailman/listinfo/nsis > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > [email protected] > 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: [email protected] Finland WWW: www.comnet.tkk.fi