Subject: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 May 2017 15:16:15 +0100

We have just revised the UDP usage draft for TAPs in preparation for WG 
review. This improves readability and fixed all known issues:
https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-usage-udp-01.txt

In doing so, we have carefully reviewed the TAPS transport usage draft 
and have some comments that may be useful to consider for updating that 
draft. Some of these relate to the way UDP is specified, and some are 
more general,

best wishes,

Tom & Gorry

---

 > 2.  Introduction
 >
 >   This document presents defined interactions between applications and
 >   the transport protocols TCP, MPTCP, SCTP, UDP and UDP-Lite as well as
 >   the LEDBAT congestion control mechanism in the form of primitives and
 >   Transport Features.  Primitives can be invoked by an application or a
 >   transport protocol; the latter type is called an "event".  The list
 >   of primitives and Transport Features in this document is strictly
 >   based on the parts of protocol specifications that describe what the
 >   protocol provides to an application using it and how the application
 >   interacts with it.  Together with [RFC8095], it provides the basis
 >   for the minimal set of transport services that end systems should
 >
 >
 >
 > Welzl, et al.            Expires October 7, 2017                [Page 3]
 >
 > Internet-Draft             Transport Services                 April 2017
 >
 >
 >   support; this minimal set is derived in
 >   [I-D.draft-gjessing-taps-minset].

What is the relationship to usage-udp?

ADD:
	UDP and UDP-Lite protocols are analysed in Features of the User
	Datagram (UDP) and Lightweight UDP (UDP-Lite) Transport
         protocols [FJ16].

 >   Parts of a protocol that are explicitly stated as optional to
 >   implement are not covered.  Interactions between the application and
 >   a transport protocol that are not directly related to the operation
 >   of the protocol are also not covered.  For example, [RFC6458]
 >   explains how an application can use socket options to indicate its
 >   interest in receiving certain notifications.  However, for the
 >   purpose of identifying primitives and Transport Services, the ability
 >   to enable or disable the reception of notifications is irrelevant.
 >   Similarly, one-to-many style sockets described in [RFC6458] just
 >   affect the application programming style, not how the underlying
 >   protocol operates, and they are therefore not discussed here.  The
 >   same is true for the ability to obtain the unchanged value of a
 >   parameter that an application has previously set (this is the case
 >  for the "get" in many get/set operations in [RFC6458]).
 >
 >   The document presents a three-pass process to arrive at a list of
 >   Transport Features.  In the first pass, the relevant RFC text is
 >   discussed per protocol.  In the second pass, this discussion is used
 >   to derive a list of primitives that are uniformly categorized across
 >   protocols.  Here, an attempt is made to present or -- where text
 >   describing primitives does not yet exist -- construct primitives in a
 >   slightly generalized form to highlight similarities.  This is, for
 >   example, achieved by renaming primitives of protocols or by avoiding
 >   a strict 1:1-mapping between the primitives in the protocol
 >   specification and primitives in the list.  Finally, the third pass
 >   presents Transport Features based on pass 2, identifying which
 >   protocols implement them.
 >
 >   In the list resulting from the second pass, some Transport Features
 >   are missing because they are implicit in some protocols, and they
 >   only become explicit when we consider the superset of all features
 >   offered by all protocols.  For example, TCP always carries out
 >   congestion control; we have to consider it together with a protocol
 >   like UDP (which does not have congestion control) before we can
 >   consider congestion control as a Transport Feature.  The complete
 >   list of features across all protocols is therefore only available
 >   after pass 3.

This needs an intro to the document separate to the overview of the
process

The document needs to start with an introduction to the document
separate of the overview of the process, so that anyone reading thsi
knows whether t read more. Perhaps this should be the first section?

 >   This document discusses unicast transport protocols and a unicast
 >   congestion control mechanism.  Transport protocols provide
 >   communication between processes that operate on network endpoints,
 >   which means that they allow for multiplexing of communication between
 >   the same IP addresses, and normally this multiplexing is achieved
 >   using port numbers.  Port multiplexing is therefore assumed to be
 >   always provided and not discussed in this document.
 >

The above paragraph could be moved earlier perhaps as part of the 
introduction.

- This is more diffserv-based, rather than historical:
OLD:
 >      Staying with the intention behind the application's
 >      ability to specify the "Type of Service", this should probably be
 >      interpreted to mean the value in the DSField, which is the
 >      Differentiated Services Codepoint (DSCP).
NEW:
	 The Differentiated Services (diffuser) model [RFC2475][RFC3260]
	 replaces this field in the IP Header assigning the six most
	 significant bits to carry the Differentiated Services
          Code Point (DSCP) field [RFC2474]

 > 3.4.  Primitives Provided by UDP and UDP-Lite
 >
 >   The primitives provided by UDP and UDP-Lite are described in [FJ16].

- We should include some text on the UDP primitives here, try:

ADD:
         <t><xref target="RFC0768">The User Datagram Protocol (UDP)</xref>
         States: "This User Datagram Protocol (UDP) is defined to make
         available a datagram mode of packet-switched computer 
communication in
         the environment of an interconnected set of computer networks." It
         &ldquo;provides a procedure for application programs to send 
messages
         to other programs with a minimum of protocol mechanism
         (..)&rdquo;.</t>

         <t>The User Interface section of RFC768 states that the user 
interface
         to an application should be able to create receive, source and
         destination ports and addresses, and provide operations to receive
         data based on ports with an indication of source port and address.
         Operations should be provided that allows datagrams be sent 
specifying
         the source and destination ports and addresses to be sent.</t>

		<t>UDP offers only a basic transport interface. UDP datagrams
		may be directly sent and received, without exchanging messages
		between the endpoints to setup a connection (i.e., no handshake
		is performed by the transport protocol prior to communication).
		Neither UDP nor UDP-Lite provide congestion control,
		retransmission, nor do they have support to optimise
		fragmentation and other transport functions. This means that
		applications using UDP need to provide additional functions on
		top of the UDP transport API <xref target="RFC8085"></xref>.
		Guidance on the use of the services provided by UDP is provided
		in the UDP Guidelines <xref target="RFC8085"></xref>. </t>

		<t>
		The set of pass 1 primitives for UDP and UDP-Lite is documented
		in <xref target="draft-usage-udp]"></xref>
		</t>

- It is much clearer to rewrite this:
OLD:
 >   o  CHECKSUM.UDP:
 >      Pass 1 primitive / event: 'DISABLE_CHECKSUM'.
 >      Parameters: 0 when no checksum is used at sender, 1 for checksum
 >      at sender (default)
NEW:
     o  SET_CHECKSUM_ENABLED.UDP:
        Pass 1 primitive / event: 'CHECKSUM_ENABLED'.
        Parameters: 0 when zero checksum is used at sender, 1 for
        checksum at sender (default)

- We could not parse the old text. It is much clearer to rewrite this:
OLD:
 >   o  CHECKSUM_REQUIRED.UDP:
 >      Pass 1 primitive / event: 'REQUIRE_CHECKSUM'.
 >      Parameter: 0 when checksum is required at receiver, 1 to allow
 >      zero checksum at receiver (default)
New:
	SET_CHECKSUM_REQUIRED.UDP
		Pass 1 primitive / event: 'SET_CHECKSUM_COVERAGE'
		Parameter: 0 to allow zero checksum, 1 when a non-zero
		checksum is required (default) at receiver,

- This primitive is not permitted for IPv6 RFC1981bis. Add "IPv4" 
header, suggest this:
OLD:
 >   o  SET_DF.UDP(-Lite):
 >      Pass 1 primitive event: 'SET_DF'.
 >      Parameter: 0 when DF is not set (default), 1 when DF is set
NEW:
	o  SET_DF.UDP(-Lite):
	   Pass 1 primitive event: 'SET_DF'.
	   Parameter: 0 when DF is not set (default) in the IPv4
	   header, 1 when DF is set.

- Suggest add defaults to sending 00:
OLD:
 >   o  SET_ECN.UDP(-Lite):
 >      Pass 1 primitive / event: 'SET_ECN'
 >      Parameters: ECN value
 >      Comments: This allows a UDP(-Lite) application to set the ECN
 >      codepoint field for outgoing UDP(-Lite) datagrams.
NEW:
	o  SET_ECN.UDP(-Lite):
	   Pass 1 primitive / event: 'SET_ECN'
	   Parameters: ECN value
	   Comments: This allows a UDP(-Lite) application to set the ECN
	   codepoint field for outgoing UDP(-Lite) datagrams. Defaults
	   to sending '00'.

- Connections for UDP are an unusual concept, can we try:
OLD:
 >   o  ABORT.UDP(-Lite):
 >      Pass 1 primitive event: 'CLOSE'
 >      Comments: this terminates a connection without delivering
 >      remaining data.  No further UDP(-Lite) datagrams are sent/received
 >      on this connection.
NEW:
     o  ABORT.UDP(-Lite):
        Pass 1 primitive event: 'CLOSE'
        Comments: this terminates a connection without delivering
        remaining data.  No further UDP(-Lite) datagrams are
        sent/received for this transport service instance.

- For UDP, this is just an error report, remove.
DELETE:
 >   o  SEND_FAILURE.UDP(-Lite):
 >      Pass 1 primitive / event: 'SEND'
 >      Comments: This may be used to probe for the effective PMTU when
 >      using in combination with the 'MAINTENANCE.SET_DF' primitive.

- UDP can't do this,  remove UDP(-Lite)
OLD:
 >   o  Listen, N specified local interfaces
 >      Protocols: SCTP, UDP(-Lite)
NEW:
	    o  Listen, N specified local interfaces
	       Protocols: SCTP
- UDP can potentially also do this (for some options on all packets)
OLD:
 >   o  Specify which IP Options must always be used
 >      Protocols: TCP
NEW:
    o  Specify which IP Options must always be used
       Protocols: TCP, UDP(-Lite)

- Why do this??? - Isn't it better to set flow labels per interface or 
for the whole stack, how can any specific transport or application pick 
unique labels?
TEXT:
 >   o  Specify IPv6 flow label field
 >      Protocols: SCTP

(i.e., Is this automatable by the host and a host wide
configuration?)

-------------------
Get Interface MTU is missing from pass 2 and 3:

ADD to pass 2:

	GET_INTERFACE_MTU.UDP:
		Pass 1 primitive: GET_INTERFACE_MTU
		Returns: Maximum datagram size (bytes)

ADD to Pass 3,
MAINTENANCE:

	Get interface MTU
	Protocols: UDP

- Move the per-datagram IP options to be placed next to the other IP 
options primitives:

MOVE:
 >   o  Specify IP Options
 >      Protocols: UDP(-Lite)
MOVE:
 >   o  Obtain IP Options
 >      Protocols: UDP(-Lite)

- Please remove UDP(-Lite), it does not make sense to do thisfrom 5.2.3. 
  Errors:

OLD:
 >   o  Notification of an unsent (part of a) message
 >      Protocols: SCTP, UDP(-Lite)

NEW:
     o  Notification of an unsent (part of a) message
        Protocols: SCTP
------------------

 > 8.  Security Considerations
 >
 >   Authentication, confidentiality protection, and integrity protection
 >   are identified as Transport Features by [RFC8095].  As currently
 >   deployed in the Internet, these features are generally provided by a
 >   protocol or layer on top of the transport protocol; no current full-
 >   featured standards-track transport protocol provides these features
 >   on its own.  Therefore, these features are not considered in this
 >   document, with the exception of native authentication capabilities of
 >   TCP and SCTP for which the security considerations in [RFC5925] and
 >   [RFC4895] apply.
 >

- We think it is also important discussion from usage-udp:
ADD:
	  <t>Security considerations for the use of UDP and UDP-Lite are
	  provided in the referenced RFCs. Security guidance for
           application usage is provided in the UDP-Guidelines <xref
	  target="RFC8085"></xref>.</t>
-- 
Prof Gorry Fairhurst, School of Engineering, University of Aberdeen.
The University of Aberdeen is a charity registered in Scotland,
No SC013683.

---

From: Michael Welzl <[email-masked]>
Date: Fri, 12 May 2017 14:31:23 +0200

Hi,

Thanks a lot for all your comments (plus the nits we authors of the other -usage draft received offline).

I’ll try to address them all - but there are a two technical questions in this email that made me stop, so I’ll cut all the editorial stuff away and discuss them here - in line below:

> - Why do this??? - Isn't it better to set flow labels per interface or for the whole stack, how can any specific transport or application pick unique labels?
> TEXT:

Somehow the question seems irrelevant in the context of this draft, which is a list of transport features of protocols. These features are defined in the RFCs spec’ing the protocols - for SCTP, this is defined, and that’s why it’s here.

We can discuss this for the proposed services that a system should offer, which we try to write up in the minset draft:
I do think that an application should be allowed to assign a label to a TAPS flow (as we call them), which could then map to this function. I mean, isn’t a flow label supposed to identify a transport flow? Then a system-wide configuration wouldn't seem right to me.

But this doesn’t exist!  It’s strictly an IP function and I couldn’t find it described for UDP anywhere. I think we agreed on how a TAPS system should handle this, and this is reflected in
https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-6.4.1
… which may require a system to implement new local functionality, maybe based on this MTU function - but to my understanding it’s just not something that UDP offers.

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 12 May 2017 14:24:23 +0100

See below.

> I do think that an application should be allowed to assign a label to a TAPS flow (as we call them), which could then map to this function. I mean, isn’t a flow label supposed to identify a transpo…
I think we may disagree. Flow ids identify flows to the network layer, 
they have no role at the transport layer, and need to be unique (as best 
they can) for a source address.

I much prefer the idea that the Flow id is generated by the IP system, 
by using a hash - possibly utilising transport data as a part of this 
hash, and including the protocol number. That seems to be what ECMP is 
expecting and I suspect ECMP is an improtant use-case.

The alternative (if I understand) could be: I could imagine each 
application could (in theory) be provided with an API to find out what 
flow-ids are currently being used for each interface it cares about and 
to then reserve one of the unused IDs for the specific interface(s) that 
it wishes to use. Then we need to ensure all upper layer entities 
coordinate on this. To me, this seems over-kill, and the approach taken 
with ephemeral port assignment is much simpler - the application simply 
doesn't get involved with choosing the number.

Now if what you are saying is that you want the App to somehow signal 
that it can use an existing flow ID that is in use, and combine data 
with that flow to get the same network treeatment, I can understand the 
case. However, that's not exactly the same thing.
> But this doesn’t exist!
I think I don't understand your comment ... and interpretting 
low-numbered RFCs is never easy -  I'll use RFC1122 as my basis:

RFC 1122 says:
        " A host MUST implement a mechanism to allow the transport layer
          to learn MMS_S, the maximum transport-layer message size that
          may be sent for a given {source, destination, TOS} triplet..."
        " and EMTU_S must be less than or equal to the MTU of the network
          interface corresponding to the source address of the datagram."

TCP handles this for the app.
>   It’s strictly an IP function and I couldn’t find it described for UDP anywhere. I think we agreed on how a TAPS system should handle this, and this is reflected in
It's something that a UDP App really needs to pay attention to as per 
RFC8085 - we may differ on whether you call that "offers" or needs to 
function. Either way, an app that plans to use any form of PMTUD needs 
to use this number.

As put in RFC1122:
        " A host that does not implement local fragmentation MUST ensure
          that the transport layer (for TCP) or the application layer
          (for UDP) obtains MMS_S from the IP layer and does not send a
          datagram exceeding MMS_S in size."
> Michael
Gorry

---

From: Michael Welzl <[email-masked]>
Date: Fri, 12 May 2017 17:27:09 +0200

> On May 12, 2017, at 3:24 PM, Gorry Fairhurst <[email-masked]> wrote:
> 
> See below.
> 
> I think we may disagree. Flow ids identify flows to the network layer, they have no role at the transport layer, and need to be unique (as best they can) for a source address.

We disagree indeed - in particular about the “unique (as best they can)..” bit. Where is this written??

> I much prefer the idea that the Flow id is generated by the IP system, by using a hash - possibly utilising transport data as a part of this hash, and including the protocol number.

RFC 6437 introduces the flow label as a replacement for the 5-tuple - “possibly utilising transport data as a part of this hash” seems to me to be a very weak requirement here!

Anyway classifiers in the network wouldn’t work on the flow label alone, but, from RFC 6437, section 2 which is called “specification”:
  "Packet classifiers can
   use the triplet of Flow Label, Source Address, and Destination
   Address fields to identify the flow to which a particular packet
   belongs."

Then what is the flow label good for, if it’s unique per source address? It doesn’t add any information to this 3-tuple in this case!

> That seems to be what ECMP is expecting and I suspect ECMP is an improtant use-case.
> 
> The alternative (if I understand) could be: I could imagine each application could (in theory) be provided with an API to find out what flow-ids are currently being used for each interface it cares about and to then reserve one of the unused IDs for the specific interface(s) that it wishes to use. Then we need to ensure all upper layer entities coordinate on this. To me, this seems over-kill, and the approach taken with ephemeral port assignment is much simpler - the application simply doesn't get involved with choosing the number.
> 
> Now if what you are saying is that you want the App to somehow signal that it can use an existing flow ID that is in use, and combine data with that flow to get the same network treeatment, I can understand the case. However, that's not exactly the same thing.

I understand that it would be nice to avoid upper-layer coordination here. However, I see at least two use cases for the application being more in control:
1) avoiding fate sharing (encouraging ECMP), e.g. for increased resilience
2) the opposite: grouping flows, to be able to apply priorities on them, using a mechanism such as the Congestion Manager or https://tools.ietf.org/html/draft-welzl-tcp-ccc

So this is not about giving the application control of the specific flow label number, but allowing it to say “use the same number for these flows” or not.
I think this could nicely be done by letting it number flows, and grouping them via equal numbering - without guaranteeing that these numbers map onto the exact same numbers as a flow label.

> I think I don't understand your comment ... and interpretting low-numbered RFCs is never easy -  I'll use RFC1122 as my basis:
> 
> RFC 1122 says:

… and UDP is another such transport layer. If you try to send a message that’s too large, it throws an error, based on the information it gets via the paragraph you quote above.
But that’s UDP, not the application on top.

> It's something that a UDP App really needs to pay attention to as per RFC8085 - we may differ on whether you call that "offers" or needs to function. Either way, an app that plans to use any form of PMTUD needs to use this number.

I agree; and we have put related functions into the minset draft. But here we’re describing what it is that UDP itself (not a full-fleged TAPS system) currently offers…

>         datagram exceeding MMS_S in size.”

Okaaay, you found an instance of  “ _ or the application layer (for UDP) _ “.    I agree this should be included!  But, this is not the interface MTU. From RFC 1122:

***
         If no local fragmentation
         is performed, the value of MMS_S will be:

            MMS_S = EMTU_S - <IP header size>

         and EMTU_S must be less than or equal to the MTU of the network
         interface corresponding to the source address of the datagram. paragraph further above defines MMS_S as the maximum transport-layer m
***

So first of all, there’s the “if” - this would only be the value without local fragmentation. Can we assume that there won’t be local fragmentation?
Then, EMTU_S <= interface MTU, and MMS_S is even smaller: very reasonably, the IP header size is subtracted.

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 12 May 2017 17:23:28 +0100

More below.

On 12/05/2017, 16:27, Michael Welzl wrote:
>> On May 12, 2017, at 3:24 PM, Gorry Fairhurst<[email-masked]>  wrote:
>>
>> See below.
>>
I'm taking the position of using this as input to an ECMP or LAG hash 
algorithm.
> RFC 6437 introduces the flow label as a replacement for the 5-tuple - “possibly utilising transport data as a part of this hash” seems to me to be a very weak requirement here!
OK, which I think is the idea in RFC6438.
>     Address fields to identify the flow to which a particular packet
Yes.
> Then what is the flow label good for, if it’s unique per source address? It doesn’t add any information to this 3-tuple in this case!
Aha - I mean each "microflow" sent from a specific source address should 
be identified by a different and unique flow ID.
> 1) avoiding fate sharing (encouraging ECMP), e.g. for increased resilience
Yes. Part of the idea here is that microflows (say with the same IPsec 
ESP) can now be separately forwarded if that is what is desired by the 
sending endpoint.
> 2) the opposite: grouping flows, to be able to apply priorities on them, using a mechanism such as the Congestion Manager or https://tools.ietf.org/html/draft-welzl-tcp-ccc
That's the converse of the IPsec ESP example above, and also ok if the 
endpoint wishes this.
> So this is not about giving the application control of the specific flow label number, but allowing it to say “use the same number for these flows” or not.
That's fine with me. Providing it is *NOT* the flow-id, but an input to 
the function that determines the flow-id.
> I think this could nicely be done by letting it number flows, and grouping them via equal numbering - without guaranteeing that these numbers map onto the exact same numbers as a flow label.
OK.
> But that’s UDP, not the application on top.
I don't expect each UDP app to have to start by trying to send 64,000B 
and reducing to see what works. Apps need to be able to find this out.

(If you happened to implement host fragementation, any size of send upto 
your fragmentation limit would always return true when writing).

> I agree; and we have put related functions into the minset draft.
Yes we do agree. If you want to redefine that to bytes permitted in the 
UDP payload, I would also be really happy.
> But here we’re describing what it is that UDP itself (not a full-fleged TAPS system) currently offers…
>
And for that, the UDP app must assume either the network-wide default, 
or base this on maths from the MTU info at the network-layer (section 
3.2 of RFC8085). That's part of using UDP.
> Okaaay, you found an instance of  “ _ or the application layer (for UDP) _ “.    I agree this should be included!  But, this is not the interface MTU.
Maybe it's better to read PMTU, and I'd be fine with a socket (or 
whatever API) retrieving that in place of the Interface-MTU).
>  From RFC 1122:
>              MMS_S = EMTU_S -<IP header size>
>
We put the discussion text of host fragmentation in the "DF" discussion 
of our draft.

You could argue that we separate these because "DF" can be set on host 
fragments. (IPv6
> Then, EMTU_S<= interface MTU,
OK
> and MMS_S is even smaller: very reasonably, the IP header size is subtracted.
OK, I'd also be happy to say retrieves MMS_S. (I'm not sure though this 
in practice is implemented ?) -- but does this primitive exist in the 
real world? or do we need to explain both?
> Cheers,
> Michael
>
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Fri, 12 May 2017 22:37:43 +0200

In line:

> On May 12, 2017, at 6:23 PM, Gorry Fairhurst <[email-masked]> wrote:
> 
> More below.
> 
> I'm taking the position of using this as input to an ECMP or LAG hash algorithm.
>> 
> Aha - I mean each "microflow" sent from a specific source address should be identified by a different and unique flow ID.

Ah! Then we agree - for most normal cases (to support ECMP). The flow grouping case described below would be an exception.

> Yes. Part of the idea here is that microflows (say with the same IPsec ESP) can now be separately forwarded if that is what is desired by the sending endpoint.
> That's the converse of the IPsec ESP example above, and also ok if the endpoint wishes this.
> That's fine with me. Providing it is *NOT* the flow-id, but an input to the function that determines the flow-id.

Great!  So we agree!

> I don't expect each UDP app to have to start by trying to send 64,000B and reducing to see what works. Apps need to be able to find this out.
> 
> (If you happened to implement host fragementation, any size of send upto your fragmentation limit would always return true when writing).
> 
> Yes we do agree. If you want to redefine that to bytes permitted in the UDP payload, I would also be really happy.

Good - because that’s how it’s currently written in draft-gjessing-taps-minset-04

> And for that, the UDP app must assume either the network-wide default, or base this on maths from the MTU info at the network-layer (section 3.2 of RFC8085). That's part of using UDP.
>>> As put in RFC1122:
> Maybe it's better to read PMTU, and I'd be fine with a socket (or whatever API) retrieving that in place of the Interface-MTU).

… but it’s not the PMTU either - as we agree below:

> We put the discussion text of host fragmentation in the "DF" discussion of our draft.
> 
> You could argue that we separate these because "DF" can be set on host fragments. (IPv6
> OK, I'd also be happy to say retrieves MMS_S. (I'm not sure though this in practice is implemented ?) -- but does this primitive exist in the real world? or do we need to explain both?

Let’s stick with what the spec says - both of these drafts are just an overview of the spec and may differ quite a bit from implementations (I know mine does).

Cheers,
Michael

---

From: Erik Kline <[email-masked]>
Date: Mon, 15 May 2017 12:10:34 +0900

WRT the IPv6 flow label: there really aren't any requirements on semantics
that can be relied upon by applications on the wide open Internet.  It's
basically just something you can use within cooperating administrative
domains.

That said, it might be nice to be able to influence its value (even if only
for applications that are used with an administrative domain).

---

From: Michael Welzl <[email-masked]>
Date: Mon, 15 May 2017 06:58:10 +0200

Well, that may be true, but it's also  not how it should be, according to the rfcs... and apps assuming such misbehavior isn't going to make the situation any better.

today tcp relies on routers not introducing huge reordering, and net admins hopefully know that... so they cause harm by configuring differently.
it would be good if that was the same for the flow label.

Sent from my iPhone

> On 15 May 2017, at 05:10, Erik Kline <[email-masked]> wrote:
> 
> WRT the IPv6 flow label: there really aren't any requirements on semantics that can be relied upon by applications on the wide open Internet.  It's basically just something you can use within cooperating administrative domains.
> 
> That said, it might be nice to be able to influence its value (even if only for applications that are used with an administrative domain).

---

From: Joe Touch <[email-masked]>
Date: Mon, 15 May 2017 12:10:40 -0700

FWIW:

> … which may require a system to implement new local functionality, maybe based on this MTU function - but to my understanding it’s just not something that UDP offers.
IP is supposed to export MMS_S and MMS_R to the transport, which are
calculated from EMTU_S, EMTU_R, and the link MTU for the given source IP
address.. PMTUD exports PMTU to the transport. Both already take into
account the link MTU and other MTU information, where available.

In no cases does the transport actually ever need to see the link MTU.

Joe

---

From: Michael Welzl <[email-masked]>
Date: Tue, 16 May 2017 16:09:09 +0200

Hi,

Thanks a lot for your comments!  Answers in line below, marked with [Michael]. When I say "done" I mean my local copy - still need to fix some more nits, but I thought sharing this answer already now is useful.

Cheers,
Michael

ADD:

[Michael] I addressed this, but differently because I think repeating the title of FJ16 doesn't make this sentence very readable. Here's my new version of the paragraph's last sentence:

***
   Together with an overview
   of the services provided by IETF transport protocols and and
   congestion control mechanisms [RFC8095] and an analysis of UDP and
   UDP-Lite [FJ16], it provides the basis for the minimal set of
   transport services that end systems should support [I-D.draft-
   gjessing-taps-minset].
***

>   always provided and not discussed in this document.

The above paragraph could be moved earlier perhaps as part of the introduction.

[Michael] Done, but removed the first sentence of the paragraph, and inserted "unicast" in the right place of the existing text.
Anyway, the intro's first paragraph now doesn't talk about the processs anymore.

NEW:

[Michael] Done. This also made me remove the (now redundant) sentence preceding the quoted sentence, as well as one more statement in pass 2 / SET_DSCP.TCP that talks about this field replacement but maybe wasn't correctly phrased.

ADD:
       <t><xref target="RFC0768">The User Datagram Protocol (UDP)</xref>
       States: "This User Datagram Protocol (UDP) is defined to make
       available a datagram mode of packet-switched computer communication in
       the environment of an interconnected set of computer networks." It
       &ldquo;provides a procedure for application programs to send messages
       to other programs with a minimum of protocol mechanism
       (..)&rdquo;.</t>

       <t>The User Interface section of RFC768 states that the user interface
       to an application should be able to create receive, source and
       destination ports and addresses, and provide operations to receive
       data based on ports with an indication of source port and address.
       Operations should be provided that allows datagrams be sent specifying
       the source and destination ports and addresses to be sent.</t>

		<t>

[Michael] Done.

NEW:

[Michael] Done. I checked and saw that you accordingly replaced DISABLE_CHECKSUM
with CHECKSUM_ENABLED in your own draft. However, please note that there is
a leftover occurrence, in a sentence that also has an extra space before the ".".
Just do a search for "DISABLE_CHECKSUM" in draft-ietf-taps-transports-usage-udp-02.

New:
		
[Michael] I agree and rephrased this as you suggest, but I think your replacement
of REQUIRE_CHECKSUM with SET_CHECKSUM_COVERAGE here is an error, so I didn't do it.

- This primitive is not permitted for IPv6 RFC1981bis. Add "IPv4" header, suggest this:
NEW:
	o  SET_DF.UDP(-Lite):

[Michael] Done.

NEW:
	o  SET_ECN.UDP(-Lite):

[Michael] Done.

NEW:
   o  ABORT.UDP(-Lite):

[Michael] Done.

>      using in combination with the 'MAINTENANCE.SET_DF' primitive.

...and:

- Please remove UDP(-Lite), it does not make sense to do thisfrom 5.2.3.  Errors:

NEW:

[Michael] I'd like to keep this, as it's part of my effort to unify the description
of services across protocols. As you can see here, both UDP and SCTP can give
per-message errors, but TCP doesn't. You say it's "just an error report" - indeed,
your SEND primitive description contains: "Messages passed to the send primitive that
cannot be sent atomically in a datagram will not be sent by the network layer,
generating an error." My pass 2 description above only points back to the pass 1
primitive called "SEND". So it's just a different way of saying that SEND failed.

NEW:

[Michael] Done. Great catch, btw, this wasn't even a part of the pass 2 primitives.

NEW:

[Michael] Done.

[Michael] See the other thread: I think we settled this.

-------------------

ADD to pass 2:

	GET_INTERFACE_MTU.UDP:

ADD to Pass 3,
MAINTENANCE:

	Get interface MTU
	Protocols: UDP

[Michael] I see that you have now replaced this with GET_MMS_S and GET_MMS_R
and will update my text accordingly.

- Move the per-datagram IP options to be placed next to the other IP options primitives:

>      Protocols: UDP(-Lite)

[Michael] Sorry, but I don't get that - there's only one other, and that's:
"Specify which IP Options must always be used". But this is in the
ESTABLISHMENT and AVAILABILITY categories, not in MAINTENANCE - indeed
TCP can only do this at the beginning, not later. Anyway, this now also
includes UDP(-Lite) as you suggested above. So where would you want
me to move this?

------------------

[Michael] Done.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 16 May 2017 15:20:48 +0100

Thanks for dealing with this, comments in-line.

> Just do a search for "DISABLE_CHECKSUM" in draft-ietf-taps-transports-usage-udp-02.
Thanks.
> of REQUIRE_CHECKSUM with SET_CHECKSUM_COVERAGE here is an error, so I didn't do it.
Correct.

> primitive called "SEND". So it's just a different way of saying that SEND failed.
Your call if it makes sense to you.

> [Michael] See the other thread: I think we settled this.
Thanks - that would be correct.
> includes UDP(-Lite) as you suggested above. So where would you want
I agree, I see the grouping now, and that's why you had the two apart. 
No action needed.
Gorry