Subject: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-usage-04.txt

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Apr 2017 14:45:45 +0200

Dear all,

This is the minor change that I promised at the last meeting - mainly to include TCP Authentication (RFC 5925). Someone said that this document should cite the other TAPS documents for context - very true! we did that too.
Finally, Gorry's comment regarding UDP's "close" (a recent email discussion) was also incorporated.

With this update, we authors believe that the document could now be ready for WGLC.

Cheers,
Michael

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-ietf-taps-transports-usage-04.txt
> Date: 5 Apr 2017 14:42:24 CEST
> To: Michael Tüxen <[email-masked]>, Michael Welzl <[email-masked]>, Michael Tuexen <[email-masked]>, Naeem Khademi <[email-masked]>, <[email-masked]>
> Resent-From: <[email-masked]>
> 
> 
> A new version of I-D, draft-ietf-taps-transports-usage-04.txt
> has been successfully submitted by Michael Welzl and posted to the
> IETF repository.
> 
> Name:		draft-ietf-taps-transports-usage
> Revision:	04
> Title:		On the Usage of Transport Features Provided by IETF Transport Protocols
> Document date:	2017-04-05
> Group:		taps
> Pages:		49
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-taps-transports-usage-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-04
> 
> Abstract:
>   This document describes how TCP, MPTCP, SCTP, UDP and UDP-Lite expose
>   services to applications and how an application can configure and use
>   the transport features that make up these services.  It also
>   discusses the service provided by the LEDBAT congestion control
>   mechanism.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "Aaron Falk" <[email-masked]>
Date: Wed, 05 Apr 2017 10:27:03 -0400

Thanks, Michael!  Once the rev for …-transports-udp-usage-… has been 
posted we’ll start the WGLC for both.

—aaron

On 5 Apr 2017, at 8:45, Michael Welzl wrote:

> Dear all,
>
> This is the minor change that I promised at the last meeting - mainly 
> to include TCP Authentication (RFC 5925). Someone said that this 
> document should cite the other TAPS documents for context - very true! 
> we did that too.
>> To: Michael Tüxen <[email-masked]>, Michael Welzl 
>> <[email-masked]>, Michael Tuexen <[email-masked]>, Naeem 
>> Khademi <[email-masked]>, <[email-masked]>
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-04.txt
>> Status:         
>> https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/
>> Htmlized:       
>> https://tools.ietf.org/html/draft-ietf-taps-transports-usage-04
>> Htmlized:       
>> https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-04
>> Diff:           
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-04
>>
>> Abstract:
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 11:01:21 -0700

On 4/5/2017 5:45 AM, Michael Welzl wrote:
> This is the minor change that I promised at the last meeting - mainly to include TCP Authentication (RFC 5925).
There are bugs in the description. TCP-AO was careful to say "TCP SEND,
or a sequence of commands resulting in a SEND" (same for RECEIVE),
regarding setting or viewing received key IDs (current and next),
especially including ways to set/read these values even when a SEND or
RECEIVE isn't issued (e.g., to affect retransmissions or ACKs).

I didn't give a deep re-read and I don't recall from my earlier checks,
but is there a discussion of using other operations to interact with
connection parameters (socket options, ioctls), e.g., as part of the
required interface?

Joe

---

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Apr 2017 21:12:28 +0200

Hi,

Thanks a lot for checking this!

> On Apr 5, 2017, at 8:01 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Hm, I saw this but didn’t get it - what is “a sequence of commands resulting in a SEND” (or RECEIVE) ?
I just don’t get what that’s supposed to mean. E.g., what else than SEND will send?

> RECEIVE isn't issued (e.g., to affect retransmissions or ACKs).

I also saw this but didn’t see it as mandatory to provide (“It may be useful…”, the text says). Is this really very useful?

> connection parameters (socket options, ioctls), e.g., as part of the

Nothing that’s not in the RFCs… I did rephrase the authentication stuff for TCP as “CONNECTION.MAINTENANCE” primitives (set_auth, get_auth), stating that they’d be implemented using SEND and RECV. Not much else available…

If you say it’s important it can be added, I guess, but I find it hard to derive that from the text in RFC 5925. Well, empty send’s and receive’s are a way out, I suppose.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 12:31:23 -0700

> I just don’t get what that’s supposed to mean. E.g., what else than SEND will send?

E.g., setting a socket option to set values then using SEND, or RECEIVE
then socket options to read.

The point was that the setting of those values can be asynchronous to
the SEND/RECEIVE calls.
> I also saw this but didn’t see it as mandatory to provide (“It may be useful…”, the text says). Is this really very useful?
You might want/need to change keys on a BGP session even when you aren't
yet ready to issue a SEND. You might want to check to see of the keys
have changed due to retransmissions or ACKs even when you didn't issue a
RECEIVE.

> If you say it’s important it can be added, I guess, but I find it hard to derive that from the text in RFC 5925. Well, empty send’s and receive’s are a way out, I suppose.

It's not just RFC 5925. The issue is whether there are other mandatory
configurations or monitoring that is async to SEND/RECEIVE. If so, then
you can't simply assume they occur only during those calls.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Apr 2017 21:46:25 +0200

> On Apr 5, 2017, at 9:31 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Okay, got it; socket options don’t exist in RFC 793 language, or any of the RFCs updating it, I think…
maybe this RFC should have invented such a function call?  Anyway, I can do this for you  :-)   to some degree, that’s the role of my draft. I can say that RFC 5925 demands this functionality, and describe SET_AUTH and GET_AUTH primitives that would map to that.

> have changed due to retransmissions or ACKs even when you didn't issue a

Okay…

> you can't simply assume they occur only during those calls.

There isn’t much; Nagle is an example - RFC 1122 just says that the functionality to enable / disable must be there, without specifying via which primitive that would happen.
So, my draft says, in pass 2:

   o  DISABLE_NAGLE.TCP:
      Pass 1 primitive / event: not specified

Seems like I should do the same for set_auth and get_auth.

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 12:50:15 -0700

FWIW, the current setsockopt commands are an extension (IMO) of the
STATUS command of RFC 793, allowing it to not only read connection
information but also modify it.

IMO, we should think of it in those terms, not merely "setsockopt" or
"ioctl" or anything else.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 12:55:22 -0700

> Seems like I should do the same for set_auth and get_auth.
Set_auth and get_auth are either in the STATUS (as per my previous
message) or SEND/RECEIVE.

There may be other signals that need to be specified. E.g., RFC1122 has
a few items that need to be indicated, but isn't clear about them being
only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4).

Joe

---

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Apr 2017 22:10:59 +0200

> On Apr 5, 2017, at 9:55 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

What’s the problem with defining new primitives for these things? It’s just an abstract API anyway.
I actually removed STATUS in my draft because of the following reasoning (quoting my own draft):

***
The 'status' primitive was not included because [RFC0793] describes this primitive as
"implementation dependent" and states that it "could be excluded without adverse effect”.
  Moreover, while a data block containing specific information is described, it is also stated
   that not all of this information may always be available.
***

Because a TAPS system should be able to rely on things that are available pretty much everywhere,
this draft doesn’t include things that are optional for an underlying transport to implement.

> only inside SEND/RECEIVE commands (e.g., see sections 4.1.4 and 4.2.4).

Exactly my point - disabling Nagle is one of these things. So I gave them names and call them primitives under “CONNECTION.MAINTENANCE”.
Shouldn’t matter, as long as the functionality is there?

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 13:33:31 -0700

Hi, Michael,

On 4/5/2017 1:10 PM, Michael Welzl wrote:
>> ...
You can, but 5925 says "SEND or other" and "RECEIVE or other", i.e., it
does say that the management of these parameters can be via
SEND/RECEIVE, but doesn't have to be.

> "implementation dependent" and states that it "could be excluded without adverse effect”.

That was true back when 793 was created, but hasn't been true
effectively since 1122.

> this draft doesn’t include things that are optional for an underlying transport to implement.
Agreed - I'm saying that there MUST be a command by which some
parameters of a connection can be monitored and altered after the
connection is established but asynchronously from a SEND/RECEIVE call.

You might say that you could accomplish the result with a zero-byte SEND
or nonblocking RECEIVE, but that's ugly from an API viewpoint.

> Shouldn’t matter, as long as the functionality is there?

Oh, OK - then you would want to say that the keyID and nextkeyIDs fall
under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Apr 2017 23:23:53 +0200

> On Apr 5, 2017, at 10:33 PM, Joe Touch <[email-masked]> wrote:
> 
> Hi, Michael,
> 
> 

We seem to agree: see below -

> That was true back when 793 was created, but hasn't been true

Hmmm…. what about the whole block defined in RFC793? It tells you about rwnd, snd wnd, and strange stuff like security/compartment… where to draw the line?
I guess by knowing what is actually happening in OS’es out there, for each of these items. That’s the quest I wasn’t going to take - this draft is based on the RFCs.
I’d also say that these things don’t matter much for a (minimal) TAPS system - for many of these things, exposing them creates an unnecessary dependency on the protocol.

> or nonblocking RECEIVE, but that's ugly from an API viewpoint.

Agree to both -

> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section.

Exactly. Right now, the error is that the CONNECTION.MAINTENANCE primitive description says that this uses ‘send’ or ‘receive’. It shouldn’t.  I’ll note that for the next update (when I'll address more comments from WGLC), thanks!

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 5 Apr 2017 14:31:08 -0700

> Hmmm…. what about the whole block defined in RFC793? It tells you about rwnd, snd wnd, and strange stuff like security/compartment… where to draw the line?
Having a "window" into what TCP is doing is nice, but not necessary.

Having a way to disable Nagle (or enable it, for that matter) is necessary.

I'd draw the line at "required" to make TCP work correctly.

> I guess by knowing what is actually happening in OS’es out there, for each of these items. That’s the quest I wasn’t going to take - this draft is based on the RFCs.

IMO, it's hard to scrub those RFCs for this info. There was a time when
the IETF decided that APIs were out of scope and a lot of the info you
need was ignored in RFCs, or at best pushed to "honorable mention".

> I’d also say that these things don’t matter much for a (minimal) TAPS system - for many of these things, exposing them creates an unnecessary dependency on the protocol.

I don't know what the requirements are for a minimal TCP system, so
there's no way to answer that.

We ought to understand that for every protocol we design, but we don't.

> Exactly. Right now, the error is that the CONNECTION.MAINTENANCE primitive description says that this uses ‘send’ or ‘receive’. It shouldn’t.  I’ll note that for the next update (when I'll address…

AOK.
Joe

---

From: Michael Welzl <[email-masked]>
Date: Wed, 5 Apr 2017 23:43:18 +0200

> On Apr 5, 2017, at 11:31 PM, Joe Touch <[email-masked]> wrote:
> 
> 
> 

Yes -

> there's no way to answer that.

I don’t think the group ever agreed on any - so my statement was based on our (authors’) own rules, laid out in:
https://tools.ietf.org/html/draft-gjessing-taps-minset <https://tools.ietf.org/html/draft-gjessing-taps-minset>

>> Exactly. Right now, the error is that the CONNECTION.MAINTENANCE primitive description says that this uses ‘send’ or ‘receive’. It shouldn’t.  I’ll note that for the next update (when I'll address…

Thanks!

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Thu, 6 Apr 2017 08:54:44 +0200

BTW,

>>>> under BOTH SEND/RECEIVE and the CONNECTION.MAINTENANCE section.

When handing over the keyID and nextkeyIDs on SEND, this just means that these new values are valid from the time SEND was called, right? It's not tied to the specific data block that's being handed over?
(I'm asking because that's a difference to SCTP, where it's possible to decide to authenticate a particular data chunk that's handed over. For TCP, this would be pretty unusual, I think, but perhaps also implementable...)

Cheers,
Michael

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Apr 2017 12:32:23 -0700

Hi, Michael,

Sorry for the delay...

> When handing over the keyID and nextkeyIDs on SEND, this just means that these new values are valid from the time SEND was called, right? It's not tied to the specific data block that's being hande…
Correct. They're not tied to data the way the URG pointer is or SCTP
authentications are.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Thu, 13 Apr 2017 21:34:46 +0200

No worries about the delay, but thanks!
Michael

> On Apr 13, 2017, at 9:32 PM, Joe Touch <[email-masked]> wrote:
> 
> Hi, Michael,
> 
> Sorry for the delay...
> 
>