Hi, I am a student worker with the Internet Networks Architecture department at TU Berlin and I am working with APIs for network protocols. We are currently looking into implementing TAPS, a novel way to offer transport layer services to the application layer. The idea is to offer an API on top of multiple different transport protocols, such as TCP and QUIC. Instead of explicitly choosing a transport protocol, the application only provides abstract requirements, e.g., reliability. The TAPS system maps these properties to transport protocols, potentially trying out multiple protocols in parallel. Furthermore, TAPS can select between multiple local interfaces and remote IP addresses. A short talk (~25 minutes) from the All systems go! conference about it is available here: https://media.ccc.de/v/ASG2018-188-the_future_of_networking_apis. TAPS is currently being standardized in the IETF (https://datatracker.ietf.org/wg/taps/about/). Here you can find the proposed architecture: https://datatracker.ietf.org/doc/draft-ietf-taps-arch/, interface: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ and an informal draft on implementation considerations: https://datatracker.ietf.org/doc/draft-ietf-taps-impl/. One if the implementations currently in the works is done by Apple in form of their Network.framework API (https://developer.apple.com/documentation/network). While this implementation is relatively advanced, it is so far only available for MacOS, iOS and it derivatives. As such, it would be favorable to have a platform agnostic and open-source implementation as well.
From what we can tell, asyncio seems to offer a lot of the ground work necessary to implement it efficiently, so here are some questions we have before beginning with the implementation:
- Is something like this in the scope to become part of the standard python library or something that would be done in an external library? If it is in scope, what would the requirements for it to become part of the standard library be? - Are there currently any other active efforts to implement new network functionality into the standard library? - Are there currently any considerations to expand the standard transports offered by asyncio (TCP, UDP and SSL) by additional ones like SCTP, or more importantly QUIC? Any comments or further pointers to sources that could be helpful with this would be greatly appreciated. Best regards Max
Hi Max, and welcome! On Mon, Dec 10, 2018 at 09:47:07PM +0000, Franke, Maximilian Julian Shawn wrote: [...]
These are factors which strongly go against TAPS being implemented in the standard library: it is novel and the usage of it is unproven, and it hasn't been standardized yet. Generally speaking, the Python standard library only provides proven, standardized protocols. A few reasons for this: - We don't have the resources of Apple, we can't support everything, so we have to choose those which are most likely to be useful; that means those with a proven track-record, not experimental or novel protocols. - We take backwards-compatibility seriously, so with a few exceptions, any API we offer would have to be stable. (There are ways around this, but we don't use them lightly.) - The Python release cycle is relatively sedate and slow, and experimental libraries usually need a much faster release cycle. This is not to absolutely rule out a std lib implementation. If the networking experts among the core developers think this is a good idea, it could happen, regardless of how novel it is. But in the meantime, I recommend that you consider writing a library and offering it on PyPI as a third-party library: https://pypi.org/ If you are still keen to push for a standard library implementation, you will probably need to write a PEP: https://www.python.org/dev/peps/ At the very least, reading over some successful PEPs will suggest what sort of arguments you should make in order to get TAPS approved. -- Steve
On Tue, 11 Dec 2018 09:31:36 +1100 Steven D'Aprano <steve@pearwood.info> wrote:
I agree that TAPS doesn't look proven at all (I would also add that I'm a bit skeptical it will achieve the stated goals -- but we'll see). IMO it's not a good candidate for standard library inclusion. Regards Antoine.
Hi Max, and welcome! On Mon, Dec 10, 2018 at 09:47:07PM +0000, Franke, Maximilian Julian Shawn wrote: [...]
These are factors which strongly go against TAPS being implemented in the standard library: it is novel and the usage of it is unproven, and it hasn't been standardized yet. Generally speaking, the Python standard library only provides proven, standardized protocols. A few reasons for this: - We don't have the resources of Apple, we can't support everything, so we have to choose those which are most likely to be useful; that means those with a proven track-record, not experimental or novel protocols. - We take backwards-compatibility seriously, so with a few exceptions, any API we offer would have to be stable. (There are ways around this, but we don't use them lightly.) - The Python release cycle is relatively sedate and slow, and experimental libraries usually need a much faster release cycle. This is not to absolutely rule out a std lib implementation. If the networking experts among the core developers think this is a good idea, it could happen, regardless of how novel it is. But in the meantime, I recommend that you consider writing a library and offering it on PyPI as a third-party library: https://pypi.org/ If you are still keen to push for a standard library implementation, you will probably need to write a PEP: https://www.python.org/dev/peps/ At the very least, reading over some successful PEPs will suggest what sort of arguments you should make in order to get TAPS approved. -- Steve
On Tue, 11 Dec 2018 09:31:36 +1100 Steven D'Aprano <steve@pearwood.info> wrote:
I agree that TAPS doesn't look proven at all (I would also add that I'm a bit skeptical it will achieve the stated goals -- but we'll see). IMO it's not a good candidate for standard library inclusion. Regards Antoine.
participants (3)
-
Antoine Pitrou -
Franke, Maximilian Julian Shawn -
Steven D'Aprano