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/
- [AVTCORE] Discussion on RMCAT traffic model in Va… Varun Singh
- Re: [AVTCORE] Discussion on RMCAT traffic model i… Varun Singh
- Re: [AVTCORE] Discussion on RMCAT traffic model i… Varun Singh