From nobody Thu May 11 07:14:19 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B6612EC9C; Thu, 11 May 2017 07:14:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149451205190.16592.17423357387270084046@ietfa.amsl.com> Date: Thu, 11 May 2017 07:14:11 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-udp-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:14:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols Authors : Godred Fairhurst Tom Jones Filename : draft-ietf-taps-transports-usage-udp-01.txt Pages : 20 Date : 2017-05-11 Abstract: This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. The resulting road map to documentation may be of help to users of the UDP and UDP-Lite protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-01 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 11 07:23:31 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D43129418 for ; Thu, 11 May 2017 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXutxAVSbvL9 for ; Thu, 11 May 2017 07:23:25 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2B42D12EC66 for ; Thu, 11 May 2017 07:16:18 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:8dc9:5d5b:e021:1b99]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BD4771B014CA; Thu, 11 May 2017 17:11:27 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. To: "taps@ietf.org" Cc: gorry Fairhurst , michael Welzl Message-ID: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> Date: Thu, 11 May 2017 15:16:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:23:30 -0000 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: The User Datagram Protocol (UDP) 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 “provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism (..)”. 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. 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 . Guidance on the use of the services provided by UDP is provided in the UDP Guidelines . The set of pass 1 primitives for UDP and UDP-Lite is documented in - 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: 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 . -- Prof Gorry Fairhurst, School of Engineering, University of Aberdeen. The University of Aberdeen is a charity registered in Scotland, No SC013683. From nobody Fri May 12 05:36:17 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493FD12EAFF for ; Fri, 12 May 2017 05:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9hVXswaXzwq for ; Fri, 12 May 2017 05:36:12 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B94012EB18 for ; Fri, 12 May 2017 05:31:26 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1d99jA-0007cB-Bb for taps@ietf.org; Fri, 12 May 2017 14:31:24 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx05.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1d99j9-0001ge-TX; Fri, 12 May 2017 14:31:24 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> Date: Fri, 12 May 2017 14:31:23 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 8 sum msgs/h 4 total rcpts 54615 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.095, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 441B37021F7F7E8E5BD63AC7184F5005E0A8B46E X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1383 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 12:36:15 -0000 Hi, Thanks a lot for all your comments (plus the nits we authors of the = other -usage draft received offline). I=E2=80=99ll try to address them all - but there are a two technical = questions in this email that made me stop, so I=E2=80=99ll 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: > > o Specify IPv6 flow label field > > Protocols: SCTP >=20 > (i.e., Is this automatable by the host and a host wide > configuration?) 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=E2=80=99ing the protocols - for SCTP, this is = defined, and that=E2=80=99s why it=E2=80=99s 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=E2=80=99t a flow label supposed to identify a transport flow? = Then a system-wide configuration wouldn't seem right to me. > ------------------- > Get Interface MTU is missing from pass 2 and 3: >=20 > ADD to pass 2: >=20 > GET_INTERFACE_MTU.UDP: > Pass 1 primitive: GET_INTERFACE_MTU > Returns: Maximum datagram size (bytes) But this doesn=E2=80=99t exist! It=E2=80=99s strictly an IP function = and I couldn=E2=80=99t 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 =E2=80=A6 which may require a system to implement new local = functionality, maybe based on this MTU function - but to my = understanding it=E2=80=99s just not something that UDP offers. Cheers, Michael From nobody Fri May 12 06:29:36 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5AF1294FF for ; Fri, 12 May 2017 06:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XzCInrCFRq5 for ; Fri, 12 May 2017 06:29:32 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4260D12EB5F for ; Fri, 12 May 2017 06:24:47 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 1BC791B014D0; Fri, 12 May 2017 16:19:32 +0100 (BST) Message-ID: <5915B787.4000307@erg.abdn.ac.uk> Date: Fri, 12 May 2017 14:24:23 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Welzl CC: "taps@ietf.org" References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> In-Reply-To: <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 13:29:35 -0000 See below. On 12/05/2017, 13:31, Michael Welzl wrote: > 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: >>> o Specify IPv6 flow label field >>> Protocols: SCTP >> (i.e., Is this automatable by the host and a host wide >> configuration?) > 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. 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. >> ------------------- >> 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) > 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 > 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. 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." > > Cheers, > Michael Gorry From nobody Fri May 12 08:32:15 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723CF12EC30 for ; Fri, 12 May 2017 08:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9cbaaPEdeb4 for ; Fri, 12 May 2017 08:32:11 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB0312EC3E for ; Fri, 12 May 2017 08:27:12 -0700 (PDT) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1d9CTG-000EWR-Aj; Fri, 12 May 2017 17:27:10 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1d9CTF-0002kI-IM; Fri, 12 May 2017 17:27:10 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <5915B787.4000307@erg.abdn.ac.uk> Date: Fri, 12 May 2017 17:27:09 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> <5915B787.4000307@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 3 sum msgs/h 2 total rcpts 54619 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.031, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FFD83CA62693FE9296843781836FCBC1CD3512B3 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1386 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:32:14 -0000 > On May 12, 2017, at 3:24 PM, Gorry Fairhurst = wrote: >=20 > See below. >=20 > On 12/05/2017, 13:31, Michael Welzl wrote: >> Hi, >>=20 >> Thanks a lot for all your comments (plus the nits we authors of the = other -usage draft received offline). >>=20 >> I=E2=80=99ll try to address them all - but there are a two technical = questions in this email that made me stop, so I=E2=80=99ll cut all the = editorial stuff away and discuss them here - in line below: >>=20 >>=20 >>> - 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?) >> 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=E2=80=99ing the protocols - for SCTP, this is = defined, and that=E2=80=99s why it=E2=80=99s here. >>=20 >> 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=E2=80=99t a flow label supposed to identify a transport flow? = Then a system-wide configuration wouldn't seem right to me. > 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 =E2=80=9Cunique (as best = they can)..=E2=80=9D 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 - = =E2=80=9Cpossibly utilising transport data as a part of this hash=E2=80=9D= seems to me to be a very weak requirement here! Anyway classifiers in the network wouldn=E2=80=99t work on the flow = label alone, but, from RFC 6437, section 2 which is called = =E2=80=9Cspecification=E2=80=9D: "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=E2=80=99s unique per source = address? It doesn=E2=80=99t 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. >=20 > 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. >=20 > 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 =E2=80=9Cuse the same number for = these flows=E2=80=9D 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. >>> ------------------- >>> Get Interface MTU is missing from pass 2 and 3: >>>=20 >>> ADD to pass 2: >>>=20 >>> GET_INTERFACE_MTU.UDP: >>> Pass 1 primitive: GET_INTERFACE_MTU >>> Returns: Maximum datagram size (bytes) >> But this doesn=E2=80=99t exist! > I think I don't understand your comment ... and interpretting = low-numbered RFCs is never easy - I'll use RFC1122 as my basis: >=20 > 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." >=20 > TCP handles this for the app. =E2=80=A6 and UDP is another such transport layer. If you try to send a = message that=E2=80=99s too large, it throws an error, based on the = information it gets via the paragraph you quote above. But that=E2=80=99s UDP, not the application on top. >> It=E2=80=99s strictly an IP function and I couldn=E2=80=99t 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 >> =E2=80=A6 which may require a system to implement new local = functionality, maybe based on this MTU function - but to my = understanding it=E2=80=99s just not something that UDP offers. > 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=E2=80=99re describing what it is that UDP itself (not a = full-fleged TAPS system) currently offers=E2=80=A6 > 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.=E2=80=9D Okaaay, you found an instance of =E2=80=9C _ or the application layer = (for UDP) _ =E2=80=9C. I agree this should be included! But, this is = not the interface MTU. =46rom RFC 1122: *** If no local fragmentation is performed, the value of MMS_S will be: MMS_S =3D EMTU_S - 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=E2=80=99s the =E2=80=9Cif=E2=80=9D - this would = only be the value without local fragmentation. Can we assume that there = won=E2=80=99t be local fragmentation? Then, EMTU_S <=3D interface MTU, and MMS_S is even smaller: very = reasonably, the IP header size is subtracted. Cheers, Michael From nobody Fri May 12 09:29:04 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B71B129572 for ; Fri, 12 May 2017 09:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5xOfyg5GPEX for ; Fri, 12 May 2017 09:29:00 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 06189128D2E for ; Fri, 12 May 2017 09:23:53 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 24A1F1B01653; Fri, 12 May 2017 19:18:37 +0100 (BST) Message-ID: <5915E180.2050106@erg.abdn.ac.uk> Date: Fri, 12 May 2017 17:23:28 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Welzl CC: "taps@ietf.org" References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> <5915B787.4000307@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 16:29:03 -0000 More below. On 12/05/2017, 16:27, Michael Welzl wrote: >> On May 12, 2017, at 3:24 PM, Gorry Fairhurst wrote: >> >> See below. >> >> On 12/05/2017, 13:31, Michael Welzl wrote: >>> 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: >>>>> o Specify IPv6 flow label field >>>>> Protocols: SCTP >>>> (i.e., Is this automatable by the host and a host wide >>>> configuration?) >>> 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. >> 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'm taking the position of using this as input to an ECMP or LAG hash algorithm. > >> 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! OK, which I think is the idea in RFC6438. > 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." 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. >> 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 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. > >>>> ------------------- >>>> 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) >>> 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. > … 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. 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). >>> 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. >> 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. 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. >> 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.” > 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: > > *** > If no local fragmentation > is performed, the value of MMS_S will be: > > MMS_S = EMTU_S - > > 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? 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 > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps Gorry From nobody Fri May 12 13:41:58 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80FDF1314B5 for ; Fri, 12 May 2017 13:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZC1-7jEkMJ6 for ; Fri, 12 May 2017 13:41:53 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B8E21270A7 for ; Fri, 12 May 2017 13:37:48 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1d9HJq-000Etg-U7 for taps@ietf.org; Fri, 12 May 2017 22:37:46 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx06.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1d9HJp-0008Nz-GC; Fri, 12 May 2017 22:37:46 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Michael Welzl In-Reply-To: <5915E180.2050106@erg.abdn.ac.uk> Date: Fri, 12 May 2017 22:37:43 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <41460979-E1A4-480B-BEFC-CF64B5B72442@ifi.uio.no> References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> <5915B787.4000307@erg.abdn.ac.uk> <5915E180.2050106@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.8]; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 54627 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.000, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 763A32DF71B37328F3B982016C6AE9296B6AF177 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1392 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 20:41:57 -0000 In line: > On May 12, 2017, at 6:23 PM, Gorry Fairhurst = wrote: >=20 > More below. >=20 > On 12/05/2017, 16:27, Michael Welzl wrote: >>> On May 12, 2017, at 3:24 PM, Gorry Fairhurst = wrote: >>>=20 >>> See below. >>>=20 >>> On 12/05/2017, 13:31, Michael Welzl wrote: >>>> Hi, >>>>=20 >>>> Thanks a lot for all your comments (plus the nits we authors of the = other -usage draft received offline). >>>>=20 >>>> I=E2=80=99ll try to address them all - but there are a two = technical questions in this email that made me stop, so I=E2=80=99ll cut = all the editorial stuff away and discuss them here - in line below: >>>>=20 >>>>=20 >>>>> - 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?) >>>> 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=E2=80=99ing the protocols - for SCTP, this is = defined, and that=E2=80=99s why it=E2=80=99s here. >>>>=20 >>>> 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=E2=80=99t a flow label supposed to identify a transport = flow? Then a system-wide configuration wouldn't seem right to me. >>> 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 =E2=80=9Cunique (as best = they can)..=E2=80=9D bit. Where is this written?? > I'm taking the position of using this as input to an ECMP or LAG hash = algorithm. >>=20 >>> 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 - = =E2=80=9Cpossibly utilising transport data as a part of this hash=E2=80=9D= seems to me to be a very weak requirement here! > OK, which I think is the idea in RFC6438. >> Anyway classifiers in the network wouldn=E2=80=99t work on the flow = label alone, but, from RFC 6437, section 2 which is called = =E2=80=9Cspecification=E2=80=9D: >> "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." > Yes. >> Then what is the flow label good for, if it=E2=80=99s unique per = source address? It doesn=E2=80=99t 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. Ah! Then we agree - for most normal cases (to support ECMP). The flow = grouping case described below would be an exception. >>> That seems to be what ECMP is expecting and I suspect ECMP is an = improtant use-case. >>>=20 >>> 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. >>>=20 >>> 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 > 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 =E2=80=9Cuse the same number = for these flows=E2=80=9D 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. Great! So we agree! >>>>> ------------------- >>>>> Get Interface MTU is missing from pass 2 and 3: >>>>>=20 >>>>> ADD to pass 2: >>>>>=20 >>>>> GET_INTERFACE_MTU.UDP: >>>>> Pass 1 primitive: GET_INTERFACE_MTU >>>>> Returns: Maximum datagram size (bytes) >>>> But this doesn=E2=80=99t exist! >>> I think I don't understand your comment ... and interpretting = low-numbered RFCs is never easy - I'll use RFC1122 as my basis: >>>=20 >>> 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." >>>=20 >>> TCP handles this for the app. >> =E2=80=A6 and UDP is another such transport layer. If you try to send = a message that=E2=80=99s too large, it throws an error, based on the = information it gets via the paragraph you quote above. >> But that=E2=80=99s 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. >=20 > (If you happened to implement host fragementation, any size of send = upto your fragmentation limit would always return true when writing). >=20 >>>> It=E2=80=99s strictly an IP function and I couldn=E2=80=99t 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 >>>> =E2=80=A6 which may require a system to implement new local = functionality, maybe based on this MTU function - but to my = understanding it=E2=80=99s just not something that UDP offers. >>> 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. > 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=E2=80=99s how it=E2=80=99s currently written in = draft-gjessing-taps-minset-04 >> But here we=E2=80=99re describing what it is that UDP itself (not a = full-fleged TAPS system) currently offers=E2=80=A6 >>=20 > 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: >>> " 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.=E2=80=9D >> Okaaay, you found an instance of =E2=80=9C _ or the application = layer (for UDP) _ =E2=80=9C. 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). =E2=80=A6 but it=E2=80=99s not the PMTU either - as we agree below: >> =46rom RFC 1122: >>=20 >> *** >> If no local fragmentation >> is performed, the value of MMS_S will be: >>=20 >> MMS_S =3D EMTU_S - >>=20 >> 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 >> *** >>=20 >> So first of all, there=E2=80=99s the =E2=80=9Cif=E2=80=9D - this = would only be the value without local fragmentation. Can we assume that = there won=E2=80=99t be local fragmentation? > We put the discussion text of host fragmentation in the "DF" = discussion of our draft. >=20 > You could argue that we separate these because "DF" can be set on host = fragments. (IPv6 >> Then, EMTU_S<=3D 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? Let=E2=80=99s 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 nobody Sun May 14 20:14:44 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2857C12947A for ; Sun, 14 May 2017 20:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZqzIPh3uy0V for ; Sun, 14 May 2017 20:14:41 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E37C0129493 for ; Sun, 14 May 2017 20:10:55 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l14so31661295ywk.1 for ; Sun, 14 May 2017 20:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=16gXWoZiMx2BIObT76wFnbzDN7fOEloNnqlv1SaPJrY=; b=CGhjPGhh2fnARtfLsSQe1L7rITjFYQ4bS8eHDiB1ZCyhOvdgaudFeZK6GP02I6lD3/ 9OYYtrPrqYCUoPAaUxGY8GZ951yRzsDGuhLryUIYuusLSltLhX7C0fHKBRXI5CaLXGLx Ba+xT6eX04+tPUdUiIrH1iAOmZa9ePOq5joGjmNQmpXwT+wIDQ2mtdBifO3lrSmAMnxY 76RiGxGoQ39I6G/BZMJj7U/Y3nlGDMoCobk+/cb+WH2DQRLAZVrAU4x4OApBFGOlljml yBHhAhHRFMiCbtxbv8V7uxJJCOoUCzyCZHmfmudpHFMG21H/wzSKVXJ7ysTelNmK/1FX 9hiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=16gXWoZiMx2BIObT76wFnbzDN7fOEloNnqlv1SaPJrY=; b=uE5KW/UREOPL3CUhORJMhDIzdjtUk/fwUz53Zufgou7RTrM/mI0Tk6iX//rgylUyrm NfAaVuMfU0AJlsuf8ju+rhNVFL/6F1UN5fMmsGT4NwDl4npKjFQut9OI/70flkvpfBAm CBlBnobxII5YvOkHZ0lgdRRXu8OdfHx6/satu5IxD1ox2MtYV+nKMq7peYNgmyvr0bC+ OIq3pRUnDCwEpEFVA6qJLxR8QrZ+/6W2RPWQgX2CBCAKXEIDWSA9KAVxo3RPKhGMTPLb uGGcJl+z3KVW6HiXIxTiSYekW4M9l8voJvZ25x1S61yw2RvCoVBcoea7T3+4s6eYUTHa 6Xiw== X-Gm-Message-State: AODbwcAOOsTDdVajyGylTjlo1J4gW4vkA1lgSnHQU458t+6I8M7viwIU 0UtBOaFDJV3i/P/IsCOwCR0ru0oQw3kDqCg= X-Received: by 10.129.82.80 with SMTP id g77mr3210261ywb.207.1494817854777; Sun, 14 May 2017 20:10:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.105.84 with HTTP; Sun, 14 May 2017 20:10:34 -0700 (PDT) In-Reply-To: <5915E180.2050106@erg.abdn.ac.uk> References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> <5915B787.4000307@erg.abdn.ac.uk> <5915E180.2050106@erg.abdn.ac.uk> From: Erik Kline Date: Mon, 15 May 2017 12:10:34 +0900 Message-ID: To: gorry@erg.abdn.ac.uk Cc: Michael Welzl , "taps@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114da6fc450fe5054f8767e5" Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 03:14:43 -0000 --001a114da6fc450fe5054f8767e5 Content-Type: multipart/alternative; boundary="001a114da6fc3d73bc054f876740" --001a114da6fc3d73bc054f876740 Content-Type: text/plain; charset="UTF-8" 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). --001a114da6fc3d73bc054f876740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.=C2=A0 It's basically just somet= hing you can use within cooperating administrative domains.

That said, it might b= e nice to be able to influence its value (even if only for applications tha= t are used with an administrative domain).
--001a114da6fc3d73bc054f876740-- --001a114da6fc450fe5054f8767e5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgUwrDxNUSFjgmy9EypFaPjVculdmfOiQ2 T6qxa064JtUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNTE1 MDMxMDU1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAFWwSNR2ILR+rp01NoHnRg5sFd6+bKJOgrnpt3E5V/dJoEiZz9Ob RJjSzWsjEpIx+3f/r4YqyRoKDg+GWY5W+dM0XRBQ4VxTrGKLzIkY47Af15BjDWKH6YhonBjfDX9I s5HQV6Lmk8RQb8ZOdeauMll8Soj2yCBRLBIyR5ALrUfceSTsfUF4KjD8EhhoWAkOhAydlUGo5RSl 7eGWHdPUO0piWgAEm1xt0WMUPdQyRkqcDSxVhHSwZ172kPUwbEXNFyG2CEQnlUlZ2xYwlAGDwo/c Ra00T58pO96X7IMzFOI713JOwlsj9qfvUM1gENnfhq7O+4eAyVXtuYxzUsLUVp8= --001a114da6fc450fe5054f8767e5-- From nobody Sun May 14 22:03:25 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B820C129476 for ; Sun, 14 May 2017 22:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJv7EPwAV2cj for ; Sun, 14 May 2017 22:03:21 -0700 (PDT) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D677129B44 for ; Sun, 14 May 2017 21:58:15 -0700 (PDT) Received: from mail-mx02.uio.no ([129.240.10.43]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dA85F-0004Dd-0n; Mon, 15 May 2017 06:58:13 +0200 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.5]) by mail-mx02.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dA85E-0009G0-LS; Mon, 15 May 2017 06:58:12 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Mon, 15 May 2017 06:58:10 +0200 Cc: gorry@erg.abdn.ac.uk, "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> <5915B787.4000307@erg.abdn.ac.uk> <5915E180.2050106@erg.abdn.ac.uk> To: Erik Kline X-UiO-SPF-Received: Received-SPF: neutral (mail-mx02.uio.no: 109.189.133.234 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.133.234; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.5]; X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 54673 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=5.0, autolearn=disabled, AWL=0.058, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 30AC7F2E0417FD22DBBD8B4D493BAC63113DF01A X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -48 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1425 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 05:03:24 -0000 Well, that may be true, but it's also not how it should be, according to th= e rfcs... and apps assuming such misbehavior isn't going to make the situati= on any better. today tcp relies on routers not introducing huge reordering, and net admins h= opefully 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 wrote: >=20 > 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 ba= sically just something you can use within cooperating administrative domains= . >=20 > That said, it might be nice to be able to influence its value (even if onl= y for applications that are used with an administrative domain). From nobody Mon May 15 12:14:53 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACD11201F8 for ; Mon, 15 May 2017 12:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tptCQB6EYcaR for ; Mon, 15 May 2017 12:14:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E32128E19 for ; Mon, 15 May 2017 12:11:37 -0700 (PDT) Received: from [128.9.184.22] ([128.9.184.22]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4FJAgp9006048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 May 2017 12:10:43 -0700 (PDT) To: Michael Welzl , " Fairhurst" Cc: "taps@ietf.org" References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> From: Joe Touch Message-ID: <46d4da5d-8e64-2d9b-fcda-c822d88469d7@isi.edu> Date: Mon, 15 May 2017 12:10:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no> Content-Type: multipart/alternative; boundary="------------2F3200DF8F9857C05BA1B36F" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 19:14:51 -0000 This is a multi-part message in MIME format. --------------2F3200DF8F9857C05BA1B36F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit FWIW: On 5/12/2017 5:31 AM, Michael Welzl wrote: >> ------------------- >> 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) > 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. 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 --------------2F3200DF8F9857C05BA1B36F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

FWIW:


On 5/12/2017 5:31 AM, Michael Welzl wrote:
-------------------
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)

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.
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
--------------2F3200DF8F9857C05BA1B36F-- From nobody Tue May 16 01:54:17 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8010129AE9; Tue, 16 May 2017 01:54:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149492485593.12055.10308145174558413458@ietfa.amsl.com> Date: Tue, 16 May 2017 01:54:15 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-udp-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 08:54:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols Authors : Godred Fairhurst Tom Jones Filename : draft-ietf-taps-transports-usage-udp-02.txt Pages : 19 Date : 2017-05-16 Abstract: This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. The resulting road map to documentation may be of help to users of the UDP and UDP-Lite protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-02 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 16 07:14:14 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6650212EB1A for ; Tue, 16 May 2017 07:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-EUtyJ3rFH2 for ; Tue, 16 May 2017 07:14:09 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D845112EBCF for ; Tue, 16 May 2017 07:09:13 -0700 (PDT) Received: from mail-mx05.uio.no ([129.240.10.49]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dAd9z-0006s9-0c for taps@ietf.org; Tue, 16 May 2017 16:09:11 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx05.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1dAd9y-0001QH-22; Tue, 16 May 2017 16:09:10 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> Date: Tue, 16 May 2017 16:09:09 +0200 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx05.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 10 sum msgs/h 4 total rcpts 54820 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.023, RP_MATCHES_RCVD=-0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B801877FE779EBBA5F2FB3F884522D7589F0779B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 13178 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:14:13 -0000 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 > 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]. [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]. *** > 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. [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. - 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] [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. > 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: The User Datagram Protocol = (UDP) 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 “provides a procedure for application programs to send = messages to other programs with a minimum of protocol mechanism (..)”. 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. 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 . Guidance on the use of the services provided by UDP is = provided in the UDP Guidelines . = The set of pass 1 primitives for UDP and UDP-Lite is = documented in [Michael] Done. - 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) [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. - 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, =09 [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: 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. [Michael] Done. - 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'. [Michael] Done. - 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. [Michael] Done. - 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. ...and: - 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 [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. - 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 [Michael] Done. Great catch, btw, this wasn't even a part of the pass 2 = primitives. - 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) [Michael] Done. - 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?) [Michael] See the other thread: I think we settled this. ------------------- 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 [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: MOVE: > o Specify IP Options > Protocols: UDP(-Lite) > MOVE: > o Obtain IP Options > 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? ------------------ > 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: 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 . [Michael] Done. From nobody Tue May 16 07:24:47 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E63129C1E for ; Tue, 16 May 2017 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7QfHeDLpaX8 for ; Tue, 16 May 2017 07:24:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 3D369129B9D for ; Tue, 16 May 2017 07:20:50 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:b0aa:7eb6:ebb9:62d6]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 55A3E1B015F2; Tue, 16 May 2017 17:15:53 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> To: Michael Welzl Cc: "taps@ietf.org" From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Tue, 16 May 2017 15:20:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:24:46 -0000 Thanks for dealing with this, comments in-line. On 16/05/2017 15:09, Michael Welzl wrote: > 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 > > > > >> 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]. > > > [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]. > *** > > > >> 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. > > [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. > > > > - 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] > > [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. > > > >> 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: > The User Datagram Protocol (UDP) > 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 > “provides a procedure for application programs to send messages > to other programs with a minimum of protocol mechanism > (..)”. > > 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. > > 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 . > Guidance on the use of the services provided by UDP is provided > in the UDP Guidelines . > > > The set of pass 1 primitives for UDP and UDP-Lite is documented > in > > > [Michael] Done. > > > - 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) > > [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. > Thanks. > > - 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, > > [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. > Correct. > > - 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. > > [Michael] Done. > > > - 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'. > > [Michael] Done. > > > - 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. > > [Michael] Done. > > > - 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. > > ...and: > > - 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 > > > [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. > > Your call if it makes sense to you. > > - 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 > > > [Michael] Done. Great catch, btw, this wasn't even a part of the pass 2 primitives. > > > > - 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) > > > [Michael] Done. > > > > - 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?) > > [Michael] See the other thread: I think we settled this. > > > ------------------- > 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 > > [Michael] I see that you have now replaced this with GET_MMS_S and GET_MMS_R > and will update my text accordingly. > Thanks - that would be correct. > > > - 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) > > [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? > I agree, I see the grouping now, and that's why you had the two apart. No action needed. > > ------------------ > >> 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: > 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 target="RFC8085">. > > [Michael] Done. > > Gorry From nobody Thu May 18 08:29:21 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0379612932A for ; Thu, 18 May 2017 08:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK0DdzIlLwOV for ; Thu, 18 May 2017 08:29:16 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C1212E870 for ; Thu, 18 May 2017 08:23:53 -0700 (PDT) From: Karl-Johan Grinnemo To: "vaibhav.bajpai@tum.de" CC: "taps@ietf.org" Thread-Topic: [Taps] review: draft-grinnemo-taps-he-02 Thread-Index: AQHSz+q/+PMYB4KcvEW8wvtRza6q9g== Date: Thu, 18 May 2017 15:23:48 +0000 Message-ID: <8D51B0B3-8C20-4E26-9D65-EA9E8156E1A3@kau.se> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/alternative; boundary="_000_8D51B0B38C204E269D65EA9E8156E1A3kause_" MIME-Version: 1.0 Archived-At: Subject: [Taps] review: draft-grinnemo-taps-he-02 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 15:29:19 -0000 --_000_8D51B0B38C204E269D65EA9E8156E1A3kause_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmFpYmhhdiENCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIChhbmQgc29ycnkgZm9yIG15 IGxhdGUgcmVwbHkpLg0KDQpPdmVyYWxsLCBJIGxpa2UgdGhpcyBkb2N1bWVudCAoc3VnZ2VzdGlv bnMgZm9yIGltcHJvdmVtZW50cyBiZWxvdykuIEkgaG9wZSBhbg0KDQpIRSBtZWNoYW5pc20gaGVs cHMgZ2V0IGZ1dHVyZSB0cmFuc3BvcnQgcHJvdG9jb2xzIGdldCB3aWRlciBhZG9wdGlvbi4NCg0K LS0gVmFpYmhhdg0KDQoNCiAgVG8gYmUgY29tcGxpYW50IHdpdGggUkZDIDY1NTUgW1JGQzY1NTVd LCB0aGUgUG9saWN5IE1hbmFnZW1lbnQgY29tcG9uZW50DQogIFNIT1VMRCwgaW4gdGhvc2UgY2Fz ZXMgdGhlcmUgYXJlIG5vIHBvbGljaWVzIHRlbGxpbmcgb3RoZXJ3aXNlLCBnaXZlIHByaW9yaXR5 DQogIHRvIElQdjYgb3ZlciBJUHY0Lg0KDQotLSBSRkMgNjU1NSBkb2VzIG5vdCBnaXZlIHByaW9y aXR5IHRvIHY2LiBZZXMsIHRoaXMgd2FzIHRoZSBvcmlnaW5hbA0KbW90aXZhdGlvbiBmb3IgdGhl IGRvY3VtZW50LCBidXQgUkZDIDY1NTUgc3RhdGVzIHRoYXQgdGhlIHByaW9yaXR5IGlzIGRpY3Rh dGVkDQpieSB0aGUgYWRkcmVzcyBzZWxlY3Rpb24gcG9saWN5IFtSRkMgNjcyNF0uIEluIG1ham9y aXR5IG9mIHRoZSBzY2VuYXJpb3MgdGhpcw0KYm9pbHMgZG93biB0byBnaXZpbmcgcHJpb3JpdHkg dG8gbmF0aXZlIHY2LiBIb3dldmVyLCBpZiBhIGhvc3QgaGFzIG5hdGl2ZSB2NA0KYW5kIFRlcmVk byBjb25uZWN0aXZpdHksIGEgSEUgaW1wbGVtZW50YXRpb24gd2lsbCBoYXBwaWx5IGdpdmUgcHJp b3JpdHkgdG8NCm5hdGl2ZSB2NCBvdmVyIFRlcmVkby4NCg0KDQoNClByb2JhYmx5IHRoaXMgcGFy dCBvZiB0aGUgdGV4dCBzaG91bGQgYmUgY2hhbmdlZCBzbyB0aGF0IGl0IGFsaWducyB3aXRoIFJG QyA2NTU1Lg0KDQpUbyBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9mIGNvbm5lY3Rpb24gYXR0ZW1wdHMg dGhhdCBhcmUgaW5pdGlhdGVkLCB0aGUgVHJhbnNwb3J0IFByb2JpbmcgY29tcG9uZW50IFNIT1VM RCBjYWNoZSB0aGUgb3V0Y29tZSBvZiBjb25uZWN0aW9uIGF0dGVtcHRzIGluIGEgcmVwb3NpdG9y eSBrZXB0IGJ5IHRoZSBQb2xpY3kgTWFuYWdlbWVudCBjb21wb25lbnQuIENhY2hlZCBjb25uZWN0 aW9uLWF0dGVtcHQgcmVzdWx0cyBTSE9VTEQgYmUgdmFsaWQgZm9yIGEgY29uZmlndXJhYmxlIGFt b3VudCBvZiB0aW1lIGFmdGVyIHdoaWNoIHRoZXkgU0hPVUxEIGV4cGlyZSBhbmQgaGF2ZSB0byBi ZSByZXBlYXRlZC4gLS0gSG93IGxvbmcgc2hvdWxkIHRoaXMgY2FjaGUgYmU/IEhvdyBpcyB0aGlz IGNvbmZpZ3VyZWQ/DQoNClRoZSBjYWNoZSBsaWZldGltZSBoYXMgYmVlbiBzZWVuIGFzIGFuIGlt cGxlbWVudGF0aW9uLWRlcGVuZGVudCBwYXJhbWV0ZXIsIGFuZCB0aHVzIGRlbGliZXJhdGVseSBv bWl0dGVkLg0KU3RpbGwsIEkgYW0gYXdhcmUgb2YgUkZDIDY1NTUgaW4gU2VjdGlvbiA0LCBBbGdv cml0aG0gUmVxdWlyZW1lbnRzLCBzYXlpbmcgdGhhdCAiQ2FjaGUgZW50cmllcyBzaG91bGQgYmUN CmZsdXNoZWQgd2hlbiB0aGVpciBhZ2UgZXhjZWVkcyBhIHN5c3RlbS1kZWZpbmVkIG1heGltdW0g b24gdGhlIG9yZGVyIG9mIDEwIG1pbnV0ZXMsIHNvIG1heWJlIHRoaXMgbmVlZHMNCnNvbWUgZnVy dGhlciBkZWxpYmVyYXRpb25zLg0KDQpEIHRoZW4gZ292ZXJucyB0aGUgZGVsYXkgYmV0d2VlbiB0 aGUgaW5pdGlhdGlvbiBvZiB0aGUgY29ubmVjdGlvbiBhdHRlbXB0cyBDMSBhbmQgQzIuIC0tIGhv dyBpcyBkZWxheSBEIGRldGVybWluZWQ/DQoNCkFzIHdpdGggdGhlIGNhY2hlIGxpZmV0aW1lLCB0 aGUgZXhhY3Qgd2F5IHRoZSBkZWxheSBpcyBzZXQgaXMgY29uc2lkZXJlZCBpbXBsZW1lbnRhdGlv biBkZXBlbmRlbnQuIEluIHRoZQ0KTkVBVCBzeXN0ZW0sIHRoZSBzeXN0ZW0gdXNlZCBpbiB0aGUg ZXhhbXBsZSBpbiBTZWN0aW9uIDYsIHRoZSBkZWxheSBmb3IgYSBjb25uZWN0aW9uIGF0dGVtcHQg aXMgc2V0IGFzDQpERUxUQSAqIHByaW9yaXR5LCB3aGVyZSBERUxUQSBpcyBhIHBhcmFtZXRlciB3 aGljaCBnb3Zlcm5zIHRoZSB0aW1lIGRpZmZlcmVuY2UgYmV0d2VlbiB0d28gY29uc2VjdXRpdmUN CnByaW9yaXR5IGxldmVscyAoaW4gTkVBVCwgcHJpb3JpdHkgZ29lcyBmcm9tIDAgYW5kIHVwd2Fy ZHMsIHdpdGggMCBiZWluZyB0aGUgaGlnaGVzdCBwcmlvcml0eSkuDQoNCkZvciB0aGUgVHJhbnNw b3J0IFByb2JpbmcgY29tcG9uZW50IHRvIGJlIGFibGUgdG8gZWZmaWNpZW50bHkgdXNlIHRoZSBj b25uZWN0aW9uLWF0dGVtcHQgY2FjaGUsIGFscmVhZHktaW5pdGlhdGVkLCBub24td2lubmluZyB0 cmFuc3BvcnQgc29sdXRpb25zIFNIT1VMRCBOT1QgYmUgdGVybWluYXRlZCBhcyBzb29uIGFzIGEg d2lubmluZyBjb25uZWN0aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkLiAtLSBJIGZvdW5kIHRoaXMg c2VudGVuY2UgY29uZnVzaW5nLiBQZXJoYXBzIGFuIGV4YW1wbGUgaGVscHMgaGVyZS4NCg0KSSB3 aWxsIGRlZmluaXRlbHkgcmVmb3JtdWxhdGUgdGhpcy4gTWF5YmUsIGl0IHdvdWxkIGJlIGVhc2ll ciB0byByZWFkIHRoaXMgc2VudGVuY2UgaWYgaXQgd2FzDQpzaG9ydGVuZWQgdG8gIkZvciB0aGUg VHJhbnNwb3J0IFByb2JpbmcgY29tcG9uZW50IHRvIGJlIGFibGUgdG8gZWZmaWNpZW50bHkgdXNl IHRoZSBjb25uZWN0aW9uLWF0dGVtcHQNCmNhY2hlLCBhbHJlYWR5LWluaXRpYXRlZCB0cmFuc3Bv cnQgc29sdXRpb25zIFNIT1VMRCBOT1QgYmUgdGVybWluYXRlZC4uLiINCg0KQXMgcG9pbnRlZCBv dXQgaW4gUkZDIDY1NTUgW1JGQzY1NTVdLCBhIEhFIGFsZ29yaXRobSBzaG91bGQgbm90IHdhc3Rl IG5ldHdvcmtpbmcgcmVzb3VyY2VzIGJ5IHJvdXRpbmVseSBtYWtpbmcgc2ltdWx0YW5lb3VzIGNv bm5lY3Rpb24gYXR0ZW1wdHMuIFRvIHRoaXMgZW5kLCB0aGUgSEUgYWxnb3JpdGhtIHNob3VsZCBj YWNoZSB0aGUgb3V0Y29tZSBvZiBwcmV2aW91cyBjb25uZWN0aW9uIGF0dGVtcHRzIHRvIHRoZSBz YW1lIHBlZXIuIFRoZSBpbXBhY3QgYW5kIGVmZmljaWVuY3kgb2YgdGhlIEhFIGFsZ29yaXRobSBo YXMgYmVlbiBldmFsdWF0ZWQgaW4gW1BhcGFzdGVyZ2lvdTE2XS4gVGhlIHBhcGVyIHN1Z2dlc3Rz IHRoYXQgY2FjaGluZyBzaWduaWZpY2FudGx5IHJlZHVjZXMgdGhlIENQVSBsb2FkIGltcG9zZWQg YnkgYSBIRSBtZWNoYW5pc20uIC0tIFBlcmhhcHMgbWFrZSBpdCBjbGVhciB0aGF0IFtQYXBhc3Rl cmdpb3UxNl0gZGlzY3Vzc2VzIHRoZSBpbXBhY3Qgb2YgbWVtb3J5IGFuZCBjcHUgcmVzb3VyY2Vz IG9uIHRoZSBlbmQtaG9zdCBhbmQgbm90IG5ldHdvcmtpbmcgcmVzb3VyY2VzIG9uIHRoZSB3aXJl Lg0KDQpBZ3JlZS4NCg0KQ29uc2lkZXIgYSBzY2VuYXJpbyBpbiB3aGljaCBhbiBJUHY0LW9ubHkg Y2xpZW50IHVzaW5nIHRoZSAuLi4gLS0gV2h5IG5vdCB2Ni1vbmx5IGNsaWVudCBpbnN0ZWFkPyA6 KQ0KDQpObyBwYXJ0aWN1bGFyIHJlYXNvbiwgY291bGQgcHJvYmFibHkgY2hhbmdlIGZyb20gSVB2 NCB0byBJUHY2Lg0KDQotLSBJdCB3YXMgdW5jbGVhciB0byBtZSBob3cgdGhlIHRoZSBsaXN0IG9m IGNhbmRpZGF0ZSBwcm90b2NvbHMgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBwb2xpY3kgbWFuYWdlci4g QW4gZXhhbXBsZSB3b3VsZCBoZWxwIGhlcmUuIEkgYW0gZXZlbiB0aGlua2luZyBwZXJoYXBzIHRo aXMgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNClRoZSBwb2xpY3kgbWFuYWdl ciBpcyBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIEktRC4gU3RpbGwsIG1heWJlIGl0IHdv dWxkIGhlbHANCnRvIHN1cHBseSBhIHJlZmVyZW5jZSB0byBvdXIgcGFwZXIsIE4uIEtoYWRlbWks IEQuIFJvcywgTS4gV2VsemwsIFouIEJvemFrb3YsIEEuIEJydW5zdHJvbSwNCkcuIEZhaXJodXJz dCwgSy4tSi4gR3Jpbm5lbW8sIEQuIEhheWVzLCBQLiBIdXJ0aWcsIFQuIEpvbmVzLCBTLiBNYW5n aWFudGUsIE0uIFR1zIh4ZW4sIGFuZA0KRi4gV2VpbnJhbmsuICJORUFUOiBBIFBsYXRmb3JtLSBh bmQgUHJvdG9jb2wtSW5kZXBlbmRlbnQgSW50ZXJuZXQgVHJhbnNwb3J0IEFQSSzigJ0gd2hpY2gg b2ZmZXJzDQphIGRlc2NyaXB0aW9uIG9mIHRoZSBwb2xpY3kgbWFuYWdlci4NCg0KDQpBZ2Fpbiwg dGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KDQpCZXN0IFJlZ2FyZHMNCkthcmwtSm9oYW4gR3Jp bm5lbW8NCkxla3Rvci9TZW5pb3IgTGVjdHVyZXINCkRhdGF2ZXRlbnNrYXAvQ29tcHV0ZXIgU2Np ZW5jZQ0KS2FybHN0YWRzIHVuaXZlcnNpdGV0L0thcmxzdGFkIHVuaXZlcnNpdHkNClRmbi46L1Bo b25lOiArNDYgKDApNTQgNzAwIDI0IDQwDQpNb2JpbDovTW9iaWxlOiArNDYgKDApNzA4IDc0MCA1 MTENClNreXBlOiBrYXJsZ3Jpbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBWYWliaGF2 IEJhanBhaSB3d3cudmFpYmhhdmJhanBhaS5jb208aHR0cDovL3d3dy52YWliaGF2YmFqcGFpLmNv bS8+IFBvc3Rkb2N0b3JhbCBSZXNlYXJjaGVyIFRVIE11bmljaCwgR2VybWFueSAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KDQoNCg== --_000_8D51B0B38C204E269D65EA9E8156E1A3kause_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPHByZSBjbGFzcz0id29yZHdyYXAi IHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBvdmVyZmxvdzogYXV0bzsgZm9udC1mYW1p bHk6IE1lbmxvLCBNb25hY28sIENvbnNvbGFzLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZv bnQtc2l6ZTogMTNweDsgcGFkZGluZzogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0 b206IDEwcHg7IGxpbmUtaGVpZ2h0OiAxLjQyODU3MTQzOyB3b3JkLWJyZWFrOiBub3JtYWw7IHdv cmQtd3JhcDogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsgYm9yZGVyOiAwcHggbm9u ZSBibGFjazsgYm9yZGVyLXRvcC1sZWZ0LXJhZGl1czogNHB4OyBib3JkZXItdG9wLXJpZ2h0LXJh ZGl1czogNHB4OyBib3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9t LWxlZnQtcmFkaXVzOiA0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxmb250IGNvbG9yPSIj MDIwMjAyIiBjbGFzcz0iIj5IaSBWYWliaGF2ITwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9Indv cmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgb3ZlcmZsb3c6IGF1dG87IGZv bnQtZmFtaWx5OiBNZW5sbywgTW9uYWNvLCBDb25zb2xhcywgJ0NvdXJpZXIgTmV3JywgbW9ub3Nw YWNlOyBmb250LXNpemU6IDEzcHg7IHBhZGRpbmc6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tYm90dG9tOiAxMHB4OyBsaW5lLWhlaWdodDogMS40Mjg1NzE0Mzsgd29yZC1icmVhazogbm9y bWFsOyB3b3JkLXdyYXA6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IGJvcmRlcjog MHB4IG5vbmUgYmxhY2s7IGJvcmRlci10b3AtbGVmdC1yYWRpdXM6IDRweDsgYm9yZGVyLXRvcC1y aWdodC1yYWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1yaWdodC1yYWRpdXM6IDRweDsgYm9yZGVy LWJvdHRvbS1sZWZ0LXJhZGl1czogNHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij48Zm9udCBj b2xvcj0iIzAyMDIwMiIgY2xhc3M9IiI+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIChhbmQgc29y cnkgZm9yIG15IGxhdGUgcmVwbHkpLjwvZm9udD48L3ByZT4NCjxwcmUgY2xhc3M9IndvcmR3cmFw IiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgb3ZlcmZsb3c6IGF1dG87IGZvbnQtZmFt aWx5OiBNZW5sbywgTW9uYWNvLCBDb25zb2xhcywgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBm b250LXNpemU6IDEzcHg7IHBhZGRpbmc6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90 dG9tOiAxMHB4OyBsaW5lLWhlaWdodDogMS40Mjg1NzE0Mzsgd29yZC1icmVhazogbm9ybWFsOyB3 b3JkLXdyYXA6IG5vcm1hbDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7IGJvcmRlcjogMHB4IG5v bmUgYmxhY2s7IGJvcmRlci10b3AtbGVmdC1yYWRpdXM6IDRweDsgYm9yZGVyLXRvcC1yaWdodC1y YWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1yaWdodC1yYWRpdXM6IDRweDsgYm9yZGVyLWJvdHRv bS1sZWZ0LXJhZGl1czogNHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij48Zm9udCBjb2xvcj0i IzU1NjRmZiIgY2xhc3M9IiI+T3ZlcmFsbCwgSSBsaWtlIHRoaXMgZG9jdW1lbnQgKHN1Z2dlc3Rp b25zIGZvciBpbXByb3ZlbWVudHMgYmVsb3cpLiBJIGhvcGUgYW48L2ZvbnQ+PC9wcmU+DQo8cHJl IGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG92ZXJmbG93 OiBhdXRvOyBmb250LWZhbWlseTogTWVubG8sIE1vbmFjbywgQ29uc29sYXMsICdDb3VyaWVyIE5l dycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxM3B4OyBwYWRkaW5nOiAwcHg7IG1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLWJvdHRvbTogMTBweDsgbGluZS1oZWlnaHQ6IDEuNDI4NTcxNDM7IHdvcmQt YnJlYWs6IG5vcm1hbDsgd29yZC13cmFwOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRl OyBib3JkZXI6IDBweCBub25lIGJsYWNrOyBib3JkZXItdG9wLWxlZnQtcmFkaXVzOiA0cHg7IGJv cmRlci10b3AtcmlnaHQtcmFkaXVzOiA0cHg7IGJvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOiA0 cHg7IGJvcmRlci1ib3R0b20tbGVmdC1yYWRpdXM6IDRweDsgd2hpdGUtc3BhY2U6IHByZS13cmFw OyI+PGZvbnQgY29sb3I9IiM1NTY0ZmYiIGNsYXNzPSIiPkhFIG1lY2hhbmlzbSBoZWxwcyBnZXQg ZnV0dXJlIHRyYW5zcG9ydCBwcm90b2NvbHMgZ2V0IHdpZGVyIGFkb3B0aW9uLg0KDQotLSBWYWli aGF2DQoNCg0KICBUbyBiZSBjb21wbGlhbnQgd2l0aCBSRkMgNjU1NSBbUkZDNjU1NV0sIHRoZSBQ b2xpY3kgTWFuYWdlbWVudCBjb21wb25lbnQNCiAgU0hPVUxELCBpbiB0aG9zZSBjYXNlcyB0aGVy ZSBhcmUgbm8gcG9saWNpZXMgdGVsbGluZyBvdGhlcndpc2UsIGdpdmUgcHJpb3JpdHkNCiAgdG8g SVB2NiBvdmVyIElQdjQuDQoNCi0tIFJGQyA2NTU1IGRvZXMgbm90IGdpdmUgcHJpb3JpdHkgdG8g djYuIFllcywgdGhpcyB3YXMgdGhlIG9yaWdpbmFsDQptb3RpdmF0aW9uIGZvciB0aGUgZG9jdW1l bnQsIGJ1dCBSRkMgNjU1NSBzdGF0ZXMgdGhhdCB0aGUgcHJpb3JpdHkgaXMgZGljdGF0ZWQNCmJ5 IHRoZSBhZGRyZXNzIHNlbGVjdGlvbiBwb2xpY3kgW1JGQyA2NzI0XS4gSW4gbWFqb3JpdHkgb2Yg dGhlIHNjZW5hcmlvcyB0aGlzDQpib2lscyBkb3duIHRvIGdpdmluZyBwcmlvcml0eSB0byBuYXRp dmUgdjYuIEhvd2V2ZXIsIGlmIGEgaG9zdCBoYXMgbmF0aXZlIHY0DQphbmQgVGVyZWRvIGNvbm5l Y3Rpdml0eSwgYSBIRSBpbXBsZW1lbnRhdGlvbiB3aWxsIGhhcHBpbHkgZ2l2ZSBwcmlvcml0eSB0 bw0KbmF0aXZlIHY0IG92ZXIgVGVyZWRvLg0KDQo8L2ZvbnQ+PHByZSBjbGFzcz0id29yZHdyYXAi IHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBvdmVyZmxvdzogYXV0bzsgZm9udC1mYW1p bHk6IE1lbmxvLCBNb25hY28sIENvbnNvbGFzLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IHBh ZGRpbmc6IDBweDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAxMHB4OyBsaW5lLWhl aWdodDogMS40Mjg1NzE0Mzsgd29yZC1icmVhazogbm9ybWFsOyB3b3JkLXdyYXA6IG5vcm1hbDsg Ym9yZGVyOiAwcHggbm9uZSBibGFjazsgYm9yZGVyLXRvcC1sZWZ0LXJhZGl1czogNHB4OyBib3Jk ZXItdG9wLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1czogNHB4 OyBib3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOiA0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsi PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDIsIDIsIDIpOyIgY2xhc3M9IiI+UHJvYmFibHkgdGhp cyBwYXJ0IG9mIHRoZSB0ZXh0IHNob3VsZCBiZSBjaGFuZ2VkIHNvIHRoYXQgaXQgYWxpZ25zIHdp dGggUkZDIDY1NTUuPC9zcGFuPjwvcHJlPjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPjwvZGl2 Pjxmb250IGNvbG9yPSIjNTU2NGZmIiBjbGFzcz0iIj4gIFRvIG1pbmltaXplIHRoZSBudW1iZXIg b2YgY29ubmVjdGlvbiBhdHRlbXB0cyB0aGF0IGFyZSBpbml0aWF0ZWQsDQogIHRoZSBUcmFuc3Bv cnQgUHJvYmluZyBjb21wb25lbnQgU0hPVUxEIGNhY2hlIHRoZSBvdXRjb21lIG9mDQogIGNvbm5l Y3Rpb24gYXR0ZW1wdHMgaW4gYSByZXBvc2l0b3J5IGtlcHQgYnkgdGhlIFBvbGljeSBNYW5hZ2Vt ZW50DQogIGNvbXBvbmVudC4NCg0KICBDYWNoZWQgY29ubmVjdGlvbi1hdHRlbXB0IHJlc3VsdHMg U0hPVUxEIGJlIHZhbGlkIGZvciBhIGNvbmZpZ3VyYWJsZQ0KICBhbW91bnQgb2YgdGltZSBhZnRl ciB3aGljaCB0aGV5IFNIT1VMRCBleHBpcmUgYW5kIGhhdmUgdG8gYmUgcmVwZWF0ZWQuDQoNCi0t IEhvdyBsb25nIHNob3VsZCB0aGlzIGNhY2hlIGJlPyBIb3cgaXMgdGhpcyBjb25maWd1cmVkPw0K PC9mb250PjwvcHJlPg0KPHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJib3gtc2l6aW5nOiBi b3JkZXItYm94OyBvdmVyZmxvdzogYXV0bzsgZm9udC1mYW1pbHk6IE1lbmxvLCBNb25hY28sIENv bnNvbGFzLCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTNweDsgcGFkZGlu ZzogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwcHg7IGxpbmUtaGVpZ2h0 OiAxLjQyODU3MTQzOyB3b3JkLWJyZWFrOiBub3JtYWw7IHdvcmQtd3JhcDogbm9ybWFsOyBiYWNr Z3JvdW5kLWNvbG9yOiB3aGl0ZTsgYm9yZGVyOiAwcHggbm9uZSBibGFjazsgYm9yZGVyLXRvcC1s ZWZ0LXJhZGl1czogNHB4OyBib3JkZXItdG9wLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90 dG9tLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOiA0cHg7IHdo aXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0iYm94LXNp emluZzogYm9yZGVyLWJveDsgb3ZlcmZsb3c6IGF1dG87IGZvbnQtZmFtaWx5OiBNZW5sbywgTW9u YWNvLCBDb25zb2xhcywgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBwYWRkaW5nOiAwcHg7IG1h cmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMTBweDsgbGluZS1oZWlnaHQ6IDEuNDI4NTcx NDM7IHdvcmQtYnJlYWs6IG5vcm1hbDsgd29yZC13cmFwOiBub3JtYWw7IGJvcmRlcjogMHB4IG5v bmUgYmxhY2s7IGJvcmRlci10b3AtbGVmdC1yYWRpdXM6IDRweDsgYm9yZGVyLXRvcC1yaWdodC1y YWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1yaWdodC1yYWRpdXM6IDRweDsgYm9yZGVyLWJvdHRv bS1sZWZ0LXJhZGl1czogNHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij48Zm9udCBjb2xvcj0i IzAyMDIwMiIgY2xhc3M9IiI+VGhlIGNhY2hlIGxpZmV0aW1lIGhhcyBiZWVuIHNlZW4gYXMgYW4g aW1wbGVtZW50YXRpb24tZGVwZW5kZW50IHBhcmFtZXRlciwgYW5kIHRodXMgZGVsaWJlcmF0ZWx5 IG9taXR0ZWQuDQpTdGlsbCwgSSBhbSBhd2FyZSBvZiBSRkMgNjU1NSBpbiBTZWN0aW9uIDQsIEFs Z29yaXRobSBSZXF1aXJlbWVudHMsIHNheWluZyB0aGF0ICZxdW90O0NhY2hlIGVudHJpZXMgc2hv dWxkIGJlDQpmbHVzaGVkIHdoZW4gdGhlaXIgYWdlIGV4Y2VlZHMgYSBzeXN0ZW0tZGVmaW5lZCBt YXhpbXVtIG9uIHRoZSBvcmRlciBvZiAxMCBtaW51dGVzLCBzbyBtYXliZSB0aGlzIG5lZWRzDQpz b21lIGZ1cnRoZXIgZGVsaWJlcmF0aW9ucy48L2ZvbnQ+PC9wcmU+PGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+PC9kaXY+PGZvbnQgY29sb3I9IiM1NTY0ZmYiIGNsYXNzPSIiPiAgRCB0aGVuIGdv dmVybnMgdGhlIGRlbGF5IGJldHdlZW4gdGhlIGluaXRpYXRpb24gb2YgdGhlIGNvbm5lY3Rpb24N CiAgYXR0ZW1wdHMgQzEgYW5kIEMyLg0KDQotLSBob3cgaXMgZGVsYXkgRCBkZXRlcm1pbmVkPw0K DQo8L2ZvbnQ+PHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXIt Ym94OyBvdmVyZmxvdzogYXV0bzsgZm9udC1mYW1pbHk6IE1lbmxvLCBNb25hY28sIENvbnNvbGFz LCAnQ291cmllciBOZXcnLCBtb25vc3BhY2U7IHBhZGRpbmc6IDBweDsgbWFyZ2luLXRvcDogMHB4 OyBtYXJnaW4tYm90dG9tOiAxMHB4OyBsaW5lLWhlaWdodDogMS40Mjg1NzE0Mzsgd29yZC1icmVh azogbm9ybWFsOyB3b3JkLXdyYXA6IG5vcm1hbDsgYm9yZGVyOiAwcHggbm9uZSBibGFjazsgYm9y ZGVyLXRvcC1sZWZ0LXJhZGl1czogNHB4OyBib3JkZXItdG9wLXJpZ2h0LXJhZGl1czogNHB4OyBi b3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9tLWxlZnQtcmFkaXVz OiA0cHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiPjxmb250IGNvbG9yPSIjMDIwMjAyIiBjbGFz cz0iIj5BcyB3aXRoIHRoZSBjYWNoZSBsaWZldGltZSwgdGhlIGV4YWN0IHdheSB0aGUgZGVsYXkg aXMgc2V0IGlzIGNvbnNpZGVyZWQgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50LiBJbiB0aGUNCk5F QVQgc3lzdGVtLCB0aGUgc3lzdGVtIHVzZWQgaW4gdGhlIGV4YW1wbGUgaW4gU2VjdGlvbiA2LCB0 aGUgZGVsYXkgZm9yIGEgY29ubmVjdGlvbiBhdHRlbXB0IGlzIHNldCBhcw0KPC9mb250PjxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDIsIDIsIDIpOyIgY2xhc3M9IiI+REVMVEEgKiBwcmlvcml0eSwg d2hlcmUgREVMVEEgaXMgYSBwYXJhbWV0ZXIgd2hpY2ggZ292ZXJucyB0aGUgdGltZSBkaWZmZXJl bmNlIGJldHdlZW4gdHdvIGNvbnNlY3V0aXZlDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoMiwgMiwgMik7IiBjbGFzcz0iIj5wcmlvcml0eSBsZXZlbHMgKGluIE5FQVQsIHByaW9yaXR5 IGdvZXMgZnJvbSAwIGFuZCB1cHdhcmRzLCB3aXRoIDAgYmVpbmcgdGhlIGhpZ2hlc3QgcHJpb3Jp dHkpLjwvc3Bhbj48L3ByZT48ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj48L2Rpdj48Zm9udCBj b2xvcj0iIzU1NjRmZiIgY2xhc3M9IiI+ICBGb3IgdGhlIFRyYW5zcG9ydCBQcm9iaW5nIGNvbXBv bmVudCB0byBiZSBhYmxlIHRvIGVmZmljaWVudGx5IHVzZSB0aGUNCiAgY29ubmVjdGlvbi1hdHRl bXB0IGNhY2hlLCBhbHJlYWR5LWluaXRpYXRlZCwgbm9uLXdpbm5pbmcgdHJhbnNwb3J0IHNvbHV0 aW9ucw0KICBTSE9VTEQgTk9UIGJlIHRlcm1pbmF0ZWQgYXMgc29vbiBhcyBhIHdpbm5pbmcgY29u bmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZC4NCg0KLS0gSSBmb3VuZCB0aGlzIHNlbnRlbmNl IGNvbmZ1c2luZy4gUGVyaGFwcyBhbiBleGFtcGxlIGhlbHBzIGhlcmUuPC9mb250PjwvcHJlPg0K PHByZSBjbGFzcz0id29yZHdyYXAiIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBvdmVy ZmxvdzogYXV0bzsgZm9udC1mYW1pbHk6IE1lbmxvLCBNb25hY28sIENvbnNvbGFzLCAnQ291cmll ciBOZXcnLCBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTNweDsgcGFkZGluZzogMHB4OyBtYXJnaW4t dG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwcHg7IGxpbmUtaGVpZ2h0OiAxLjQyODU3MTQzOyB3 b3JkLWJyZWFrOiBub3JtYWw7IHdvcmQtd3JhcDogbm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiB3 aGl0ZTsgYm9yZGVyOiAwcHggbm9uZSBibGFjazsgYm9yZGVyLXRvcC1sZWZ0LXJhZGl1czogNHB4 OyBib3JkZXItdG9wLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1 czogNHB4OyBib3JkZXItYm90dG9tLWxlZnQtcmFkaXVzOiA0cHg7IHdoaXRlLXNwYWNlOiBwcmUt d3JhcDsiPjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJv eDsgb3ZlcmZsb3c6IGF1dG87IGZvbnQtZmFtaWx5OiBNZW5sbywgTW9uYWNvLCBDb25zb2xhcywg J0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBwYWRkaW5nOiAwcHg7IG1hcmdpbi10b3A6IDBweDsg bWFyZ2luLWJvdHRvbTogMTBweDsgbGluZS1oZWlnaHQ6IDEuNDI4NTcxNDM7IHdvcmQtYnJlYWs6 IG5vcm1hbDsgd29yZC13cmFwOiBub3JtYWw7IGJvcmRlcjogMHB4IG5vbmUgYmxhY2s7IGJvcmRl ci10b3AtbGVmdC1yYWRpdXM6IDRweDsgYm9yZGVyLXRvcC1yaWdodC1yYWRpdXM6IDRweDsgYm9y ZGVyLWJvdHRvbS1yaWdodC1yYWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1sZWZ0LXJhZGl1czog NHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij48Zm9udCBjb2xvcj0iIzAyMDIwMiIgY2xhc3M9 IiI+SSB3aWxsIGRlZmluaXRlbHkgcmVmb3JtdWxhdGUgdGhpcy4gTWF5YmUsIGl0IHdvdWxkIGJl IGVhc2llciB0byByZWFkIHRoaXMgc2VudGVuY2UgaWYgaXQgd2FzDQpzaG9ydGVuZWQgdG8gJnF1 b3Q7Rm9yIHRoZSBUcmFuc3BvcnQgUHJvYmluZyBjb21wb25lbnQgdG8gYmUgYWJsZSB0byBlZmZp Y2llbnRseSB1c2UgdGhlIGNvbm5lY3Rpb24tYXR0ZW1wdA0KY2FjaGUsIGFscmVhZHktaW5pdGlh dGVkIHRyYW5zcG9ydCBzb2x1dGlvbnMgU0hPVUxEIE5PVCBiZSB0ZXJtaW5hdGVkLi4uJnF1b3Q7 PC9mb250PjwvcHJlPjxmb250IGNvbG9yPSIjNTU2NGZmIiBjbGFzcz0iIj4gIEFzIHBvaW50ZWQg b3V0IGluIFJGQyA2NTU1IFtSRkM2NTU1XSwgYSBIRSBhbGdvcml0aG0gc2hvdWxkIG5vdCB3YXN0 ZQ0KICBuZXR3b3JraW5nIHJlc291cmNlcyBieSByb3V0aW5lbHkgbWFraW5nIHNpbXVsdGFuZW91 cyBjb25uZWN0aW9uDQogIGF0dGVtcHRzLiAgVG8gdGhpcyBlbmQsIHRoZSBIRSBhbGdvcml0aG0g c2hvdWxkIGNhY2hlIHRoZSBvdXRjb21lIG9mDQogIHByZXZpb3VzIGNvbm5lY3Rpb24gYXR0ZW1w dHMgdG8gdGhlIHNhbWUgcGVlci4gIFRoZSBpbXBhY3QgYW5kDQogIGVmZmljaWVuY3kgb2YgdGhl IEhFIGFsZ29yaXRobSBoYXMgYmVlbiBldmFsdWF0ZWQgaW4NCiAgW1BhcGFzdGVyZ2lvdTE2XS4g IFRoZSBwYXBlciBzdWdnZXN0cyB0aGF0IGNhY2hpbmcgc2lnbmlmaWNhbnRseQ0KICByZWR1Y2Vz IHRoZSBDUFUgbG9hZCBpbXBvc2VkIGJ5IGEgSEUgbWVjaGFuaXNtLg0KDQotLSBQZXJoYXBzIG1h a2UgaXQgY2xlYXIgdGhhdCBbUGFwYXN0ZXJnaW91MTZdIGRpc2N1c3NlcyB0aGUgaW1wYWN0IG9m IG1lbW9yeQ0KICAgYW5kIGNwdSByZXNvdXJjZXMgb24gdGhlIGVuZC1ob3N0IGFuZCBub3QgbmV0 d29ya2luZyByZXNvdXJjZXMgb24gdGhlIHdpcmUuDQoNCjwvZm9udD48cHJlIGNsYXNzPSJ3b3Jk d3JhcCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG92ZXJmbG93OiBhdXRvOyBmb250 LWZhbWlseTogTWVubG8sIE1vbmFjbywgQ29uc29sYXMsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFj ZTsgcGFkZGluZzogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwcHg7IGxp bmUtaGVpZ2h0OiAxLjQyODU3MTQzOyB3b3JkLWJyZWFrOiBub3JtYWw7IHdvcmQtd3JhcDogbm9y bWFsOyBib3JkZXI6IDBweCBub25lIGJsYWNrOyBib3JkZXItdG9wLWxlZnQtcmFkaXVzOiA0cHg7 IGJvcmRlci10b3AtcmlnaHQtcmFkaXVzOiA0cHg7IGJvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVz OiA0cHg7IGJvcmRlci1ib3R0b20tbGVmdC1yYWRpdXM6IDRweDsgd2hpdGUtc3BhY2U6IHByZS13 cmFwOyI+PGZvbnQgY29sb3I9IiMwMjAyMDIiIGNsYXNzPSIiPkFncmVlLjwvZm9udD48L3ByZT48 Zm9udCBjb2xvcj0iIzU1NjRmZiIgY2xhc3M9IiI+ICBDb25zaWRlciBhIHNjZW5hcmlvIGluIHdo aWNoIGFuIElQdjQtb25seSBjbGllbnQgdXNpbmcgdGhlIC4uLg0KDQotLSBXaHkgbm90IHY2LW9u bHkgY2xpZW50IGluc3RlYWQ/IDopDQoNCjwvZm9udD48cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5 bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG92ZXJmbG93OiBhdXRvOyBmb250LWZhbWlseTog TWVubG8sIE1vbmFjbywgQ29uc29sYXMsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgcGFkZGlu ZzogMHB4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwcHg7IGxpbmUtaGVpZ2h0 OiAxLjQyODU3MTQzOyB3b3JkLWJyZWFrOiBub3JtYWw7IHdvcmQtd3JhcDogbm9ybWFsOyBib3Jk ZXI6IDBweCBub25lIGJsYWNrOyBib3JkZXItdG9wLWxlZnQtcmFkaXVzOiA0cHg7IGJvcmRlci10 b3AtcmlnaHQtcmFkaXVzOiA0cHg7IGJvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOiA0cHg7IGJv cmRlci1ib3R0b20tbGVmdC1yYWRpdXM6IDRweDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyI+PGZv bnQgY29sb3I9IiMwMjAyMDIiIGNsYXNzPSIiPk5vIHBhcnRpY3VsYXIgcmVhc29uLCBjb3VsZCBw cm9iYWJseSBjaGFuZ2UgZnJvbSBJUHY0IHRvIElQdjYuPC9mb250PjwvcHJlPjxmb250IGNvbG9y PSIjNTU2NGZmIiBjbGFzcz0iIj4tLSBJdCB3YXMgdW5jbGVhciB0byBtZSBob3cgdGhlIHRoZSBs aXN0IG9mIGNhbmRpZGF0ZSBwcm90b2NvbHMgaXMgZ2VuZXJhdGVkDQogICBieSB0aGUgcG9saWN5 IG1hbmFnZXIuIEFuIGV4YW1wbGUgd291bGQgaGVscCBoZXJlLiBJIGFtIGV2ZW4gdGhpbmtpbmcN CiAgIHBlcmhhcHMgdGhpcyBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48L2ZvbnQ+ PC9wcmU+DQo8cHJlIGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1i b3g7IG92ZXJmbG93OiBhdXRvOyBwYWRkaW5nOiAwcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMTBweDsgbGluZS1oZWlnaHQ6IDEuNDI4NTcxNDM7IHdvcmQtYnJlYWs6IG5vcm1h bDsgd29yZC13cmFwOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyBib3JkZXI6IDBw eCBub25lIGJsYWNrOyBib3JkZXItdG9wLWxlZnQtcmFkaXVzOiA0cHg7IGJvcmRlci10b3Atcmln aHQtcmFkaXVzOiA0cHg7IGJvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOiA0cHg7IGJvcmRlci1i b3R0b20tbGVmdC1yYWRpdXM6IDRweDsiPjxwcmUgY2xhc3M9IndvcmR3cmFwIiBzdHlsZT0iYm94 LXNpemluZzogYm9yZGVyLWJveDsgb3ZlcmZsb3c6IGF1dG87IHBhZGRpbmc6IDBweDsgbWFyZ2lu LXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAxMHB4OyBsaW5lLWhlaWdodDogMS40Mjg1NzE0Mzsg d29yZC1icmVhazogbm9ybWFsOyB3b3JkLXdyYXA6IG5vcm1hbDsgYm9yZGVyOiAwcHggbm9uZSBi bGFjazsgYm9yZGVyLXRvcC1sZWZ0LXJhZGl1czogNHB4OyBib3JkZXItdG9wLXJpZ2h0LXJhZGl1 czogNHB4OyBib3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1czogNHB4OyBib3JkZXItYm90dG9tLWxl ZnQtcmFkaXVzOiA0cHg7Ij48Zm9udCBjb2xvcj0iIzAyMDIwMiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBNZW5sbywgTW9uYWNvLCBDb25zb2xhcywgJ0NvdXJpZXIgTmV3JywgbW9ub3NwYWNlOyBmb250 LXNpemU6IDEzcHg7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPlRoZSBwb2xpY3kg bWFuYWdlciBpcyBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiB0aGlzIEktRC4gU3RpbGwsIG1heWJl IGl0IHdvdWxkIGhlbHANCnRvIHN1cHBseSBhIHJlZmVyZW5jZSB0byBvdXIgcGFwZXIsIDwvZm9u dD48Zm9udCBjb2xvcj0iIzAyMDIwMiIgZmFjZT0iTWVubG8iIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJ3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0iIj5OLiBLaGFkZW1pLCBELiBSb3MsIE0u IFdlbHpsLCBaLiBCb3pha292LCBBLiBCcnVuc3Ryb20sDQpHLiBGYWlyaHVyc3QsIEsuLUouIEdy aW5uZW1vLCBELiBIYXllcywgUC4gSHVydGlnLCBULiBKb25lcywgUy4gTWFuZ2lhbnRlLCBNLiBU dcyIeGVuLCBhbmQNCkYuIFdlaW5yYW5rLiAmcXVvdDtORUFUOiBBIFBsYXRmb3JtLSBhbmQgUHJv dG9jb2wtSW5kZXBlbmRlbnQgSW50ZXJuZXQgVHJhbnNwb3J0IEFQSSzigJ0gd2hpY2ggb2ZmZXJz DQphIGRlc2NyaXB0aW9uIG9mIHRoZSBwb2xpY3kgbWFuYWdlci4gPC9zcGFuPjwvZm9udD48L3By ZT48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogTWVubG8sIE1vbmFjbywgQ29uc29sYXMsICdDb3Vy aWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxM3B4OyB3aGl0ZS1zcGFjZTogcHJlLXdy YXA7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+PC9kaXY+PHByZSBjbGFzcz0id29yZHdyYXAiIHN0 eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBvdmVyZmxvdzogYXV0bzsgcGFkZGluZzogMHB4 OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDEwcHg7IGxpbmUtaGVpZ2h0OiAxLjQy ODU3MTQzOyB3b3JkLWJyZWFrOiBub3JtYWw7IHdvcmQtd3JhcDogbm9ybWFsOyBib3JkZXI6IDBw eCBub25lIGJsYWNrOyBib3JkZXItdG9wLWxlZnQtcmFkaXVzOiA0cHg7IGJvcmRlci10b3Atcmln aHQtcmFkaXVzOiA0cHg7IGJvcmRlci1ib3R0b20tcmlnaHQtcmFkaXVzOiA0cHg7IGJvcmRlci1i b3R0b20tbGVmdC1yYWRpdXM6IDRweDsiPjxmb250IGNvbG9yPSIjMDIwMjAyIiBmYWNlPSJNZW5s byIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIi PkFnYWluLCB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMhPC9zcGFuPjwvZm9udD48L3ByZT48cHJl IGNsYXNzPSJ3b3Jkd3JhcCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG92ZXJmbG93 OiBhdXRvOyBwYWRkaW5nOiAwcHg7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMTBw eDsgbGluZS1oZWlnaHQ6IDEuNDI4NTcxNDM7IHdvcmQtYnJlYWs6IG5vcm1hbDsgd29yZC13cmFw OiBub3JtYWw7IGJvcmRlcjogMHB4IG5vbmUgYmxhY2s7IGJvcmRlci10b3AtbGVmdC1yYWRpdXM6 IDRweDsgYm9yZGVyLXRvcC1yaWdodC1yYWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1yaWdodC1y YWRpdXM6IDRweDsgYm9yZGVyLWJvdHRvbS1sZWZ0LXJhZGl1czogNHB4OyI+PGZvbnQgY29sb3I9 IiMwMjAyMDIiIGZhY2U9Ik1lbmxvIiBjbGFzcz0iIj48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6 IHByZS13cmFwOyIgY2xhc3M9IiI+QmVzdCBSZWdhcmRzDQo8L3NwYW4+PC9mb250PjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyIgY2xhc3M9 IiI+S2FybC1Kb2hhbiBHcmlubmVtbzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IHdoaXRlLXNwYWNlOiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiIGNsYXNzPSIiPkxla3Rvci9T ZW5pb3IgTGVjdHVyZXI8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IHdoaXRlLXNwYWNlOiBub3JtYWw7IiBjbGFzcz0iIj5EYXRhdmV0ZW5za2FwL0Nv bXB1dGVyIFNjaWVuY2U8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IHdoaXRlLXNwYWNlOiBub3JtYWw7IiBjbGFzcz0iIj5LYXJsc3RhZHMgdW5pdmVy c2l0ZXQvS2FybHN0YWQgdW5pdmVyc2l0eTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IHdoaXRlLXNwYWNlOiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiIGNsYXNzPSIiPlRmbi46 L1Bob25lOiAmIzQzOzQ2ICgwKTU0IDcwMCAyNCA0MDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IHdoaXRlLXNwYWNlOiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiIGNsYXNzPSIi Pk1vYmlsOi9Nb2JpbGU6ICYjNDM7NDYgKDApNzA4IDc0MCA1MTE8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyIgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IHdoaXRlLXNwYWNlOiBub3JtYWw7IiBj bGFzcz0iIj5Ta3lwZToga2FybGdyaW48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyIgY2xhc3M9IiI+PC9wcmU+PGZvbnQgY29sb3I9 IiM1NTY0ZmYiIHN0eWxlPSJmb250LWZhbWlseTogTWVubG8sIE1vbmFjbywgQ29uc29sYXMsICdD b3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxM3B4OyB3aGl0ZS1zcGFjZTogcHJl LXdyYXA7IiBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpWYWliaGF2IEJh anBhaQ0KPGEgaHJlZj0iaHR0cDovL3d3dy52YWliaGF2YmFqcGFpLmNvbS8iIHJlbD0ibm9mb2xs b3ciIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBiYWNrZ3JvdW5kLWNvbG9yOiB0cmFu c3BhcmVudDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+d3d3LnZhaWJoYXZiYWpw YWkuY29tPC9hPg0KDQpQb3N0ZG9jdG9yYWwgUmVzZWFyY2hlcg0KVFUgTXVuaWNoLCBHZXJtYW55 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvZm9udD48L3ByZT4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8D51B0B38C204E269D65EA9E8156E1A3kause_-- From nobody Wed May 24 05:27:14 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2122D129B42; Wed, 24 May 2017 05:27:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149562882605.28455.8893882794444867038@ietfa.amsl.com> Date: Wed, 24 May 2017 05:27:06 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 12:27:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : On the Usage of Transport Features Provided by IETF Transport Protocols Authors : Michael Welzl Michael Tuexen Naeem Khademi Filename : draft-ietf-taps-transports-usage-05.txt Pages : 58 Date : 2017-05-24 Abstract: This document describes how the transport protocols Transmission Control Protocol (TCP), MultiPath TCP (MPTCP), Stream Control Transmission Protocol (SCTP), User Datagram Protocol (UDP) and Lightweight User Datagram Protocol (UDP-Lite) expose services to applications and how an application can configure and use the features that make up these services. It also discusses the service provided by the Low Extra Delay Background Transport (LEDBAT) congestion control mechanism. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-05 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-05 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 24 12:46:53 2017 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0BC127599; Wed, 24 May 2017 12:46:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149565521122.8685.2110584348826058841@ietfa.amsl.com> Date: Wed, 24 May 2017 12:46:51 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-udp-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 19:46:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols Authors : Godred Fairhurst Tom Jones Filename : draft-ietf-taps-transports-usage-udp-03.txt Pages : 19 Date : 2017-05-24 Abstract: This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. The resulting road map to documentation may be of help to users of the UDP and UDP-Lite protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-03 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transports-usage-udp-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-usage-udp-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 29 09:30:10 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94B7127735 for ; Mon, 29 May 2017 09:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC_0bk2mPJMC for ; Mon, 29 May 2017 09:30:06 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377CE126C26 for ; Mon, 29 May 2017 09:30:06 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id y201so51398872qka.0 for ; Mon, 29 May 2017 09:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=rwnsw8CsKyPiF5Q2r5blrI404BiPxgPhGJFZlj8FjBs=; b=HgKS9DlaXdHGYp7AaZDIThKPxkD7bp1t4YWjBKvzzwAI6+49wH6pYHz2ovnbkmmojA X2NHqS809+wE6+TDDAiRStH0Tv9mZbjfwU2llzm2aAlblXcVWdM//L5xV3IHzbaN6BDS fYZNjJzt8vrnYpNMvGK6VXzNNUWeAEddO8U13NUaiwwNWBzLhEiAg/P9luF1Xq1A7Ngt QkgvnBBKK97R2wXYh65pSF2F+WpdzMcayjYpdqnd/ymS0wXBiuF9th4uJizHCvke1Bg4 E2VitKoa6nMYT10RyzNdYj7c0p82VpnP3ogMgJMQ2JsapUD7L4VDNMxbLbKHs7/Dvf5c Bzbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=rwnsw8CsKyPiF5Q2r5blrI404BiPxgPhGJFZlj8FjBs=; b=AzmpCRRRuhJhqMyYSsiHM2blui48kpCdxbuBXnk5GI2ubKCebUpjpOfHMmKScU7GfV Kjv+V4vfsIUM3mXFqVjmQ23qcZ03jsgT1YgRtlthVYwhTg1hte38tSBrOZjkfP6brSwr JiIpSErnUHowhVUIEEAg6m2+SukugDKZ0xCeEsy3dtks1dpsyQvxRlOll+HvU2ZrThqs yVSCjM92Hom4sEgPMjnJEQlUTBsBlUhXXwR9gyQ6uvJBZxgE9KMMvWqT5VSScAFSzchM Wt1GuRX29aE7rFnWJGOsv6mP1eeIGcX9jZ1JWr4g4DwkfqCBbomoJdN3KO9wlpcXww0c 3i4A== X-Gm-Message-State: AODbwcCoVpECgwD9kS8Rf8Hc3Cs91txjH1ogqGuOeoIWEfzF0J7yfBHP BWzYCbVNOOtBRNkvxtc= X-Received: by 10.55.154.143 with SMTP id c137mr18984072qke.177.1496075405150; Mon, 29 May 2017 09:30:05 -0700 (PDT) Received: from [172.19.42.217] ([2601:184:4980:a321:fd63:511b:9788:599c]) by smtp.gmail.com with ESMTPSA id r24sm6478841qkh.0.2017.05.29.09.30.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 May 2017 09:30:04 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Mon, 29 May 2017 12:30:04 -0400 Message-ID: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4B74AAE7-88F9-41AF-BCF5-FAE84785590B_=" X-Mailer: MailMate (1.9.6r5356) Archived-At: Subject: [Taps] WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 16:30:08 -0000 --=_MailMate_4B74AAE7-88F9-41AF-BCF5-FAE84785590B_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable Dear TAPS working group: The authors have indicated the two drafts below are complete and are = ready for a final working group review. WGLC starts today and will be = three weeks, concluding June 19. Send comments, including an indication = that the docs are ready for publication, to the working group list. * [On the Usage of Transport Features Provided by IETF Transport = Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transport= s-usage-05.txt) * [Features of the User Datagram Protocol (UDP) and Lightweight UDP = (UDP- Lite) Transport = Protocols](https://www.ietf.org/internet-drafts/draft-ietf-taps-transport= s-usage-udp-03.txt) =E2=80=94aaron --=_MailMate_4B74AAE7-88F9-41AF-BCF5-FAE84785590B_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Dear TAPS working group:

The authors have indicated the two drafts below are compl= ete and are ready for a final working group review. WGLC starts today an= d will be three weeks, concluding June 19. Send comments, including an i= ndication that the docs are ready for publication, to the working group l= ist.

=E2=80=94aaron

--=_MailMate_4B74AAE7-88F9-41AF-BCF5-FAE84785590B_=-- From nobody Tue May 30 03:14:13 2017 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79962129BA5 for ; Tue, 30 May 2017 03:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ISp-v1jpnmU for ; Tue, 30 May 2017 03:14:10 -0700 (PDT) Received: from capri.iway.ch (capri.iway.ch [IPv6:2001:8e0:40:325::45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82CCB129BA4 for ; Tue, 30 May 2017 03:14:09 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D4C06340E89; Tue, 30 May 2017 12:14:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/7408.13853); Tue, 30 May 2017 12:14:07 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Tue, 30 May 2017 12:14:07 +0200 (CEST) Received: from [195.176.111.30] (account ietf@trammell.ch HELO public-docking-cx-1324.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 19101734; Tue, 30 May 2017 12:14:07 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4F4C42E7-612F-4134-9CD1-C1F47A94A1F5"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> Date: Tue, 30 May 2017 12:14:07 +0200 Cc: taps WG Message-Id: <70A5CB94-DBFD-4A09-80D2-5B944F01F1C8@trammell.ch> References: <408986B2-B86B-4C7D-9E91-D554029579FA@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Taps] WGLC start for -transports-usage- docs X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 10:14:12 -0000 --Apple-Mail=_4F4C42E7-612F-4134-9CD1-C1F47A94A1F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Aaron, all, I've read these, and IMO they're ready for publication. Many thanks to = the authors for the impressive amount of work that went into them! Cheers, Brian > On 29 May 2017, at 18:30, Aaron Falk wrote: >=20 > Dear TAPS working group: >=20 > The authors have indicated the two drafts below are complete and are = ready for a final working group review. WGLC starts today and will be = three weeks, concluding June 19. Send comments, including an indication = that the docs are ready for publication, to the working group list. >=20 > =E2=80=A2 On the Usage of Transport Features Provided by IETF = Transport Protocols > =E2=80=A2 Features of the User Datagram Protocol (UDP) and = Lightweight UDP (UDP- Lite) Transport Protocols > =E2=80=94aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_4F4C42E7-612F-4134-9CD1-C1F47A94A1F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZLUXvAAoJEIoSt78L6kajXeIP/RF9wGUkh3XIwifxCzzWK0Eg Kg9LTlDf78VGQz4PG03J5QS5+drZAqLrQ05EiwpbkuSN6W7n6wVB2B8VzmeREgrG sk0ID2I7nNQtpd8qvf/fuBeMmatIJJw8UBVIaVVd70Z8VdyDXiSMoK0CEIPNHiq+ mjhxSA1UpDvtQiDDN2bNKF1PmuRbq3nOQXwGpi1g/4QrY9gSgYm94JXwqRoKlnx9 kYLat9CDoNpWC7Hkwzui+FYIAi9xfxK9Dg+ZNePC9uZnVbTzL3/5DFZh+OOcRLTO 6EMmItrrgpns32AHJB80emkS9hIh7LkMX9yzjgb0wQkZLptdAg1mPevT4YcJlI7P SD//ag+jmE1OGNdBoWZ49Uj0C8yWvMo3I864l7Rq2b3QgThfHXH3/pVUwo7Y9RM/ kc0KZw3CWrT3ronYoKda9HOZwOi6xaNHXSRYmzULh0OXAnHj5bvWdpoCTvE5BlvB eJEC3DpsnqyW8AY1TObO//tGh0gil2+a7TDzt7wsTG3qLXcBSQiRjzy/aFUvD2ej /fuOLUr+6NAtIOnhBexxhMJCmq69GB6AYs+rnM0LPdYOnKPUyjB/enmuTYBeMb/3 jQpG/kixAn3cVnDWA4ws+7LIWCFrY3d/LiCBu3DeR9Wwjg2NB1QUAj/LndCw1bF0 V5147S8fiZc/eeXD8j9n =ht5+ -----END PGP SIGNATURE----- --Apple-Mail=_4F4C42E7-612F-4134-9CD1-C1F47A94A1F5--