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

Varun Singh <vsingh.ietf@gmail.com> Sun, 27 October 2013 10:57 UTC

Return-Path: <vsingh.ietf@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8B66511E8162; Sun, 27 Oct 2013 03:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DDG+d24J07X4; Sun, 27 Oct 2013 03:57:34 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCAB11E8144; Sun, 27 Oct 2013 03:57:34 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id u16so9158984iet.4 for <multiple recipients>; Sun, 27 Oct 2013 03:57:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=mymBHQPqvBP7FJmEqZ+rUEcI3Mc1FnVw+ZxkAaruUBg=; b=esd2rUZmHNV84VUnnZXB0b00Yh8JcvzG5PmnUYzm0fo3/Xxz/0l3HVMhuXmN/W54g7 MsRyxGz1HTYfOpEWluRJL8b3+80N6qCmeqpgI1VM2PDvbJYeSxA0VELGvfl5i07Ck77y q2o3F4xD5enTbVkJcApDXV/PEK5poAuHAXAQ87KaIrlC40RRF7N+8qL5yEAWYJZKnDCd WLipNbDQ2Vgyh4AiKiaPv9Y3RgoXWtk9QRbTXXfofUGsRVnHrIiF6+Fg21W1x2fob2Ma DiMJBXqeg48qQ3uDe69MAhWXlHVGMpK0y+9utUUHKFDDVDBE1QEnjJTUpDfoNbzwZnDS kTjA==
X-Received: by with SMTP id q8mr4891071igw.14.1382871453857; Sun, 27 Oct 2013 03:57:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 27 Oct 2013 03:57:13 -0700 (PDT)
From: Varun Singh <vsingh.ietf@gmail.com>
Date: Sun, 27 Oct 2013 12:57:13 +0200
Message-ID: <CAEbPqrxbMa_xGr6SqXnoxh10zKRfhm_r83i=_aGdbaLAC_cL0Q@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: [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: Sun, 27 Oct 2013 10:57:35 -0000

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

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 .


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

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)