Re: [AVTCORE] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)

[Varun Singh <[e-mail]>]

Hi all,

Practical details for the meeting on **RMCAT Traffic models**

Date: 03.11. 2013
Time: 12:30 to 14:30.
Assigned Room: Regency A

Cheers,
Varun

On Sun, Oct 27, 2013 at 12:57 PM, Varun Singh <[e-mail]> wrote:
> Hi all,
>
> In RMCAT WG there has been discussion surrounding the use
> of a media traffic generator and to facilitate discussion,
> RMCAT is hosting a side meeting on Sunday, 03 November
> at 1300-1500. I suppose the room details will be announced
> shortly.
>
> Below is a list of questions that will help design or choose
> an appropriate traffic generator for Interactive multimedia traffic.
> The list is an initial set and mainly to foster discussion both
> on the mailing list and at the meeting.
>
> Mirja and Lars are not available that day, hence on their behalf,
> the meeting is hosted by Colin and I .
>
> Cheers,
> Varun
> ---
>
> Traffic generator: to model the intrinsic variability of video:
>
> - what target bit rates can be achieved? (max?, min?)
> - how much variability in media bit rate for a given target bit rate
> - how to model motion? capturing high motion leads to bursty video
>   (higher than target bit rate), but by how much? can this even be done?
>
> Traffic generator: on responsiveness to a new target bitrate:
>
> - how quickly can the codec generate a lower bit rate?
> - immediately? does this depend on the new or requested bit rate?
> - what is immediately? is it next frame or a few frames later, until then
>   does it generates at the current rate?
> - if not immediately, what bitrates (and duration) will it generate before
>   meeting the target bitrate.
>
>
> - how quickly can the codec generate a higher bit rate?
> - immediately in the next frame? does this also depend on the new
>    or requested bit rate?
> - not immediately but in steps of intermediate bitrates, i.e., intermediate
>   bitrate for a short duration then an increase in step, repeating until
>   reaching the target bit rate.
>
> - If the target bit rate is achieved in steps, can they be announced to the
>   congestion controller, i.e., the congestion controller knows the ramp up
>   curve to meet the target bit rate.
>
> - If the media bit rate has not yet reached the requested target bit rate and
>   the congestion control requests a new target bit rate, how does the codec
>   respond?
>
> Application design related:
> - should the congestion control be able to change the frame rate (video) or
>   packetization time (audio) or is this something that the application controls.
> - should the congestion control be able to change video resolution?
> - should error-repair: NACKs, FEC be considered part of congestion control or
>   outside it, i.e., it is something that the application does and not
>   congestion control
> - If FEC is controlled by the congestion control, how quickly can the sending
>   rate be adapted by reducing/adding redundancy (FEC)? is something link this
>   done? Does this makes sense at all?
> - Apart from loss and RTT, what other congestion cues are currently used by
>   congestion control algorithms? e.g., Decoding rate/goodput, application
>   decode error rate, ECN, PCN, etc.
> - If the codec is data limited, i.e., producing a sending rate smaller than the
>   one calculated by the congestion control, can the congestion control probe
>   the bandwidth by sending additional data packets in a certain pattern (e.g.,
>   PathChirp)? would somehting link this help?
> - application input on prioritization: audio vs video (vs data)
>
>
>
>
>
> --
> http://www.netlab.tkk.fi/~varun/



-- 
http://www.netlab.tkk.fi/~varun/