From fluffy@iii.ca Thu May 2 21:20:32 2013 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B36021F90A1 for ; Thu, 2 May 2013 21:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, DEAR_SOMETHING=1.605] 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 AzL8HcnxATZZ for ; Thu, 2 May 2013 21:20:28 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id ECE0B21F8F06 for ; Thu, 2 May 2013 21:20:26 -0700 (PDT) Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7520F22E256; Fri, 3 May 2013 00:20:20 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Cullen Jennings In-Reply-To: <20130427175429.E0AF7E6736@smtp.hushmail.com> Date: Thu, 2 May 2013 22:20:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <04171876-F6A8-4A36-9388-2A44AA949DA6@iii.ca> References: <20130427175429.E0AF7E6736@smtp.hushmail.com> To: hammondjohnson@hushmail.com X-Mailer: Apple Mail (2.1503) Cc: video-codec@ietf.org Subject: Re: [video-codec] Biggest Fake Conference in Computer Science X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 04:20:32 -0000 Dear Sirs,=20 While I appreciate the information you provide in pointing out dubious = conferences and publications, as a generally rule, that is not an = appropriate use of this mailing list and I would respectfully ask you to = not do so in the future.=20 However, since we are on the topics of where to publish your paper=85. = We at the IETF definitely encourage publications from a diversity of = sources. I assure you that no matter how low you think the standard of = WORLDCOMP are, at the IETF our standards are even lower. We definitely = won't charge you $500 to publish your paper. In fact you can do submit = it at https://datatracker.ietf.org/submit/ if you can figure out our = strangely complex rules on how to format your paper. I'm pretty sure the = only thing we will review is that your email address in your paper is = correct and that you managed to pass the test that you can get the = correct boiler plate text in the draft. You can consider this as our = form of a captcha to rate limit submissions from humans but still keep = it easy for bots.=20 Now you might think, why would anyone publish at a place with a lower = bar than WORLDCOMP, and yes, I agree, good question. But think about it = - this is a publication at the IETF or at least tools.ietf.org. Some = people consider the IETF to be the most successful standards = organization ever. IP from any country tends to interoperate with IP in = every other country. Big companies, small companies, and fortune 100 = companies have referenced these publications as it they are golden = standards by themselves. Whole dot com companies have been launched on = them. They have been used in tenure applications, resum=E9s have been = padded, bird cages have been lined.=20 I aplaude your efforts to strive for the highest of quality in = scientific publishing, but something has to be the chaff in the wheat of = science. And if it involves the internet, just wanted to let you know = the IETF is always here for any internet publication.=20 Cullen=20 PS - I do wish you luck in spreading the word about bogus conferences.=20= On Apr 27, 2013, at 11:54 AM, hammondjohnson@hushmail.com wrote: > We are researchers from different parts of the world and conducted a = study on =20 > the world=92s biggest bogus computer science conference WORLDCOMP=20 > ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid = Arabnia=20 > from University of Georgia, USA. >=20 >=20 > We submitted a fake paper to WORLDCOMP 2011 and again (the same paper=20= > with a modified title) to WORLDCOMP 2012. This paper had numerous=20 > fundamental mistakes. Sample statements from that paper include:=20 >=20 > (1). Binary logic is fuzzy logic and vice versa > (2). Pascal developed fuzzy logic > (3). Object oriented languages do not exhibit any polymorphism or = inheritance > (4). TCP and IP are synonyms and are part of OSI model=20 > (5). Distributed systems deal with only one computer > (6). Laptop is an example for a super computer > (7). Operating system is an example for computer hardware >=20 >=20 > Also, our paper did not express any conceptual meaning. However, it=20= > was accepted both the times without any modifications (and without=20 > any reviews) and we were invited to submit the final paper and a=20 > payment of $500+ fee to present the paper. We decided to use the=20 > fee for better purposes than making Prof. Hamid Arabnia (Chairman=20 > of WORLDCOMP) rich. After that, we received few reminders from=20 > WORLDCOMP to pay the fee but we never responded.=20 >=20 >=20 > We MUST say that you should look at the above website if you have any = thoughts=20 > to submit a paper to WORLDCOMP. DBLP and other indexing agencies have = stopped=20 > indexing WORLDCOMP=92s proceedings since 2011 due to its fakeness. See=20= > http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of = one of the=20 > conferences of WORLDCOMP and notice that there is no listing after = 2010. See Section 2 of > http://sites.google.com/site/dumpconf for comments from well-known = researchers=20 > about WORLDCOMP.=20 >=20 >=20 > The status of your WORLDCOMP papers can be changed from scientific > to other (i.e., junk or non-technical) at any time. Better not to have = a paper than=20 > having it in WORLDCOMP and spoil the resume and peace of mind forever! >=20 >=20 > Our study revealed that WORLDCOMP is a money making business,=20 > using University of Georgia mask, for Prof. Hamid Arabnia. He is = throwing=20 > out a small chunk of that money (around 20 dollars per paper published=20= > in WORLDCOMP=92s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. = Solo)=20 > who publicizes WORLDCOMP and also defends it at various forums, using=20= > fake/anonymous names. The puppet uses fake names and defames other = conferences > to divert traffic to WORLDCOMP. He also makes anonymous phone calls = and tries to=20 > threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above = website).=20 > That is, the puppet does all his best to get a maximum number of = papers published=20 > at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia=92s) = pockets.=20 >=20 >=20 > Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, = until 2012) has=20 > refused to provide the venue for WORLDCOMP=9213 because of the fears = of their image=20 > being tarnished due to WORLDCOMP=92s fraudulent activities. That is = why WORLDCOMP=9213=20 > is taking place at a different resort. WORLDCOMP will not be held = after 2013.=20 >=20 >=20 > The draft paper submission deadline is over but still there are no = committee=20 > members, no reviewers, and there is no conference Chairman. The only = contact=20 > details available on WORLDCOMP=92s website is just an email address!=20= >=20 > Let us make a direct request to Prof. Hamid arabnia: publish all = reviews for=20 > all the papers (after blocking identifiable details) since 2000 = conference. Reveal=20 > the names and affiliations of all the reviewers (for each year) and = how many=20 > papers each reviewer had reviewed on average. We also request him to = look at=20 > the Open Challenge (Section 6) at = https://sites.google.com/site/moneycomp1=20 >=20 >=20 > Sorry for posting to multiple lists. Spreading the word is the only = way to stop=20 > this bogus conference. Please forward this message to other mailing = lists and people.=20 >=20 >=20 > We are shocked with Prof. Hamid Arabnia and his puppet=92s activities=20= > http://worldcomp-fake-bogus.blogspot.com Search Google using the=20 > keyword worldcomp fake for additional links. >=20 > _______________________________________________ > video-codec mailing list > video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec From steing@ifi.uio.no Wed May 15 08:11:50 2013 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@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 Cc: Stein Gjessing Subject: [video-codec] CFP Packet Video 2013 - Special Session on Low-Latency Interactive Video X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Video codec BoF discussion list 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-- From tterribe@xiph.org Mon May 20 23:03:35 2013 Return-Path: X-Original-To: video-codec@ietfa.amsl.com Delivered-To: video-codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A347421F971C for ; Mon, 20 May 2013 23:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 lgVRQugJnoaS for ; Mon, 20 May 2013 23:03:30 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 74D7A21F9728 for ; Mon, 20 May 2013 23:03:30 -0700 (PDT) Received: from [172.17.0.5] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 82F88F234B for ; Mon, 20 May 2013 23:03:28 -0700 (PDT) Message-ID: <519B0E2F.3040004@xiph.org> Date: Mon, 20 May 2013 23:03:27 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: video-codec@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [video-codec] Daala Coding Party X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 06:03:35 -0000 Mozilla and the Xiph.Org Foundation are organizing a coding party next week (May 27th-31st) at the Mozilla headquarters in Mountain View to start moving our Daala project from a research platform to a working codec prototype. Anyone is welcome to come hack on things. Details can be found here: https://daala.etherpad.mozilla.org/coding-party Please e-mail me (not the list) if you plan to attend, so someone will be expecting you and so we can order enough food.