From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 7418E3B29E for ; Wed, 4 Apr 2018 03:55:19 -0400 (EDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1f3dGH-0002Zp-OJ; Wed, 04 Apr 2018 09:55:17 +0200 Received: from 93-58-133-64.ip158.fastwebnet.it ([93.58.133.64] helo=[10.0.0.3]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.90_1) (envelope-from ) id 1f3dGF-0001Vk-Hp; Wed, 04 Apr 2018 09:55:17 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-C7776660-D207-45FF-8618-CEEE696A0900 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (15D100) In-Reply-To: Date: Wed, 4 Apr 2018 09:55:03 +0200 Cc: Jesper Louis Andersen , Jonathan Morton , bloat Content-Transfer-Encoding: 7bit Message-Id: <53125778-8086-4228-836E-6C0CD833F81C@ifi.uio.no> References: <50e57074-4ca5-59f7-f010-d9b2b845a8a7@rogers.com> <8DE589C3-9537-416D-AC7C-9250464869F9@gmail.com> <0ED5B59A-5C31-4F70-A2C9-04D9EA779A7B@ifi.uio.no> To: Dave Taht X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 93.58.133.64 is neither permitted nor denied by domain of ifi.uio.no) client-ip=93.58.133.64; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.3]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C902AAFAAA4888D2E2F65BB165BF8C580E5A2E5D Subject: Re: [Bloat] Seen in passing: mention of Valve's networking scheme and RFC 5348 X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 07:55:19 -0000 --Apple-Mail-C7776660-D207-45FF-8618-CEEE696A0900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable well - they have been refusing too long to do them at all. i guess that=E2=80= =99s part of the problem Sent from my iPhone > On 4 Apr 2018, at 09:42, Dave Taht wrote: >=20 > How dead is posix these days? Ietf does not generally do apis well. >=20 >> On Tue, Apr 3, 2018, 9:14 AM Michael Welzl wrote: >>=20 >>> On Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen wrote: >>>=20 >>>> On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl wrote= : >>>> please, please, people, take a look at the ietf taps (=E2=80=9Ctranspor= t services=E2=80=9D) working group :-) >>>>=20 >>>=20 >>> I tried looking it up. It seems the TAPS WG is about building a consiste= nt interface to different protocols in order to get a new interface rather t= han, say, the bsd socket interface. >>>=20 >>> But my search turned up several drafts from the WG. Did you have one in p= articular in mind? >>=20 >> Thanks for taking a look! >> Indeed, it=E2=80=99s about a consistent interface - I was provoked to sen= d this message by the reference to ossification, and talk of messages (lacki= ng in TCP). >> Sure, when you=E2=80=99re in control of both ends of a connection, you ca= n build whatever you want on top of UDP - but there=E2=80=99s a lot of wheel= re-inventing there. Really, the transport layer can=E2=80=99t change as lon= g as applications (or their libraries) are exposed to only the services of T= CP and UDP, and thereby statically bound to these transport protocols. >>=20 >> I think I=E2=80=99d recommend this draft as a starting point: https://ta= ps-api.github.io/drafts/draft-trammell-taps-interface.html >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat --Apple-Mail-C7776660-D207-45FF-8618-CEEE696A0900 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable well - they have been refusing too long to d= o them at all. i guess that=E2=80=99s part of the problem

Sent from my iPhone

On 4 Apr 2018, at 09:4= 2, Dave Taht <dave.taht@gmail.com<= /a>> wrote:



On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl <micha= we@ifi.uio.no> wrote:
please, please, people, take a look at the ietf taps (=E2=80=9C= transport services=E2=80=9D) working group  :-)


I tried looking it up.= It seems the TAPS WG is about building a consistent interface to different p= rotocols in order to get a new interface rather than, say, the bsd socket in= terface.

But my search turned up sev= eral drafts from the WG. Did you have one in particular in mind?

Thanks for taking a look!
In= deed, it=E2=80=99s about a consistent interface - I was provoked to send thi= s message by the reference to ossification, and talk of messages (lacking in= TCP).
Sure, when you=E2=80=99re in control of both ends of a conn= ection, you can build whatever you want on top of UDP - but there=E2=80=99s a= lot of wheel re-inventing there. Really, the transport layer can=E2=80=99t c= hange as long as applications (or their libraries) are exposed to only the s= ervices of TCP and UDP, and thereby statically bound to these transport prot= ocols.

I think I=E2=80=99d recommend this draft as a= starting point:  https://tap= s-api.github.io/drafts/draft-trammell-taps-interface.html

=
Cheers,
Michael

_____________= __________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
= --Apple-Mail-C7776660-D207-45FF-8618-CEEE696A0900--