Subject: [Taps] working group last call for draft-ietf-taps-minset

From: "Aaron Falk" <[email-masked]>
Date: Thu, 10 May 2018 10:52:57 -0400

Dear TAPS working group,

As discussed in London, it's time to last call 
[draft-ietf-taps-minset-03](https://tools.ietf.org/html/draft-ietf-taps-minset-03).

	          A Minimal Set of Transport Services for TAPS Systems
	                       draft-ietf-taps-minset-03

	Abstract

	   This draft recommends a minimal set of IETF Transport Services
	   offered by end systems supporting TAPS, and gives guidance on
	   choosing among the available mechanisms and protocols.  It is based
	   on the set of transport features in RFC 8303.

Please read the draft and send comments to the list. This document is 
planned to be an Informational RFC.  Statements along the lines of 
'ready to publish' are also welcome.

WGLC will conclude in two weeks on May 24, 2018.

--aaron (for the chairs)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 11 May 2018 13:26:18 +0200 (CEST)

> 'ready to publish' are also welcome.

I've never read this document before, but read all the main body now. I 
did not read all of the appendices.

I did read A3.7 plus search for my pet peeve, which is trying to avoid IP 
level fragmentation in communication plus handling path MTU blackhole 
detection/mitigation.

It seems lots of what I was looking for is here. The main body (minus 
appendices) is easy to read and makes sense to me. I guess some details 
will be cleared up in a future document that actually specifies the APIs 
and how they would look. A3.7 at least gives possibility for applications 
to get PMTU information, that's great.

However, I couldn't find exactly how an application can be helped to 
determine the actual working PMTU by specifying some kind of probe packets 
that are devoid of actual "content", ie padded to max PMTU size? At least 
that would be understood by two TAPS systems for the protocols where this 
isn't already implementable in other ways (I imagine this can be done for 
SCTP and TCP without the application having to get much involved, but will 
be harder for UDP). So to implement some kind of "test if PMTU actually 
works" TAPS functionality?

I know I'm late in the game here and haven't followed TAPS closely, so 
something like this might already be in there, but it's decided to not go 
into the minimum requirements?

Anyhow, for a first-time reader, this document seems fine and nothing 
jumped out to me as being wrong in it (of the parts that I read).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Fri, 11 May 2018 17:06:26 +0200

Dear Mikael,

Thanks a lot for reading, and thanks for your feedback!  Answers in line:

> On May 11, 2018, at 1:26 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> Please read the draft and send comments to the list. This document is planned to be an Informational RFC.  Statements along the lines of 'ready to publish' are also welcome.
> 
> I've never read this document before, but read all the main body now. I did not read all of the appendices.
> 
> I did read A3.7 plus search for my pet peeve, which is trying to avoid IP level fragmentation in communication plus handling path MTU blackhole detection/mitigation.
> 
> It seems lots of what I was looking for is here. The main body (minus appendices) is easy to read and makes sense to me. I guess some details will be cleared up in a future document that actually specifies the APIs and how they would look. A3.7 at least gives possibility for applications to get PMTU information, that's great.
> 
> However, I couldn't find exactly how an application can be helped to determine the actual working PMTU by specifying some kind of probe packets that are devoid of actual "content", ie padded to max PMTU size?

This document is strictly based on RFCs 8303 and 8304. These RFCs list what TCP, MPTCP, SCTP, UDP, UDP-Lite and LEDBAT offer, according to their spec.
From this, on top of UDP, you’d have to implement this functionality by yourself inside your application, and using the UDP functionality that’s covered by draft-ietf-taps-minset you can do this on top of a transport system that only offers this “minimum set". However, this is only a minimal set of functionality that transport systems should expose; it is quite okay for a transport system to offer functionality that goes beyond it.

> At least that would be understood by two TAPS systems for the protocols where this isn't already implementable in other ways (I imagine this can be done for SCTP and TCP without the application having to get much involved, but will be harder for UDP).

Yes -

> So to implement some kind of "test if PMTU actually works" TAPS functionality?

This is a question about draft-ietf-taps-interface, and for the current version of this draft, the answer is no. Note that a TAPS transport system can be deployed one-sided, i.e. there’s no signaling side-channel or anything; so for some questions, such as “does the PMTU actually work”, only your application may know the answer.
This said, we could think about supporting draft-ietf-tsvwg-datagram-plpmtud in draft-ietf-taps-interface. Given that Gorry is an author of both drafts, I expect him to have an opinion on that  :)

> I know I'm late in the game here and haven't followed TAPS closely, so something like this might already be in there, but it's decided to not go into the minimum requirements?

This minimum set is only based on what the examined protocols can currently do. If people think a transport system should be able to do more, I’d suggest to directly propose this for draft-ietf-taps-interface.

> Anyhow, for a first-time reader, this document seems fine and nothing jumped out to me as being wrong in it (of the parts that I read).

Good to know, thanks!

Cheers,
Michael

---

From: Theresa Enghardt <[email-masked]>
Date: Thu, 17 May 2018 13:16:08 +0200

Dear all,

I have read the draft, including the appendix, and I think it is in good
shape and can be published.

However, I stumbled across the following clarification issue:

In Section 3, it says: "elements of the system that may prohibit
implementation over UDP are marked with "!UDP".  To implement a
transport system that can also work over UDP, these marked transport
features should be excluded."
Does this really mean that a transport system should not implement,
e.g., 0-RTT, or otherwise it will not work over UDP? Maybe I'm just
confused what "work over UDP" means at this point - I would assume it
means that UDP is one of the possible choices of transport protocols.
But perhaps it means that UDP is the protocol that the transport system
can always fall back to, which the draft should make more clear. In
fact, is this the same as "implementation over either TCP or UDP is
possible" as used in Appendix A.2 paragraph 2 and A.3?

Nits:

"a TAPS transport system" - sounds redundant to me? Maybe "transport
system implementing TAPS"? (Introduction 2. paragraph; Conclusion)

"if an application would use them" --> "if an application used them"
(Introduction, 3. paragraph)

"[…] a sender-side TAPS system implementing it can talk to […]" - What
does the "it" refer to here? The TAPS system? If so, can we drop the
"implementing it"?

"Here, the focus is on connections that the transport system offers, as
opposed to connections of transport protocols that the transport system
uses." - Maybe the distinction would be even more clear if we specified
"on connections that the transport system offers as an abstraction to
the application, as opposed to […]"?

Best,
Theresa

---

From: Michael Welzl <[email-masked]>
Date: Thu, 17 May 2018 14:27:42 +0200

Hi,

Thanks a lot for reading and for your feedback!

Answers in line:

> On May 17, 2018, at 1:16 PM, Theresa Enghardt <[email-masked]> wrote:
> 
> Dear all,
> 

Well, it means that 0-RTT excludes UDP.
( This reads odd here because you call it “0-RTT”; that’s why we have the longer phrasing in the draft: “reliable transmission before or during connection establishment (!UDP)”   => it’s about “reliable”. )

> possible" as used in Appendix A.2 paragraph 2 and A.3?

Yes!  “can always fall back to” is what is meant. We’ll try to phrase this better (specifically, the wording "fall back” was eliminated upon request by Tommy Pauly).

> Nits:

Thanks, we’ll address them!

Cheers,
Michael

---

From: "Aaron Falk" <[email-masked]>
Date: Thu, 17 May 2018 11:30:16 -0400

I've received a request to extend the WGLC for this doc.  We'll accept 
comments until June 4th.

--aaron

---

From: Aaron Falk <[email-masked]>
Date: Wed, 30 May 2018 10:51:03 -0400

Reminder: working group last call concludes next Monday.  Please review
this doc and send comments &/or 'ready to publish'.

--aaron

On Thu, May 17, 2018 at 11:30 AM Aaron Falk <[email-masked]> wrote:

> As discussed in London, it's time to last call draft-ietf-taps-minset-03
> <https://tools.ietf.org/html/draft-ietf-taps-minset-03>.
>
> planned to be an Informational RFC. Statements along the lines of 'ready to
> publish' are also welcome.
>

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 31 May 2018 13:31:57 +0200

I just found time to re-read the document and have no objections.

As a note: the Appendix is several the length of the main document. It somehow makes sense, but might face criticism without explanation why.

> On 30. May 2018, at 16:51, Aaron Falk <[email-masked]> wrote:
> 
> Reminder: working group last call concludes next Monday.  Please review this doc and send comments &/or 'ready to publish'.
> 
> --aaron
> 
> On Thu, May 17, 2018 at 11:30 AM Aaron Falk <[email-masked] <mailto:[email-masked]>> wrote:
> I've received a request to extend the WGLC for this doc.. We'll accept comments until June 4th.
> 
> --aaron
> 
> As discussed in London, it's time to last call draft-ietf-taps-minset-03 <https://tools.ietf.org/html/draft-ietf-taps-minset-03>.
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: [email-masked])----'