RE: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM draftreview -- should"bandwidth"includetheheaderoverhead

["Franceschini Guido" <[e-mail]>]

> Guido, I think you meant
> 
> At time t0:
> "-receiver R2 sends TMMBR(45 kbps, 50 bytes)" instead of 
> "-receiver R2 sends TMMBR(35 kbps, 40 bytes)" 

Yes, thanks!
> 
> Your explanation looks straight forward to me. 
> 
> A sender need not maintain a list of tmmbr tuples all the 
> time. Only the active limitation needs to be stored. Whenever 
> a new TMMBR tuple is received, it needs to do just one 
> comparison to determine whether a TMMBN with new limitation 
> is necessary. No complexity involved there.

A downside of your algorithm is that if the current limitation (and only stored limitation in the server) is due to Rn, and Rn now communicates an higher limit, your server does not know to what higher limit to move.
IMO we should not over-specify here: the complex algorithm from Magnus and Bo is one, mine is another, your yet another one ==> it's an implementation matter, that balances complexity and effectiveness.
 
> I see one difference when I compared your example with the 
> example from Magnus. Magnus interpreted the first element in 
> the tuple as pure header overhead. Your example interpreted 
> it as total bit-rate up to particular protocol layer 
> including codec media bit-rate.

The key aspect of my suggestion here, is that each peer communicates accurate data, no guesses.
The accurate data that a receiver can communicate relates to the <TIDC, MPO> tuple (hopefully measured at the most precise layer of its stack); it has no control on the packet rate, thus it should better not imply any.
The accurate data that a sender can communicate relates to <media bitrate, maxpacketrate>, which are both under its control.
This works nicely in p2p as well as in p2mp.
Note that the metrics generated by the sender correspond to the <TIAS, maxprate> tuple already defined in RFC3890 !
 
> If I map your example to a simple p2p session:
> SDP offer includes the TMMBR tuple (Max 'receive' rate, 
> 'recv' per packet overhead) and SDP answer includes TMMBN 
> tuple (Max 'send' codec media bit-rate, max 'send' packet 
> rate). Max receive rate in TMMBR tuple includes both codec 
> media rate and header overhead due to protocol layers. 

Exactly (we only need to find good definitions for such semantics, so that we get uniform on this)
Guido

PS: the computation of the RTP Header extension is somehow disputable. Should it be part of the media bitrate figure (TIAS) provided by the sender (it should not, per RFC3890)? Should it be part of the mean packet overhead (MPO) figure provided by the receiver (it should, since it is overhead, but it should not, since it is not under the control of the receiver)?
IMO this is a detail that we could disregard for the time being: maybe the solution could be to identify a bw portion that can be assigned to RTP Header Extension, similarly to RTCP.

 
> --Hari
> 
> > -----Original Message-----
> > From: Franceschini Guido 
> [mailto:[e-mail]]
> > Sent: Friday, February 23, 2007 5:31 AM
> > To: Magnus Westerlund
> > Cc: [e-mail]
> > Subject: RE: Issues with using tuples in TMMBR was:Re: R: [AVT] CCM
> > draftreview -- should"bandwidth"includetheheaderoverhead
> > 
> > Magnus,
> > 
> > let me first check if I have understood your scenario. Then 
> I'll give my
> > view on your mail: just disregard it if I missed to understand the
> > scenario in the first place.
> > 
> > 
> > Scanario: a sender S and multiple receivers R1, R2 ... RN
> > 
> > The sender is notified of a number of bottlneck tuples B1, 
> B2 ... BN, each
> > expressed for a potentially different stack.
> > Based on some internal logic, the sender decides how to encode and
> > packetize its traffic, and also acknowledges with TMMBN to let each
> > receiver aware of the currently valid limits.
> > 
> > If the above is correct, then let's go on.
> > 
> > There is a set of challenges in this scenario:
> > 
> > 1) identification of the most restrictive bottleneck among 
> the B1 ... BN
> > 2) generation of the TMMBN to let receiver know about the current
> > restriction
> > 3) reduction of useless TMMBR traffic
> > 4) accuracy of the Bx data
> > 
> > Concerning 1) identification of the most restrictive 
> bottleneck among the
> > B1 ... BN
> > 
> > The usage of a tuple instead of a single value allows for a 
> more accurate
> > description, but it is easy to derive from an accurate 
> description a less
> > accurate one ;-)
> > More specifically, if you indicated in the TMMBR the IP 
> gross bitrate, or
> > the media bitrate, you were actually impling some 
> packetrate (actually,
> > the generator of the TMMBR implied a maxpacketrate). You 
> can now apply as
> > well a maxpacketrate, with the advantage that you are now 
> the sender, and
> > can therefore apply a more close-to-reality maxpacketrate.
> > Suppose you apply a maxpacketrate of 50; you would obtain from:
> > (35 kbps, 40 bytes) ==> 35000-(40*50*8)=19000
> > (45 kbps, 50 bytes) ==> 45000-(50*50*8)=25000
> > 
> > Thus, you go back to the same complexity that you have to 
> deal with anyway,
> > with just a better accuracy (the sender applied a uniform 
> and credible
> > maxpacketrate, instead of having each receiver applying his 
> own guess).
> > Also, the sender knows that it must not exceed 50 pkt/sec.
> > 
> > 
> > Concerning 2) generation of the TMMBN to let receiver know about the
> > current restriction
> > 
> > Here the goal is to let each receiver aware of the current 
> limits, so that
> > it will generate new TMMBR only if they have an impact on 
> the sender.
> > It is definitely undesirable that the sender generates a 
> TMMBN listing all
> > tuples that it is currently taking into account.
> > But if the TMMBN contains a different tuple, made of:
> > <media bitrate, maxpacketrate>
> > then each receiver is again able to determine whether it 
> should send a
> > TMMBR or not.
> > Let's use the figures above:
> > 
> > at time t0:
> > - receiver R1 sends TMMBR(35 kbps, 40 bytes)
> > - receiver R2 sends TMMBR(35 kbps, 40 bytes)
> > ==> sender sends TMMBN(19000, 50 pkt/sec, R1)
> > 
> > at time t1:
> > - R2 changes from (45 kbps, 50 bytes) to (40 kbps, 50 bytes)
> > ==> R2 computes that 19000 + (50*50*8) = 39000, thus does 
> not send TMMBR
> > 
> > at time t2:
> > - R2 changes to (38 kbps, 50 bytes)
> > ==> R2 sends TMMBR
> > - Sender computes (38 kbps, 50 bytes) ==> 38000-(50*50*8)=18000
> > ==> sender sends TMMBN(18000, 50 pkt/sec, R2)
> > 
> > 
> > Concerning 3) reduction of useless TMMBR traffic
> > 
> > The above algorithm shows how the usage of tuples instead 
> of single values
> > can be managed with the same efficiency
> > 
> > 
> > Concerning 4) accuracy of the Bx data
> > 
> > The usage of tuples instead of single values allows, even 
> in such p2mp
> > scenario, to compute more accurate limits.
> > 
> > 
> > To conclude: IMHO the usage of tuples have no CONS with 
> respect to picking
> > up a single value, while providing benefits instead.
> > 
> > Cheers
> > Guido
> > 
> > 
> > > -----Original Message-----
> > > From: Magnus Westerlund [mailto:[e-mail]]
> > > Sent: venerdì 23 febbraio 2007 11.38
> > > To: Magnus Westerlund
> > > Cc: Franceschini Guido; [e-mail]
> > > Subject: Issues with using tuples in TMMBR was:Re: R: 
> [AVT] CCM draft
> > > review -- should"bandwidth"includetheheaderoverhead
> > >
> > >
> > > Bo and me has spent some time thinking about what we see as
> > > one of the
> > > major real problems with using tuples in TMMBR. As one 
> changed TMMBR
> > > from a one-dimensional problem to a two dimensional problem,
> > > the concept
> > > of a single owner of the restriction took a hike. Thus we end
> > > up with a
> > > need to indicate multiple tuples that are the active
> > > restrictions. This
> > > will create extra complexities. There will also be more data
> > > to transmit.
> > >
> > > We are working on this, and haven't yet verified and 
> simulated it to
> > > understand the full implications. However we do like to share
> > > this with
> > > you to provide you the opportunity to think about the same
> > > problem and
> > > possibly find any issues we have forgotten about. Our current
> > > proposal
> > > for how this would work is the following:
> > >
> > > Lets start assuming that there is a session with a number of
> > > participants. They can all have restriction tuples (bit-rate,
> > > overhead).
> > > So if a media receiver has some change he first checks if the
> > > new values
> > > are an actually restriction compared to the current set of
> > > restrictions
> > > in the session. If that is the case it sends a TMMBR 
> message to the
> > > media sender. The media sender checks the restriction 
> compared to its
> > > current set and see if that is an actual restriction 
> given its sets
> > > (remember the asynchronous behavior in a multi-party 
> session) and if
> > > that allows it to drop some of the previous restriction 
> as being less
> > > restrictive then the new one. Then it sends out the TMMBN with the
> > > current set.
> > >
> > > So how does on determine which is the current set of 
> restrictions. Me
> > > and Bo have been kicking around an algorithm that might
> > > result in this.
> > > However we need to spend some time on verification.
> > >
> > > 1. First sort the set X of restriction tuples according 
> to bit-rate
> > > creating a vector of tuples, X1 to Xn with the X1 
> carrying the lowest
> > > bit-rate and Xn the highest value.
> > >
> > > 2. Eleminate all tuples in X with a overhead value 
> smaller than the
> > > value in X1.
> > >
> > > 3. Repeat step 2 for all elements in X from the lowest to the
> > > next highest.
> > >
> > > 4. A reduced set X has been created.
> > >
> > > The above algorithm eliminates all the tuples that 
> doesn't provide a
> > > restriction because they allow a higher bit-rate and 
> their bit-rate
> > > grows slower than the previous one when packet-rate increases.
> > >
> > > A second step would be to eliminate all tuples where they
> > > although have
> > > higher bit-rate, the overhead value is only slightly larger
> > > so that the
> > > first restriction does not allow a packet rate that is 
> large enough,
> > > even when all the allowed bit-rate is spent on headers. 
> An example to
> > > illustrate this:
> > >
> > > Lets say that you have a tuple of (35kbps, 40 bytes) and 
> a second one
> > > that is (45 kbps, 50 bytes).  The maximum packet rate the 
> first one
> > > allows are 35000 /(40*8) = 109.375 packets / s. 
> Performing the same
> > > calculation for the second tuple yields 45000/(50*8) = 112.5
> > > packets/s.
> > > Thus the second tuple does not provide a restriction that is
> > > applicable
> > > given that the first one is included in the set.
> > >
> > > 5. For each tuple in X calculate the largest possible packet-rate
> > > yielding no useful work, i.e. bit-rate / overhead and store
> > > in vector Y.
> > >
> > > 6. For each element in X, index by i, in case Yi+1 is 
> larger than Yi
> > > remove Yi+1 and Xi+1 from the sets and repeat comparison for i.
> > >
> > > However looking at the above there is evident that one 
> could do more
> > > here with some additional information. The comparison using
> > > packet rates
> > > that means no useful data is transported is easy to do but doesn't
> > > restrict as well as is possible. There exist two parameters
> > > that could
> > > be introduced into this to provide restrictions that exist in real
> > > usage. However these values needs to be the same and known to all
> > > session participants to be possible to utilize.
> > >
> > > The first one would to explicit declare the maximum 
> packet rate the
> > > application has any usage of at all for this media. For 
> example this
> > > could be restricted by codec, or by the codec in 
> combination with the
> > > session maximum bit-rate. This maximum packet rate value
> > > would allow one
> > > to eliminate from the set of restriction all tuples whose bit-rate
> > > divided by overhead is larger than the session maximum 
> packet-rate.
> > >
> > > A second possible restriction would to declare a minimum of useful
> > > rtp-payload bit-rate. In many cases the media codec or
> > > application has
> > > knowledge about what the smallest bit-rate that would provide any
> > > utility from the media at all. For example for an audio 
> session using
> > > the AMR speech codec packetized in RTP (RFC 3267), that
> > > bit-rate would
> > > be 4.75kbps. I ignore the per frame and RTP payload 
> overhead in this
> > > case, but those could be considered to be included also. 
> This minimal
> > > overhead could then be subtracted from all the tuples 
> bit-rate values
> > > prior to running the above presented algorithm. Note that 
> this second
> > > restriction needs to be applied prior to the first one if
> > > both where to
> > > be present.
> > >
> > > What these restrictions provides are some application sanity
> > > restrictions on what possible combination of useful bit-rate
> > > and maximum
> > > packet rate it can produce and still do some good. However
> > > these would
> > > need to be signaled and could also result in some dispute
> > > during session
> > > establishment if the applications aren't agreeing on a value.
> > >
> > > So the big question to you is: Is solving the inaccuracy 
> problem that
> > > introducing a tuple solves worth the extra complexities 
> and overhead?
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > > IETF Transport Area Director & TSVWG Chair
> > > 
> ----------------------------------------------------------------------
> > > Multimedia Technologies, Ericsson Research EAB/TVA/A
> > > 
> ----------------------------------------------------------------------
> > > Ericsson AB                | Phone [phone]
> > > Torshamsgatan 23           | Fax   [phone]
> > > S-164 80 Stockholm, Sweden | mailto: 
> [e-mail]
> > > 
> ----------------------------------------------------------------------
> > >
> > --------------------------------------------------------------------
> > 
> > CONFIDENTIALITY NOTICE
> > 
> > This message and its attachments are addressed solely to 
> the persons above
> > and may contain confidential information. If you have 
> received the message
> > in error, be informed that any use of the content hereof is 
> prohibited.
> > Please return it immediately to the sender and delete the 
> message. Should
> > you have any questions, please contact us by replying to
> > [e-mail].
> > 
> >         Thank you
> > 
> >                                         www.telecomitalia.it
> > 
> > --------------------------------------------------------------------
> > 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/avt
> 
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [e-mail].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------
                        

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