FW: BOF on Transport Services (TAPS)

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

FW: BOF on Transport Services (TAPS)

Adrian Farrel(IETF CCAMP WG)
Some folk maybe don't realise, but routing is a consumer of transport services
(wow, layer inversion or what?)

You might be interested in this BoF and the mail below originally sent to
encourage participation by the Applications community.

Adrian

> -----Original Message-----
> From: apps-discuss [mailto:[hidden email]] On Behalf Of Michael
> Welzl
> Sent: 29 January 2014 14:40
> To: [hidden email]
> Subject: [apps-discuss] BOF on Transport Services (TAPS)
>
> Dear all,
>
> A BOF called "TAPS" has been approved as a non-WG-forming BOF in London.
> The point of this activity is to move away from applications choosing "TCP" or
> "UDP" by letting them select a service instead. This is bound to let the
transport
> layer evolve - details are at:
> https://sites.google.com/site/transportprotocolservices/
>
> Much of this is about the API that the transport layer exposes to
applications. We
> had a bar BOF in Vancouver, where the major criticism was that we might be
> ignoring what applications *really* want, as many aren't really using the
socket
> layer anyway. We're trying to counter this criticism as good as we can,
because
> we really do want to do something useful here, something that does help
> applications. e.g., if the socket layer provided a richer set of services than
"TCP"
> and "UDP", some of these services might be reasonably replicated in
higher-level
> APIs; also, these higher-level APIs could be improved by using a richer set of
> services underneath - we've begun analyzing some in draft-hurtig-tsvwg-
> transport-apis
>
> What's more, if there was a common API that's independent of the transport
> protocol, it wouldn't be necessary to implement functions like PMTUD, things
for
> middlebox traversal etc. in the application per protocol, but these functions
could
> be taken care of underneath the API, leading to a better integrated networking
> stack.
>
> At this point, I'm hoping for folks from the applications area to join our
mailing list

> and participate in discussions - raise your concerns there and help us create
> something that will really be useful. the list management page is at:
> https://sympa.uio.no/ifi.uio.no/info/transport-services
>
> Cheers,
> Michael
>
> _______________________________________________
> apps-discuss mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________
routing-discussion mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/routing-discussion