Re: [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)
Varun Singh <vsingh.ietf@gmail.com> Wed, 30 October 2013 13:49 UTC
Return-Path: <vsingh.ietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8DE11E8167; Wed, 30 Oct 2013 06:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level:
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 hghbUF61OJsO; Wed, 30 Oct 2013 06:49:54 -0700 (PDT)
Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 092AD11E8174; Wed, 30 Oct 2013 06:49:53 -0700 (PDT)
Received: by mail-ie0-f177.google.com with SMTP id e14so2252811iej.22 for <multiple recipients>; Wed, 30 Oct 2013 06:49:53 -0700 (PDT)
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 :cc:content-type; bh=3wDQGBZXwBfou3hv2wsrPfdt81Bq5W/6wzhuIiqh0HA=; b=WsMNyZokkQJgTRQfcapxVwWUXPOZQcnOugCBsYsNo8Gktunxgx2jEw9CDnkQNF+a7F ND8olXhALot9piOGjJWdQN67zuNqjFceMwBqqU5EvKmwK/Z4dS/5ALSO/TNikh0T2ru4 joQpw5fwescwLx5j2erpLg/lZK/APbk9uIoAHg38sbX/Oy4FRY6CQ//UiqAyQsBiKSYn 8x2s3LonK3aS/l3Ybl8+LdNQEAD3ubynltuZsruj/3QoE/8s2S18msA5YhyWXDi2xRM/ q0djlqhMrRvgkGvtKRjAP9crH+kTI+GnE5iZUP8DHJwSucaNu0eQXMk9QoiQ2lDwsNMD zXPg==
X-Received: by 10.50.77.72 with SMTP id q8mr2534284igw.14.1383140993330; Wed, 30 Oct 2013 06:49:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.102.8 with HTTP; Wed, 30 Oct 2013 06:49:33 -0700 (PDT)
In-Reply-To: <CAEbPqrxbMa_xGr6SqXnoxh10zKRfhm_r83i=_aGdbaLAC_cL0Q@mail.gmail.com>
References: <CAEbPqrxbMa_xGr6SqXnoxh10zKRfhm_r83i=_aGdbaLAC_cL0Q@mail.gmail.com>
From: Varun Singh <vsingh.ietf@gmail.com>
Date: Wed, 30 Oct 2013 15:49:33 +0200
Message-ID: <CAEbPqrzCMUM=8khZsCensa7q3V8LtRsv1XeuOHHMdm7UGoQeXg@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"
Cc: Colin Perkins <csp@csperkins.org>
Subject: Re: [rtcweb] Discussion on RMCAT traffic model in Vancouver (03 Nov, 1300-1500)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 13:49:56 -0000
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/
- [rtcweb] Discussion on RMCAT traffic model in Van… Varun Singh
- Re: [rtcweb] Discussion on RMCAT traffic model in… Varun Singh
- Re: [rtcweb] Discussion on RMCAT traffic model in… Varun Singh