Re: [AVTCORE] 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: 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 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: "Eggert, Lars" <lars@netapp.com>, Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>, Colin Perkins <csp@csperkins.org>
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: 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/