From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4E2DB3CB36 for ; Wed, 4 Apr 2018 03:43:07 -0400 (EDT) Received: by mail-qt0-x22b.google.com with SMTP id d3so18806501qth.8 for ; Wed, 04 Apr 2018 00:43:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XgTFn29so9B7P9AJuBytqCAu6XFheQUbFtAeqSrZBQQ=; b=rooG2g4mFD/4aIxby4u+2Z5N3GWiJeVnLHZO4VcMOhag+dOW4qOzSmX3m48Lv/nYcM 8U437fzCnzXOj4OEagPUlozBaoib9Sa6IkjuA1wYPjj8scCgwpeQI1dEmenz0l6lCwIE dNUd6MDoW5gl7uFjnQp2wIRNDbGzONwLPvc6Kwo/zpFdNSIVT2MBwlAPmCNUQCJ7Bo27 dqAP04BOQ0CxNgU5da3s0hsb43iK7AAwAF96kxk/B7rxgAp9m4OhX63i03SFDv/8HapM QG62CIXtPPBcVxlOiMYpJVG+dCxUqR3mZxmAm5qzpYJ3S6ZMRzlz3ESHITYaA+csYr7o 2Idw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XgTFn29so9B7P9AJuBytqCAu6XFheQUbFtAeqSrZBQQ=; b=PdEkLoSByXUTxMd+1u8ca545iISTHIlzRMaB7RrBQCBpjr8ok88wu515zL8QoDHmob Jv19MRqxFKWfh/HZmN00zzwF3r9Aot7Slkq+mCPO3QLyoFRezZkgqXtL+l28xTR/iaYW oxECn9n/c2IhjFq6fa/4HbW1a7ac67MnYxv+0PaOA1CJLrDr14rrt7CbUfiNhO6MRMPK /xJANmAppRS9IBpTEJrKnirzBVxfdU0sU6rRWs+vqa+hfmstBan6quv6KMcyP2GNaKxR mxqBmLXHkG7AqNP6NszDFlF+HQUOiy9iy1QiEe6HMlmOCWDIGyl8UXbBt0TlPzK0QTpO EwyQ== X-Gm-Message-State: ALQs6tB5i4Y4TqtXYYYTgqq63YT+zejvJVMmyhyWPaqEGuTVyabvB/KB Y0j1OVH+5EhdbOqZoRAgjPIZEHL0wJwekveR/Gc= X-Google-Smtp-Source: AIpwx48wA7n5BKWt2W32D822YlzXNFZaCGSeg6+M9KxjkUytGcro7XMWQ9gPACU3JSVEax/rsxYquhBtp4YedripIA8= X-Received: by 10.200.102.71 with SMTP id j7mr11757952qtp.189.1522827786826; Wed, 04 Apr 2018 00:43:06 -0700 (PDT) MIME-Version: 1.0 References: <50e57074-4ca5-59f7-f010-d9b2b845a8a7@rogers.com> <8DE589C3-9537-416D-AC7C-9250464869F9@gmail.com> <0ED5B59A-5C31-4F70-A2C9-04D9EA779A7B@ifi.uio.no> In-Reply-To: <0ED5B59A-5C31-4F70-A2C9-04D9EA779A7B@ifi.uio.no> From: Dave Taht Date: Wed, 04 Apr 2018 07:42:55 +0000 Message-ID: To: Michael Welzl Cc: Jesper Louis Andersen , Jonathan Morton , bloat Content-Type: multipart/alternative; boundary="883d24f441f849b9a0056900f956" 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:43:07 -0000 --883d24f441f849b9a0056900f956 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How dead is posix these days? Ietf does not generally do apis well. On Tue, Apr 3, 2018, 9:14 AM Michael Welzl wrote: > > On Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen < > jesper.louis.andersen@gmail.com> wrote: > > On Tue, Apr 3, 2018 at 4:27 PM Michael Welzl wrote: > >> please, please, people, take a look at the ietf taps (=E2=80=9Ctransport >> services=E2=80=9D) working group :-) >> >> > I tried looking it up. It seems the TAPS WG is about building a consisten= t > interface to different protocols in order to get a new interface rather > than, say, the bsd socket interface. > > But my search turned up several drafts from the WG. Did you have one in > particular in mind? > > > 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 (lacking i= n > 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-i= nventing > there. Really, the transport layer can=E2=80=99t change as long as applic= ations (or > their libraries) are exposed to only the services of TCP and UDP, and > thereby statically bound to these transport protocols. > > I think I=E2=80=99d recommend this draft as a starting point: > https://taps-api.github.io/drafts/draft-trammell-taps-interface.html > > Cheers, > Michael > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --883d24f441f849b9a0056900f956 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How dead is posix these days? Ietf does not generally do = apis well.

On Tue, Apr= 3, 2018, 9:14 AM Michael Welzl <m= ichawe@ifi.uio.no> wrote:

O= n Apr 3, 2018, at 4:48 PM, Jesper Louis Andersen <jesper.lo= uis.andersen@gmail.com> wrote:

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


I tried looking it up= . It seems the TAPS WG is about building a consistent interface to differen= t protocols in order to get a new interface rather than, say, the bsd socke= t interface.

But my search turned u= p several drafts from the WG. Did you have one in particular in mind?

Thanks for taking a look!
=
Indeed, it=E2=80=99s about a consistent interface - I was provoked to = send this message by the reference to ossification, and talk of messages (l= acking in TCP).
Sure, when you=E2=80=99re in control of both ends= of a connection, 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 c= an=E2=80=99t change as long as applications (or their libraries) are expose= d to only the services of TCP and UDP, and thereby statically bound to thes= e transport protocols.

I think I=E2=80=99d recomme= nd this draft as a starting point: =C2=A0https://taps-api.github.io/drafts/draft-trammell-taps-interface.ht= ml

Cheers,
Michael

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat<= /a>
--883d24f441f849b9a0056900f956--