Minutes IETF113: taps
minutes-113-taps-01

TAPS 113:

Chairs update (Aaron Falk, Theresa Enghardt)

(AF presenting, see also chair slides):

• Had six interim meetings since 111
• Arch and API have Art and Sec reviews
• Impl getting ready for WGLC
• (p7) Specific documents update. taps-impl not quite there yet; looking for committment from non-authors to review during WGLC (for general and editorial quality) -- volunteers?

Zaheduzzaman Sarker: Resolving of author list issue went well. On submit jointly together, we can do that - Do we see any point of those who completed WGLC to complete IETF Last Call separately and then IESG evaluation together?

AF: We elected to hold the first document to get wording consistent (some of which is search/replace); once we're through WGLC with first 2, we can probably release the first 2 to IETF review. You can spread out the workload as it makes sense to you.

ZS: Makes sense to complete WGLC for these first. Have another pass at issues during IETF last call, will also help impl language. Just a thought, no strong opinion on that.

TE: Who read the impl document in the past three versions? Show of hands: 8 (continuing: 9) read it, 19 did not

TE asking for reviews again.

AF: You do not need to be an expert, we're looking for readability, consistency, comprehension, stuff that people who are really familiar with the content are going to miss.

[note taker comment, not in chat or voice: Christian Amsüss will review, still checking whether it'll make sense to volunteer for ART review if applicable, but can review either way]

Brian Trammell relayed from chat(Thorben Krüger): When is this expected to be completed?

AF: Ideally 4 weeks after IETF, also roughly time for interim. If somebody needs more time, I'd rather have a volunteer who needs more time than having to have to find another volunteer.

TK is thinking about reviewing it.

AF: Most of the interim meetings are quite detailed and don't lend themselves well for cross participation. Plan is to do one meeting at every other IETF. Possibly add milestone to produce one or more mapping documents. Also do mapping for protocols where it isn't obvious what advantage using TAPS has for them.

Martin Duke via chat: HTTP is one where mapping is pretty unclear.

QUIC mapping (Tommy Pauly)

(p1) very recent document; older documents preceded the mapping concepts (and QUIC was much in flux back then)

(p2) So far only definitions for what happens when a protocol included in impelmentation document (TCP, UDP, SCTP) is used.
Mainly "how do you wire it up" and "what are the contract guarantees"; establishment, teardown and data transfer. Some knobs in TABS are not specific; not every API applies.

(p3) This is a first document that follows the Appendix A template in the implementation draft.
We learn how it is used and what we are missing.

(p4) New draft tries to copy style from implementation document.
Pointing out: There doesn't need to be only one mapping per protocol. This is about QUIC streams, it doesn't describe datagram use, and you might have a different mapping for unreliable data. Could be broader zoo of mappings for different use cases -- and this is OK.

(p5) First part is to map the objects, what is the connectedness, what is the basic data unit
Byte streams -- doing it differently would just be different mapping.
QUIC connection maps to TAPS connection group, is a bundle of stream

(p6) New streams not blocked by other streams.

Q&A

AF: Was looking for use cases in the document that are relevant to this particular mapping -- would be good addition. (High-level summary, what it's good for and what not; finding way in the zoo).

TP: Yes. Option is to also add datagram mapping here, so we have two different mappings, and then already tell which to use when.

BT: (on p6) Seems missing: interaction with 0RTT; anything we need to say?

TP: This list is not exhaustive, it is mentioned. There is InitiateWithSend saying "Same as initiate except with 0-RTT"

Lucas Pardue: I read the doc. Lack of datagram struck me; if you do mapping, consider it. Those are things applications can use. Concrete to Aaron's suggestion: QUIC does not give use cases and just describes services that are provided. Might be documenting that elsewhere, then we can point to that. But I don't feel like TAPS needs to say anything in particular.

LP: One more point: Didn't see "stop sending" frame, for how to cancel one end of the stream.

TP: On datagram: Yes, to be complete it needs to be included. Agree on not too much about applications, but some high-level text a la "if you replace UDP, use datagrams".

TP: On stop sending, it is not included in base API of TAPS b/c no other transport protocol offers it. Don't have an API in Network.framework. TAPS allows adding protocol-specific functions. But this is not something you can expect every bytestream protocol to support

LP: Just seems to be a pretty critical thing for QUIC.

TP: You can always reset the stream. Underlying level can do stop sending as part of that.

LP: Taking offline. But thanks for the work.

Jonathan Lennox: Is this API sufficient for full-fledged H3 client/server? So is this a complete API for QUIC?

TP: We have built H3 on top of this. One thing used there that's not part of mapping is protocol specific access to metadata like Stream ID. Maybe good to add to the document. Beyond that, using this mapping works fine for H3.

MD: Thanks, been waiting for it, support adoption. On abort call: Should be reset-stream and/or stop-sending depending on directionality of the stream. On listen, it says "open socket" but it's also used for new streams -- is that accurate?

TP: Yes it is. We can clarify that.

BT: on QUIC datagram: kinda looks like SOCK_SEQPACKET which does exist in another protocol, maybe we can take something from SCTP. Maybe we can do this when it is a WG item. Since we're not talking about adoption yet, I support adoption.

TP: Last slide says "Should we adopt this?" so this is useful.

Colin Perkins: Can be replacement for bunch of TCP connections, also UDP, with right security. Are we flexible enough in TAPS to ask for connection that can do both reliable and unreliable in same connection?

TP: This is where mapping of connection object matters. Answer is yes, TAPS Connection group which maps to QUIC association can include both bidirectional streams and datagrams, each would be a different TAPS connection object.

Michael Welzl: Should the additions be included in interface document? Stop sending is probably safe to ignore for transport that don't support it. Stream ID was in SCTP, we thought there was no need to expose it, but should also be easy (could be metadata). Should probably include that in API, but don't want to make more complicated.

TP: In mapping we should call out "you should have a way", and review interface document to make sure it's clear how "protocol specific information" is transported. Details on what type it is may matter, but it'd be "Get me the QUIC stream ID for this object".

ZS (no transport AD hat): have a more general document for mappings first, like the survey on transport features at the beginning, some topics Lucas mentioned would come up here. Would be good to have this document for QUIC, not just direct mapping.

ZS (AD hat on): I don't find this in datatracker as related document.

TP: Chairs should be able to fix that.

AF: Done.

TE: Support for adoping?: 26 in favor, no opposed
TE: Should we start others? Take offline (short time)
BT: Not yet. Let's do this one first.

PANAPI (TK)

(p1) developing TAPS like system, previous discussion on mailing list

(p2) First showing system, then some feedback

(p4) Using SCION

(p5) What benefit does path awareness have at the end host? User doesnt really care, average application developer also just wants to use a high level API like REST. Network people only ones who care. New features have to be hidden behind higer level APIs, like TAPS.

(p6) TAPS API is front end, system is not only for SCION. Backend is highly scriptable.

(p7) Written in GO, backend scriptable in Lua, try to follow TAPS as much as possible

(p8) Made some deviations from TAPS docs. TAPS is very internet specific. Does not use Event system. Event system unintuitive for GO developers. Use idiomatic GO. All calls are now blocking, use routines for async, errors return early. Properties are strongly typed objects (turned out to be a nightmare), catch mistakes at compile time, avoid at run time. Feedback on design decisions welcome.

p(10): So far backend is SCION specific, can perform active latency measurements over certain paths

p(11): Confident not undermining TAPS semantics, active measurements has no equivalent in TAPS, should it be added?

p(13): Problems with strongly typed properties. Documentes do not differentiate between converged and unconverged properties. Need to have clear distinction the two stages for implementation. Easy in dynamically typed langauges, but really hard in statically typed languages. Language is biased towards event-based systems. Wasted a lot of time to try shoehorning event based system into Go.

Q&A:

MW: We had the discussion about properties changing types before, we didn't have a selection property that would need to stay mutable.

TK: Would still be nice to have distinction between modifiable and not.

Jake Holland: (p9) Please explain the address

TK: Explaining SCION address scheme

BT: To "Does this make sense?" Yes it does, I like how you did this. We have seen another Go implementation. Hope to have an PR for event driven bias by the end of the week.

TK: Didn't want to open an issue because draft is pretty mature.

BT: It's ok to file issues

AF closing: Think about other mapping documents, send suggestions to the list.

[AF]: Aaron Falk

[ZS]: Zaheduzzaman Sarker

[TE]: Theresa (Reese) Enghardt

[BT]: Brian Trammell

[TK]: Thorben Krüger

[CA]: Christian Amsüss

[TP]: Tommy Pauly

[LP]: Lucas Pardue

[JL]: Jonathan Lennox

[MD]: Martin Duke

[CP]: Colin Perkins

[MW]: Michael Welzl

[JH]: Jake Holland