TD's for discussion at the Santiago meeting

Espen Skjæran (ETO) Espen.Skjaeran at ETO.ERICSSON.SE
Fri May 7 08:44:34 EDT 1999


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 at btinternet.com
=============================================

-----Original Message-----
From: Gur Kimchi <Gur_Kimchi at VOCALTEC.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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 at 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 at CISCO.COM]
>        Sent:   Wednesday, May 05, 1999 10:20 PM
>        To:     ITU-SG16 at 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 be
>added 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 offer
>another
>        perspective.  The RTP spec, RFC 1889, says the following:
>
>           Bandwidth calculations for control and data traffic include
>lower-
>           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 know
>how
>        much overhead the additional headers will add.
>                                                                -- Steve
>



More information about the sg16-avd mailing list