RE: [AVT] CCM draft review -- should "bandwidth" include theheaderoverhead

["Desineni, Harikishan" <[e-mail]>]

That doesn't sound good to me. It complicates the definition and
confuses the implementers on what to use and when. 

Just one definition for TMMBR would be cleaner. Majority is towards
using it as pure media bitrate. 

I don't think 3GPP SA4 understand transport details that well as it is
not their core area. They depend on IETF to decide what is good in
general.

Thanks,
Hari

> -----Original Message-----
> From: Stephan Wenger [mailto:[e-mail]]
> Sent: Monday, February 12, 2007 5:07 AM
> To: Even, Roni
> Cc: Randell Jesup; Magnus Westerlund; [e-mail]
> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include
> theheaderoverhead
> 
> Folks,
> 
> I have a proposal in the best tradition of ITU-T standardization :-):
> let's do it both.
> 
> Roni has compelling arguments, I believe, for the interpretation of
> the TMMBR bitrate as the codec bitrate only.  I agree with him that
> using the codec bitrate opens cross-protocol application spaces that
> would otherwise be closed.  And, the codec bitrate is not affected by
> ROHC, IPv4/v6 issues, and so on.
> 
> Magnus and others have suggested that including the header overhead
> makes sense as well, almost certainly for all-IP scenarios.  It's
> also what most folks assume in 3GPP SA4, which is going to be the
> first "customer" for TMMBR.
> 
> So let's do it both.  We can signal the interpretation by a bit in
> the header (sliced off from the bitrate---there are enough bits), or
> we can make this dependent on signaling.  I have a slight preference
> for the latter.
> 
> How does this sound?
> 
> Regards,
> Stepha
> 
> 
> On Feb 12, 2007, at 11:32 AM, Even, Roni wrote:
> 
> > Randell,
> > I think part of the discussion is because there is a lack of
> > application
> > usage.
> > For example, on a gateway between H.320 and SIP you need to limit
the
> > codec BW bellow the circuit switch rate. Same for a mixed conference
> > that has ISDN as well as SIP or H.323 parties.
> > This is why in H.323 and H.320 the rate is the codec rate
> > Roni Even
> >
> >> -----Original Message-----
> >> From: Randell Jesup [mailto:[e-mail]]
> >> Sent: Sunday, February 11, 2007 6:26 PM
> >> To: Even, Roni
> >> Cc: Magnus Westerlund; Stephan Wenger; [e-mail]
> >> Subject: Re: [AVT] CCM draft review -- should "bandwidth" include
the
> >> headeroverhead
> >>
> >> "Even, Roni" <[e-mail]> writes:
> >>> This is our view about why to use the codec bit rate and not any
> >>> overhead. We have to remember that this is mostly for video who
does
> > not
> >>> have a fixed frame size and that packets can be larger than MTU
size
> > and
> >>> thus may be broken differently based on implementations.
> >>
> >> Which is why TIAS (especially with TMMBR) is fundamentally broken
for
> >> offer/answer.  TIAS allows setting the max packet rate - fine for a
> >> declarative use, but for offer/answer, it means that the receiver
> > knows
> >> the
> >> actual bandwidth (typically configured - "I have a 1Mbps
downstream",
> >> perhaps measured/probed, but usually NOT probed end-to-end to the
> > sender),
> >> it must (to send TIAS) follow RFC 3890 #6.4 in reverse, using a
> >> (high)
> >> guess at maxprate.  When done, you basically have
> >> TIAS = BW - (maxprate*hsize).
> >>
> >> So the sender limits their codec to TIAS, and probably uses a lot
> >> less
> >> than
> >> maxprate packets, wasting that bandwidth.  If maxprate was chosen
too
> > low,
> >> the sender might have to (for video) reduce frame rate, especially
if
> > (as
> >> you mention) the sender wants to send more packets than the
receiver
> >> anticipates.  If the sender goes over maxprate, it might work, and
> > might
> >> not, and there's no way for the sender to estimate how much to
reduce
> > the
> >> TIAS amount by other than guessing.
> >>
> >> I think b=AS (etc) make more sense; the sender knows the actual
> >> prate,
> >> size
> >> of any headers it sends, and so can make best use of of the
available
> >> bits.
> >> If we need to know any additional header/etc modifications
inbetween
> > the
> >> sender and receiver, then we should find a mechanism to discover
> > and/or
> >> signal that directly.
> >>
> >>> For one thing, the amount of data in the headers depends on
whether
> >> header
> >>> compression is in use.  Since header compression can be applied
(or
> >>> removed) anywhere along the path, the amount of overhead seen by
the
> >>> receiver might be different than the overhead seen by the
> > transmitter.
> >>
> >> And how does the receiver making an offer or answer determine this?
> > The
> >> receiver typically only knows the last-link settings.
> >>
> >>> Another reason is that an intermediate device (gateways, proxies,
or
> >> other
> >>> RTP media engine) might be re-packetizing the data.  This would
also
> >>> create a mismatch between the source and the receiver.  All of
this
> > is
> >>> avoided if we define the bit rate to be the media rate.
> >>
> >> Avoided: not really.  I'd say pushed off into some undefined
> > mechanism.
> >> Or, if not handled, you're not really solving the problem.
> >>
> >>> A third way a mismatch can be created is by encryption, where an
> >>> encryption pad is added (or possibly removed) at the campus
> >>> edge.  So
> > I'd
> >>> also want that RTP padding to be excluded from the definition (not
> > just
> >>> the headers).
> >>
> >> And again, how does the receiver know this to include it in the
TIAS
> >> calculation?  If this is an RTP/RTCP-aware midbox, it could adjust
BW
> >> values - if *everything* that can modify bandwidth is aware and
> > handles
> >> TIAS in offers and TMMBR, you could adjust TIAS by (maxprate *
> >> packet_delta), but in reality I don't see this happening.  BTW, any
> >> end-to-end signalling or media encryption will cause a major
headache
> > here
> >> - the midbox can't see/modify these values.  At best it could in
some
> >> cases
> >> signal the modification separately or in a separate tag at call
> >> setup,
> > but
> >> that's not an option with current protocols.
> >>
> >>> Of course, we'd also prefer to keep it as media because that is
what
> > both
> >>> H.323 and H.320 do and part of the usage of this command is to
adapt
> >> rates
> >>> between different transport channels.
> >>
> >> I'd say then push the burden of converting to bandwidth into media
> > rate
> >> onto the converter, not into every endpoint (especially since using
> > these
> >> conversions seems to require either a lot of assumptions or
> > potentially
> >> wastes bandwidth).
> >>
> >> I think I'm pretty much in agreement with Magnus here.
> >>
> >> Magnus also writes:
> >>>> Guido's idea of including the average packet overhead might
> > actually
> >> not
> >>>> be a bad one. As that would allow the sender to take into
> > consideration
> >>>> the per packet overhead seen by the TMMBR sending receiver. I
would
> >>>> define that overhead as the number of bytes in addition to RTP
> > payload.
> >>>> The reason to include the RTP header itself is that if there are
> > some
> >>>> translator or mixer doing something to expand the RTP header.
> >>
> >> This speaks to my comment above about finding a way to signal
> >> overhead
> >> separate from link bandwidth.
> >>
> >> --
> >> Randell Jesup, Worldgate (developers of the Ojo videophone),
ex-Amiga
> > OS
> >> team
> >> [e-mail]
> >> "The fetters imposed on liberty at home have ever been forged out
of
> > the
> >> weapons
> >> provided for defence against real, pretended, or imaginary dangers
> > from
> >> abroad."
> >> 		- James Madison, 4th US president (1751-1836)
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt