From dreibh@iem.uni-due.de Thu May 2 02:36:09 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755F721F98A9 for ; Thu, 2 May 2013 02:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 Oc0rb7Jz-6bL for ; Thu, 2 May 2013 02:36:05 -0700 (PDT) Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) by ietfa.amsl.com (Postfix) with ESMTP id B2A2121F98A2 for ; Thu, 2 May 2013 02:36:04 -0700 (PDT) Received: from kringsjaa.simula.nornet ([77.88.71.158]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id r429a08d022861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 May 2013 11:36:01 +0200 From: Thomas Dreibholz To: multipathtcp@ietf.org Date: Thu, 02 May 2013 11:36 +0200 Message-ID: <1757450.200yHnxk9L@kringsjaa.simula.nornet> Organization: University of Duisburg-Essen, Institute for Experimental Mathematics User-Agent: KMail/4.10.2 (Linux/3.2.0-40-generic; KDE/4.10.2; x86_64; ; ) In-Reply-To: References: <11033309.D2qUUIOfVk@kringsjaa.simula.nornet> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1386412.IGaOuUJOBv"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19 Cc: Ernst Gunnar Gran Subject: Re: [multipathtcp] Fwd: [iccrg] The NorNet Research Testbed for Multi-Homed Systems X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 09:36:09 -0000 --nextPart1386412.IGaOuUJOBv Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Yoshifumi, Tirsdag 30 april 2013 19.22.13 skrev Yoshifumi Nishida: > Hi, > This looks an interesting topic for mptcp. Indeed, it is! I intend to go to the upcoming IETF meeting in Berlin. Is there a possi= bility=20 to have a presentation slot during the MPTCP meeting, or should we writ= e an=20 Informational I-D? > ---------- Forwarded message ---------- > From: Thomas Dreibholz > Date: Tue, Apr 30, 2013 at 5:07 AM > Subject: [iccrg] The NorNet Research Testbed for Multi-Homed Systems > To: iccrg@irtf.org > Cc: Ernst Gunnar Gran , Amund Kvalbein >=20 >=20 > Hi all, >=20 > the Simula Research Laboratory in Fornebu, Norway (https://simula.no/= ) is > currently building up a large-scale Internet testbed for multi-homed > systems. > Therefore, this could be of interest for all researchers doing work o= n > congestion control for multi-homed systems, i.e. particularly also fo= r > multi- > path transport protocols like MPTCP and CMT-SCTP. >=20 > Our website http://www.nntb.no/ now contains some up-to-date informat= ion on > the NorNet project. The NorNet project is funded by the Research Coun= cil of > Norway (Forskningsr=E5det) as part of the INFRASTRUKTUR programme and= will be > an > open platform for all researchers on multi-homed systems, probably in= a > similar way as PlanetLab. Also, within the next few months -- possibl= y in > the > late summer/early autumn -- we will provide a workshop for interested= > researchers at the Simula Research Laboratory in Fornebu. More detail= s will > follow soon on our website. >=20 >=20 > Links: > - NorNet website: https://simula.no/ > - Simula Research Laboratory: http://www.nntb.no/ > - INFRASTRUKTUR (in Norwegian): > http://www.forskningsradet.no/servlet/Satellite?c=3DNyhet&pagename=3D= infrastrukt > ur%2FHovedsidemal&cid=3D1253966339813 --=20 Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Thomas Dreibholz Simula Research Laboratory Simula Innovation AS, Network Systems Group Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway Mailing address: P.O.Box 134, 1325 Lysaker, Norway -----------------------------------------------------------------------= E-Mail: dreibh@simula.no Homepage: http://simula.no/people/dreibh =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --nextPart1386412.IGaOuUJOBv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlGCM4AACgkQ32BbsHYPLWWpvwCePmr31WaXpEkziQC1MW1c1Dp6 WPIAnRD/4XrPUzW9JeMzWGFFEKDHtogs =Qcg9 -----END PGP SIGNATURE----- --nextPart1386412.IGaOuUJOBv-- From nishida@sfc.wide.ad.jp Thu May 2 22:18:44 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4244521F930C for ; Thu, 2 May 2013 22:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 b-rKDwuOTvl8 for ; Thu, 2 May 2013 22:18:43 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (ns.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:143]) by ietfa.amsl.com (Postfix) with ESMTP id 5385221F87FB for ; Thu, 2 May 2013 22:18:42 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id DBC6527809F for ; Fri, 3 May 2013 14:18:39 +0900 (JST) Received: by mail-la0-f54.google.com with SMTP id fd20so1210393lab.27 for ; Thu, 02 May 2013 22:18:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NpX1Eh/toVFHzc1+QZ4Gf/twqtbcF+K8i2i0lm4ZJSQ=; b=DSbUQMyHtel3XQpj8A03pHGR4KYJGZBBOIMQ+BH82fd5ryoFi6xY+D0kqurbPW0GO6 PxZTr7bzccLxBWGi9ZAQZhVI38ZtotGlWMfWaittuhKjnPBhG6h6BayH2Lde+jPWSfrq MW02MZyzxM6N8ptjAgDZ4FblEGVZT1wPMUB8XLNi1K83iX+HWAqFltnM75rjs1BpW2J+ yZN7n65CX33sG/4NjIXE+wvc6GnBEfLABTj+PygNnaZVvKG6myFRx2gUsAfdeNkcjKwj mqMUUtWK6SwgkwXjq4DFPNQRclL12kQF9rnCrCbRg4jAjdPy9fQwhiyH+RrsKvC1R7Pt tMYA== MIME-Version: 1.0 X-Received: by 10.112.126.9 with SMTP id mu9mr3747162lbb.99.1367558316953; Thu, 02 May 2013 22:18:36 -0700 (PDT) Received: by 10.114.62.237 with HTTP; Thu, 2 May 2013 22:18:36 -0700 (PDT) In-Reply-To: <1757450.200yHnxk9L@kringsjaa.simula.nornet> References: <11033309.D2qUUIOfVk@kringsjaa.simula.nornet> <1757450.200yHnxk9L@kringsjaa.simula.nornet> Date: Thu, 2 May 2013 22:18:36 -0700 Message-ID: From: Yoshifumi Nishida To: Thomas Dreibholz Content-Type: multipart/alternative; boundary=001a11c37864b1a65a04dbc97b41 Cc: multipathtcp , Ernst Gunnar Gran Subject: Re: [multipathtcp] Fwd: [iccrg] The NorNet Research Testbed for Multi-Homed Systems X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 05:18:44 -0000 --001a11c37864b1a65a04dbc97b41 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, On Thu, May 2, 2013 at 2:36 AM, Thomas Dreibholz wrote: > Hi Yoshifumi, > > Tirsdag 30 april 2013 19.22.13 skrev Yoshifumi Nishida: > > Hi, > > This looks an interesting topic for mptcp. > > Indeed, it is! > > I intend to go to the upcoming IETF meeting in Berlin. Is there a > possibility > to have a presentation slot during the MPTCP meeting, or should we write an > Informational I-D? > I'm sure there is a possibility. But, we even haven't decided if we'll have a meeting in Berlin yet. Once we decide, we'll call for presentations for the meeting. So, please wait a bit. You don't have to write an I-D, but please try to explain how this is related to mptcp when you submit a request for presentation. As long as it's related to mptcp, we'll try to allocate time for it. Thanks, -- Yoshifumi --001a11c37864b1a65a04dbc97b41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

<= div class=3D"gmail_quote">On Thu, May 2, 2013 at 2:36 AM, Thomas Dreibholz = <dreibh@iem.uni-due.de> wrote:
Hi Yoshifumi,

Tirsdag 30 april 2013 19.22.13 skrev Yoshifumi Nishida:
> Hi,
> This looks an interesting topic for mptcp.

Indeed, it is!

I intend to go to the upcoming IETF meeting in Berlin. Is there a possibili= ty
to have a presentation slot during the MPTCP meeting, or should we write an=
Informational I-D?

I'm sure t= here is a possibility. But, we even haven't decided if we'll have a= meeting in Berlin yet.
Once we decide, we'll call for = presentations for the meeting. So, please wait a bit.
You don't have to write an I-D, but please try to explain ho= w this is related to mptcp when you submit a request for presentation.
As long as it's related to mptcp, we'll try to allocate= time for it.

Thanks,
--
= Yoshifumi
--001a11c37864b1a65a04dbc97b41-- From philip.eardley@bt.com Fri May 3 10:02:26 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE7D21F9A53 for ; Fri, 3 May 2013 10:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 o5FfVbgvcjM9 for ; Fri, 3 May 2013 10:02:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id DE8DD21F8C9B for ; Fri, 3 May 2013 09:06:51 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 3 May 2013 17:06:47 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.241]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 3 May 2013 17:06:47 +0100 From: To: Date: Fri, 3 May 2013 17:06:46 +0100 Thread-Topic: MPTCP Implementation survey Thread-Index: Ac5IFk/uqkQAN6A+Q3G+1Ql6TgGUSQ== Message-ID: <9510D26531EF184D9017DF24659BB87F34684B50E3@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F34684B50E3EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] MPTCP Implementation survey X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:02:26 -0000 --_000_9510D26531EF184D9017DF24659BB87F34684B50E3EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If you're an MPTCP Implementer, it would be very much appreciated if you co= uld fill in our Implementation Survey. This is all part of our effort to upgrade MPTCP from Experimental to Standa= rds track - by showing there are several independent implementations and th= at the issues and protocol features have been carefully thought about and t= ested. We're also gathering feedback on the things that need to be improved - or n= eed to be deleted, as they haven't been implemented or not proved useful. http://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey If you have implemented MPTCP but not announced it, your reply would also b= e very much appreciated. The i-d suggests an anonymisation procedure; pleas= e invent something else if you prefer. If you (the implementation team) cannot answer a question, just skip it - p= artial responses will also be very valuable. Please return your completed survey to the MPTCP Chairs: Philip Eardley and Yoshifumi Nishida . Our hope is to get replies by roughly the end of May, so that there's plent= y of time for a summary of the responses to form a key part of a 'next step= s' discussion in Berlin. Also, if there's interest and implementers think it is worthwhile, we could= arrange an interop event for Berlin. Please let us know what you think. Thanks! Best wishes Phil & Yoshifumi. -- Survey of MPTCP Implementations (blank version for implementers to fill in) draft-eardley-mptcp-implementations-survey-01 Abstract This survey gathers information from people who have implemented MPTCP, in particular to help progress the protocol from Experimental to Standards track. It is ready to be filled in, if you are an implementer. Thank-you! --_000_9510D26531EF184D9017DF24659BB87F34684B50E3EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

If you’re an MPTCP Implementer, it would be ver= y much appreciated if you could fill in our Implementation Survey.

 

= This is all part of our effort to upgrade MPTCP from Experimental to Standa= rds track – by showing there are several independent implementations = and that the issues and protocol features have been carefully thought about= and tested.

We’re also gather= ing feedback on the things that need to be improved – or need to be d= eleted, as they haven’t been implemented or not proved useful.

 

 

<= p class=3DMsoNormal>If you have implemented MPTCP but not announced it, your re= ply would also be very much appreciated. The i-d suggests an anonymisation = procedure; please invent something else if you prefer.

 

If you (the= implementation team) cannot answer a question, just skip it - partial resp= onses will also be very valuable.

 

Please return your completed surv= ey to the MPTCP Chairs: Philip Eardley <philip.eardley@bt.com> and Yo= shifumi Nishida <nishida@sfc.wide.ad.jp>.

 

Our hope is to get = replies by roughly the end of May, so that there’s plenty of time for= a summary of the responses to form a key part of a ‘next steps’= ; discussion in Berlin.

 

Also, if there’s interest and impleme= nters think it is worthwhile, we could arrange an interop event for Berlin.= Please let us know what you think.

<= o:p> 

Thanks!

Best wishes

Phil &= Yoshifumi.

 =

--

Survey of MPTCP Implementations (blank version for implem=
enters to fill
          &nbs=
p;            &=
nbsp;          in)<=
/span>
  &nb=
sp;          draft-e=
ardley-mptcp-implementations-survey-01
 
<=
span lang=3DEN style=3D'font-size:10.0pt'>Abstract
<= pre> 
   This survey =
gathers information from people who have implemented
   MPTCP, in par=
ticular to help progress the protocol from Experimental
   to Standar=
ds track.
 
   It is ready to be filled in, if you are an implemente=
r.  Thank-you!
 
= --_000_9510D26531EF184D9017DF24659BB87F34684B50E3EMV65UKRDdoma_-- From steing@ifi.uio.no Wed May 15 08:11:50 2013 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) 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-Level: 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1UcdMl-0005Wl-5S; Wed, 15 May 2013 17:11:43 +0200 Received: from 1x-193-157-202-195.uio.no ([193.157.202.195]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from ) id 1UcdMk-0004fY-EU; Wed, 15 May 2013 17:11:43 +0200 From: Stein Gjessing Content-Type: multipart/alternative; boundary="Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93" Date: Wed, 15 May 2013 17:11:41 +0200 Message-Id: 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-SPF-Received: 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: 193.157.202.195 spam_score: -54 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 36 max/h 6 blacklist 0 greylist 0 ratelimit 0 Subject: [multipathtcp] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 15:11:50 -0000 --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Here is an excellent venue for discussions and publication of results. Cheers,=20 Stein __________________________________________________________ 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. =20 http://pv2013.itec.aau.at/call-for-papers/accepted-special-sessions/#ss1 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: =95 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. =95 Latency minimization has become a major goal, especially in = the face of =93bufferbloat=94: large delays from large buffers with = simplistic FIFO-queue management. =95 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. =95 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 = =93Real-time Media Congestion Avoidance Techniques=94 (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: =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms =95 Necessary RTP/RTCP extensions =95 Field experience with video codecs in a low-delay, real-time = setting =95 Interactions between applications and RTP flows =95 Failing to meet real-time schedules: impact, techniques to = detect, instrument or diagnose it Organizers: =95 Michael Welzl, University of Oslo (michawe at ifi.uio.no) =95 Stein Gjessing, University of Oslo (steing at ifi.uio.no)= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 http://pv2013.itec.aau.at/call-for-papers/accepted-special-session= s/#ss1

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:
=95 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.
=95 Latency minimization has = become a major goal, especially in the face of =93bufferbloat=94: large = delays from large buffers with simplistic FIFO-queue = management.
=95 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 =93Real-time Media Congestion Avoidance Techniques=94 = (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:
= =95 Congestion control algorithms for interactive real-time = video: requirements, evaluation criteria, and mechanisms
=95 = Necessary RTP/RTCP extensions
=95 Field experience with video = codecs in a low-delay, real-time setting
=95 Interactions between = applications and RTP flows
=95 Failing to meet real-time = schedules: impact, techniques to detect, instrument or diagnose = it

Organizers:
=95 Michael Welzl, University of = Oslo (michawe at ifi.uio.no)
=95 Stein = Gjessing, University of Oslo (steing at ifi.uio.no)= --Apple-Mail=_4CA7AC64-6758-4240-93E4-84B414877C93--