Re: [Taps] extending the meeting a few minutes to accommodate another talk

Brian Trammell <ietf@trammell.ch> Sun, 17 July 2016 11:31 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E38E126579 for <taps@ietfa.amsl.com>; Sun, 17 Jul 2016 04:31:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.189
X-Spam-Level:
X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBwvvXmuIk9k for <taps@ietfa.amsl.com>; Sun, 17 Jul 2016 04:31:13 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D0DEB12B031 for <taps@ietf.org>; Sun, 17 Jul 2016 04:31:12 -0700 (PDT)
Received: from dhcp-b49f.meeting.ietf.org (dhcp-b49f.meeting.ietf.org [31.133.180.159]) by trammell.ch (Postfix) with ESMTPSA id 9DDB61A04CD; Sun, 17 Jul 2016 13:31:11 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_D6EAEEAD-ED32-4EBC-92CA-394E3AA0FEB8"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <DFD8EF4A-C880-43FF-9ADB-9FCA16917C96@gmail.com>
Date: Sun, 17 Jul 2016 13:31:11 +0200
Message-Id: <39E21339-EBB0-4552-8D2D-7F82CC068122@trammell.ch>
References: <73A3FD28-F2FE-43BB-9789-8F45E5462175@gmail.com> <2FA95D67-B0D3-4B92-95FE-F2B0EA8C66F8@trammell.ch> <DFD8EF4A-C880-43FF-9ADB-9FCA16917C96@gmail.com>
To: Aaron Falk <aaron.falk@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/9i7kWpSPiVhXoYI4-VNG9Xj7x10>
Cc: Stephen McQuistin <sm@smcquistin.uk>, taps@ietf.org
Subject: Re: [Taps] extending the meeting a few minutes to accommodate another talk
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Jul 2016 11:31:15 -0000

> On 17 Jul 2016, at 13:28, Aaron Falk <aaron.falk@gmail.com> wrote:
> 
> OK but information is lost with excessive compression.  So, no heroics.  :)

It'll be a lightning talk in the sense of "it's an ad to read the rest of the slides, and come talk to us if you have questions".

Cheers,

Brian

> 
> —aaron
> 
>> On Jul 17, 2016, at 1:27 PM, Brian Trammell <ietf@trammell.ch> wrote:
>> 
>> hi Aaron,
>> 
>>> On 17 Jul 2016, at 13:22, Aaron Falk <aaron.falk@gmail.com> wrote:
>>> 
>>> Hi Folks-
>>> 
>>> Yesterday there was an interesting talk at the IRTF/ACM Applied Networking Research Workshop that is relevant to TAPS.  Since our slot is only an hour and our agenda already full, I would like to propose extending the meeting 10 minutes to accommodate it.  We’ll be eating into the free time before the Bits-and-Bytes social so I don’t think anyone will miss any scheduled activities but I am aware that folks sometimes schedule meetings during the breaks. I hope this doesn’t inconvenience anyone.
>>> 
>>> Here is the abstract of the ANRW talk and the updated agenda:
>>> 
>>> Implementing Real-Time Transport Services over an Ossified Network
>>> 
>>> Stephen McQuistin (University of Glasgow), Colin Perkins (University of Glasgow), and Marwan Fayed (University of Stirling)
>>> 
>>> Real-time applications require a set of transport services not currently provided by widely-deployed transport protocols. Ossification prevents the deployment of novel protocols, restricting solutions to protocols using either TCP or UDP as a substrate. We describe the transport services required by real-time applications. We show that, in the short-term (i.e., while UDP is blocked at current levels), TCP offers a feasible substrate for providing these services. Over the longer term, protocols using UDP may reduce the number of networks blocking UDP, enabling a shift towards its use as a demultiplexing layer for novel transport protocols.
>>> 
>>> https://irtf.org/anrw/2016/anrw16-final25.pdf
>>> 
>>> 
>>> Updated TAPS agenda:
>>> 
>>> 1. Chairs update - 5min
>>> 
>>> 2. Update on draft-ietf-taps-transports-usage - 10 min (Naeem Khademi ) – updated draft promised by the authors.
>>> 
>>> 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry Fairhurst) – already updated.
>>> 
>>> 4. Update on draft-gjessing-taps-minset - 10 min (Michael Welzl) - updated draft promised by the authors.
>>> 
>>> 5. Investigation on the use on happy eyeballs for transport protocol selection - 10 min (Anna Brunström)
>>> 
>>> 6. Post socket - 10 min (Brian Trammell)
>> 
>> I can do these as a lightning talk to make this go faster. So, s/10 min/5 min/..
>> 
>> Cheers,
>> 
>> Brian
>> 
>> 
>>> 7. Socket intents - 5 min (Philipp Tiesel)
>>> 
>>> 8. Implementing Real-Time Transport Services over an Ossified Network - 10 miin (Stephen McQuistin)
>>> 
>>> See you Thursday,
>>> 
>>> —aaron
>>> 
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>> 
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps