[aqm] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video

Stein Gjessing <steing@ifi.uio.no> Wed, 15 May 2013 15:11 UTC

Return-Path: <steing@ifi.uio.no>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 53DBF21F8F83; Wed, 15 May 2013 08:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iGIrVo0PEbGg; Wed, 15 May 2013 08:11:45 -0700 (PDT)
Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E8FA821F8AD8; Wed, 15 May 2013 08:11:44 -0700 (PDT)
Received: from mail-mx2.uio.no ([]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from <steing@ifi.uio.no>) id 1UcdMl-0005Wl-5S; Wed, 15 May 2013 17:11:43 +0200
Received: from 1x-193-157-202-195.uio.no ([]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from <steing@ifi.uio.no>) id 1UcdMk-0004fY-EU; Wed, 15 May 2013 17:11:43 +0200
From: Stein Gjessing <steing@ifi.uio.no>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93"
Date: Wed, 15 May 2013 17:11:41 +0200
Message-Id: <F68194DC-B2B2-45FF-832D-37F24AA57D24@ifi.uio.no>
To: aqm@ietf.org, rtcweb@ietf.org, lmap@ietf.org, tsvwg@ietf.org, rmcat@ietf.org, multipathtcp@ietf.org, video-codec@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 2607 max rcpts/h 28 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.5, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.551, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 45A26AF8F0515C0711EDC4E4402EEAD2BB95E78D
X-UiO-SPAM-Test: remote_host: spam_score: -54 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 36 max/h 6 blacklist 0 greylist 0 ratelimit 0
Cc: Stein Gjessing <steing@ifi.uio.no>
Subject: [aqm] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2013 15:11:50 -0000

Here is an excellent venue for discussions and publication of results.


Packet Video 2013   -   Special Session on Low-Latency Interactive Video
Sponsored by IEEE Communications Society
December 12. and 13., 2013, San Jose, Ca, USA

Call for papers.    


Several years ago, it was found that users do not like video quality fluctuations. At that time the predominant belief was that network rate fluctuations should be minimized, in order to reasonably interoperate with TCP in the network. This led to the creation of a number of so-called "TCP-friendly" congestion controls that exhibit a smoother sending rate than TCP, while avoiding to send more than a conformant TCP under similar conditions. TFRC is perhaps the best known example of such a congestion control mechanism.

A lot has happened since then:
	• The notion of TCP-friendliness has received massive criticism; the widespread deployment of a more aggressive TCP variant, CUBIC, has not led to an Internet meltdown, making the case that diverging from strict TCP-friendliness is possible.
	• Latency minimization has become a major goal, especially in the face of “bufferbloat”: large delays from large buffers with simplistic FIFO-queue management.
	• Codecs have improved; novel video codecs are able to adjust the data rate, but modern codecs may also produce variable bitrate transmissions with burstier packet flows than before.
	• TFRC has been embedded in the DCCP protocol, which has probably never been used for anything other than experiments; instead of running over DCCP, RTP-based applications now contain proprietary congestion control mechanisms.

The emergence of the RTCWEB protocol suite for real-time communication between Web browsers has renewed the interest in developing congestion control standards for real-time media. This time, however, the goal is to get things right: delay should be minimized, and standards should realize congestion control using RTP with RTCP signaling. The IETF “Real-time Media Congestion Avoidance Techniques” (RMCAT) working group has been founded to address this need. New questions arise: what type of congestion controls do we need? How much feedback should we send? How do we make this work in multi-user scenarios, e.g., for video conferencing? What should be the API between a video codec and a new delay-based congestion controlled RTP stream? What is the quality that can be expected from the combination of a codec and congestion control mechanism, when we consider better metrics than plain PSNR?

Topics of interest include, but are not limited to:
	• Congestion control algorithms for interactive real-time video: requirements, evaluation criteria, and mechanisms
	• Necessary RTP/RTCP extensions
	• Field experience with video codecs in a low-delay, real-time setting
	• Interactions between applications and RTP flows
	• Failing to meet real-time schedules: impact, techniques to detect, instrument or diagnose it

	• Michael Welzl, University of Oslo (michawe at ifi.uio.no)
	• Stein Gjessing, University of Oslo (steing at ifi.uio.no)