Let's not get too trigger happy here!
The original intent of flowControl is to constrain the bit rate of a channel to something such as a video decoder can cope with. In the past these tended to be MIPS limited, and bit rate tended to be a major (although not only) parameter that affecting the number of MIPS required. Note that in this case this was bits of video data and had nothing to do with headers etc. flowControl is also used to control the rate at which gateways receive things like video data. This allows the gateways to squirt the data down fixed bit rate pipes such as parts of ISDN B channels. Again this figure is not interested in packet overhead.
Use of flowControl in the QoS arena is the most recent of its uses. Therefore, even if it is broken in this context, it is not appropriate to change its definition as it would fix one problem and break two others!
However, I don't believe it is actually broken in the latter context. In the QoS case, the flowControl command is really only used to switch the channel on and off. The transmitter knows at which rate it will send, and puts this in the RSVPParameters part of the OLC. This information is presumably also put in the RSVP PATH Sender TSPEC.
Even if it is desired to allow flowControl to change the channel rate, a transmitter that receives a flowControl message can work out what it requires to add in terms of headers, and then change the RSVP PATH TSPEC accordingly. This will get to the receiver, which will send RESV using the new spec. As the transmitter knows what it is going to do in terms of packetisation and the receiver can only guess, this seems the right way round to me.
Pete
============================================= Pete Cordell pete.cordell@btinternet.com =============================================
-----Original Message----- From: Gur Kimchi Gur_Kimchi@VOCALTEC.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@MAILBAG.INTEL.COM Date: 07 May 1999 04:41 Subject: Re: flowControlCommand and packet overhead
Paul Wrote:
The value in consistently using the same, although arguably flawed, bandwidth calculations outweighs the benefit of having a mix of calculations.
I don't quite agree, this is the type of corrections that should make into the Implementer's guide. When you calculate for a few sessions it does not make much of a difference, but there are high-scale GWs and GKs based on 323 out in the market (supporting multiple DS3s) and the offset will be too much - it will effect network provisioning.
- gur
Gur Kimchi Corporate Director, Advance Technologies, Research and Standards VocalTec Communications Ltd web: http://www.vocaltec.com
-------- On 05/06/99 04:04 PM GMT Paul Long Plong@SMITHMICRO.COM wrote:
Steve,
But H.323, the referencing document via H.225.0 of RFC 1889, says that bandwidth for the open logical channel bitrate and ARQ is calculated _without_ headers. We cannot change this, because it would break existing implementations. Are you suggesting that flowControlCommand should do it differently, i.e., include at least the RTP header? The value in consistently using the same, although arguably flawed, bandwidth calculations outweighs the benefit of having a mix of calculations.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Stephen Casner [SMTP:casner@CISCO.COM] Sent: Wednesday, May 05, 1999 10:20 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: flowControlCommand and packet overhead On Wed, 28 Apr 1999, Paul Long wrote: > Therefore, clarification text to the following effect should beadded to > 6.2.11.2 (in v2) of H.323: > > "flowControlCommand applies to the information streams which are the > content of logical channel(s), not including RTP headers, RTP payload headers, > network headers and other overhead."
I'm mostly a lurker on this list, but I thought I would offeranother perspective. The RTP spec, RFC 1889, says the following:
Bandwidth calculations for control and data traffic includelower- layer transport and network protocols (e.g., UDP and IP) since that is what the resource reservation system would need to know. The application can also be expected to know which of these protocols are in use. Link level headers are not included in the calculation since the packet will be encapsulated with different link level headers as it travels.
At a minimum, I would expect the RTP payload header to be included because that is specific to the encoding and would not be known by lower layers. The difficulty in pushing this problem off to lower layers is that they need to know the packet rate in order to knowhow much overhead the additional headers will add. -- Steve