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

From: "Ingemar Johansson S \(LU/EAB\)" <[email-masked]>
Date: Tue, 13 Feb 2007 11:00:25 +0100

Hi

My humble opinion is that it is unrealistic to assume that the
application has any knowledge whatsoever about the use of header
compression, this applies esp. to RoHC. One could perhaps argue that
RoHC will be used in 3GPP rel 7 but here the implementor/operator have
full freedom to choose to use-or-not-to-use RoHC, it is more or less a
"coffee with cream" issue. That said RoHC is highly recommended to use.

There is some possibility that the application could get know the use of
header compression in a terminal but this knowledge only applies to the
radio interface closest to the terminal. Moreover this is to be regarded
as a vendor specific (dreadful crosslayer) feature and I don't belive
that one should rely on such things in a proposed standard.

I bet my "5 kronor" on alternative d)

Ingemar

> Message: 2
> Date: Mon, 12 Feb 2007 15:07:32 -0800
> From: Dave Singer <[email-masked]>
> Subject: RE: [AVT] CCM draft review -- should "bandwidth" include
> 	theheaderoverhead
> To: [email-masked]
> Message-ID: <p06230914c1f6a200bde6@[17.202.35.52]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 
> On the question of what bitrate to send, it depends on who knows what:
> 
> "Please send me a stream that fits through a constriction of 
> x kb/s. And
> a) I know that ROHC is in use through that constriction;
> b) I know it is not;
> c) I don't know;  if you do, then you can do the partitioning;
> d) I don't know, and if you don't either, assume the worst 
> (i.e. that it is not)."
> 
> My suspicion is that we have to signal (c, d), and that (d) 
> is the most likely outcome.  That is, we include headers 
> unless the sender knows to the contrary.
> 
> 
> On the question of "what is bitrate", I'd suggest that we say 
> that the source was traffic-smoothed to not exceed x.  By 
> that I mean, if I send a packet of Y kbits, then the next 
> packet is sent no earlier than Y/x seconds later.  
> Alternatively, the bitrate is the max over all consecutive 
> pairs of packets [i,i+1] of
> (timestamp(i+1) - timestamp(i))/size(i)
> 
> which is harsh, but otherwise we'll have to define a leaky 
> bucket model, or an averaging interval.  Both of these either 
> require signalling the size of the ingest buffer to the 
> constriction, or assuming it, neither of which are pleasant.
> --
> David Singer
> Apple Computer/QuickTime

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