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 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