Subject: Re: [NSIS] Maximum Packet Size Parameter <M> -- Re: Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC

From: Jukka Manner <[email-masked]>
Date: Tue, 08 Dec 2009 07:22:57 +0200

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-masked]
>       <http://www.ietf.org/mail-archive/web/nsis/current/msg07916.html>>
>     * /List-help/: <mailto:[email-masked]?subject=help>
>     * /List-id/: Next Steps in Signaling <nsis.ietf.org
>       <http://nsis.ietf.org>>
>     * /List-post/: <mailto:[email-masked]>
>     * /List-subscribe/: <https://www1.ietf.org/mailman/listinfo/nsis>,
>       <mailto:[email-masked]?subject=subscribe>
>     * /List-unsubscribe/: <https://www1.ietf.org/mailman/listinfo/nsis>,
>       <mailto:[email-masked]?subject=unsubscribe>
>     * /References/: <[email-masked]
>       <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-masked]>/* wrote:
> 
> 
>     From: The IESG <[email-masked]>
>     Subject: [NSIS] Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC
>     Template) to Informational RFC
>     To: "IETF-Announce" <[email-masked]>
>     Cc: [email-masked]
>     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-masked]
>     <http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]> mailing
>     lists by 2009-11-25. Exceptionally,
>     comments may be sent to [email-masked]
>     <http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>
>     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-masked]
>     <http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>
>     https://www.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> 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-masked]
Finland                           WWW:    www.comnet.tkk.fi