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

Varun Singh <vsingh.ietf@gmail.com> Mon, 04 November 2013 18:07 UTC

Return-Path: <vsingh.ietf@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51511E8117; Mon, 4 Nov 2013 10:07:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw9MiKPBSkM1; Mon, 4 Nov 2013 10:06:59 -0800 (PST)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1700C11E812B; Mon, 4 Nov 2013 10:06:56 -0800 (PST)
Received: by mail-ie0-f180.google.com with SMTP id e14so12652268iej.39 for <multiple recipients>; Mon, 04 Nov 2013 10:06:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=qn3hlVoSN94zfRmOH4bDPTixPJF0CA4SbpCBAvhvEeo=; b=JAV5cx6mCjQZPz0bnk4g4YFx7bZ9H25/6CEz61ri12m98rZovljen5H4TFVRXjp9Kq XKf8CM9iDTTtN8LImODnWLQlIqQXKoGSmAT5we+94k4u0yc4ztG+NjiMaa9pzUeDlmJn KdBQMGI8KEEDhnfBpNv+zA5ReHY7IJTR+cMeznDa28KUrbRR4vZu1zNZX4e4UGHjRhqz IiRxDFLfTYMmF8XYCj/fVANBuR1iHxhUtUxxzO97B8kxMjIshLB1J0CfKvNFCKgD+BrQ UrkGNj+mKz5SzXq6g2pF5bZzgbAaB9am+q2ysXJux5D8M0ZOzITICtKDIWhoJd8tQ7VK y2eQ==
X-Received: by 10.50.39.51 with SMTP id m19mr12679666igk.51.1383588414417; Mon, 04 Nov 2013 10:06:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.102.8 with HTTP; Mon, 4 Nov 2013 10:06:34 -0800 (PST)
In-Reply-To: <CAEbPqrzCMUM=8khZsCensa7q3V8LtRsv1XeuOHHMdm7UGoQeXg@mail.gmail.com>
References: <CAEbPqrxbMa_xGr6SqXnoxh10zKRfhm_r83i=_aGdbaLAC_cL0Q@mail.gmail.com> <CAEbPqrzCMUM=8khZsCensa7q3V8LtRsv1XeuOHHMdm7UGoQeXg@mail.gmail.com>
From: Varun Singh <vsingh.ietf@gmail.com>
Date: Mon, 04 Nov 2013 10:06:34 -0800
Message-ID: <CAEbPqryG3fcrBY0bNSebLf36-f=-GibY_8c+1Cu5zrBUbSZE3A@mail.gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, "avt@ietf.org" <avt@ietf.org>, rmcat WG <rmcat@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [AVTCORE] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 18:07:02 -0000

Hi,

Slideset from yesterday's meeting are available at:
https://speakerdeck.com/vr000m/media-traffic-generator-discussion
Note takers, if you could send the notes to me, I can then process and
post them to the mailing lists.

Cheers,
Varun

On Wed, Oct 30, 2013 at 6:49 AM, Varun Singh <vsingh.ietf@gmail.com> wrote:
> 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 <vsingh.ietf@gmail.com> 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/



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