From nobody Thu Dec 1 05:27:41 2016 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 6FDCB1296CF; Thu, 1 Dec 2016 05:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 8fT-EitOMCA4; Thu, 1 Dec 2016 05:27:34 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 25F621296FD; Thu, 1 Dec 2016 05:27:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9FC872CCAE; Thu, 1 Dec 2016 15:27:05 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VwzgC71rFGJ; Thu, 1 Dec 2016 15:27:05 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 388752CC95; Thu, 1 Dec 2016 15:27:05 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_077B8BF5-BD02-4606-B0EA-35F7A0ED01F8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <431806df-63fe-c45c-5b26-c2e79394e6ad@nostrum.com> Date: Thu, 1 Dec 2016 15:27:03 +0200 Message-Id: References: <2622b864-acce-d442-ab1a-4cc5808868d3@nostrum.com> <431806df-63fe-c45c-5b26-c2e79394e6ad@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: General Area Review Team , draft-ietf-taps-transports.all@ietf.org, taps@ietf.org Subject: Re: [Taps] [Gen-art] Gen-art LC review: draft-ietf-taps-transports-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 13:27:36 -0000 --Apple-Mail=_077B8BF5-BD02-4606-B0EA-35F7A0ED01F8 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 Thanks for the review, Robert. Jari --Apple-Mail=_077B8BF5-BD02-4606-B0EA-35F7A0ED01F8 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 iQIcBAEBCgAGBQJYQCUoAAoJEM80gCTQU46q0iYP/3FgN3GYGA3f6+IfE7mQlMgp iuxWNgQ2ShMLSxV5JOuear1MowGML5N4FePDz7S6u3Xe/s/SQQ/CJR+HWYHUjTS5 9Re/Kkd2gG2kpdzoLIIq+ZpAbQx9VIU+bkT2l2LrMEb9rPFDlSwk853DMo0IEGau UQAnP8lAfhhrCfg1dj/FG/gPqeEYgXRKwNeGojsVx2wXq5Lwss/CPTUMpEOVxqyp rT2GhXddA3qKryY25t0Cc3yIw3Kh3XlCKltVFcThJqvVa1dAIoCkyanXQI70GzmQ r2oJXa4+fncs3zQwGta8B8X7R5ZyGynWvyit8Dszmz9NKMlh5Am+YeI3dbRTddUw GBW1WbIQZLH7xOEDZd/D8s0PN1Q51TWakZzuh+I+vQ5k7mkwIwRL1HIUBEsV9Ac6 2OfeXWVtr6W5E9uH2w0hNbgh+IdWtANjSqGUXfGfLf3JdoU1OGwJtLL4DONTyaiX AhDkX/MLqNGjJXXHgUtDUMVqx4SltHPLhtDpO2qAiV67osZx+8MoWrz7lAJyEm9L PHE3n4WIQOLGm0Kp/VnKvsBwJR/DKPi9MvYnyqPNvzO5jOV3ubYw1lZLof5pfPox PuptrpYUvJw8ACxeMpT40lUq7Ur6PTgeWrhjwbUlowQWSzY1cN4x3iu8kl/6BDdY 56gmxTkAhjzUkGGSvu12 =E3nO -----END PGP SIGNATURE----- --Apple-Mail=_077B8BF5-BD02-4606-B0EA-35F7A0ED01F8-- From nobody Mon Dec 5 08:10:40 2016 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 3B7CA129B43; Mon, 5 Dec 2016 08:10:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148095423924.3378.11116291321620506538.idtracker@ietfa.amsl.com> Date: Mon, 05 Dec 2016 08:10:39 -0800 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-13.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 16:10:39 -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 : Services provided by IETF transport protocols and congestion control mechanisms Authors : Godred Fairhurst Brian Trammell Mirja Kuehlewind Filename : draft-ietf-taps-transports-13.txt Pages : 53 Date : 2016-12-05 Abstract: This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/ Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-13 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 Dec 6 07:16:13 2016 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 E28BA129487; Tue, 6 Dec 2016 07:16:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148103736792.1888.10436304250944998928.idtracker@ietfa.amsl.com> Date: Tue, 06 Dec 2016 07:16:07 -0800 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-14.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 15:16:08 -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 : Services provided by IETF transport protocols and congestion control mechanisms Authors : Godred Fairhurst Brian Trammell Mirja Kuehlewind Filename : draft-ietf-taps-transports-14.txt Pages : 53 Date : 2016-12-06 Abstract: This document describes, surveys, and classifies the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. It examines the Transmission Control Protocol (TCP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Datagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP), the Internet Control Message Protocol (ICMP), the Realtime Transport Protocol (RTP), File Delivery over Unidirectional Transport/ Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC), and NACK- Oriented Reliable Multicast (NORM), Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides background for the definition of transport services within the TAPS working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-14 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 Dec 7 06:54:38 2016 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 CFEBE129A26 for ; Wed, 7 Dec 2016 06:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 7fNjKSLm2s1F for ; Wed, 7 Dec 2016 06:54:34 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 066DE1294D6 for ; Wed, 7 Dec 2016 06:54:34 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1cEdc8-0006zn-8U for taps@ietf.org; Wed, 07 Dec 2016 15:54:32 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cEdc7-0004Fs-PR for taps@ietf.org; Wed, 07 Dec 2016 15:54:32 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> Date: Wed, 7 Dec 2016 15:54:31 +0100 To: taps WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 5 sum rcpts/h 16 sum msgs/h 6 total rcpts 49704 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.643, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 87A2D593F02C92DFE86AD89D049FD7913C6691A5 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 11791 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 14:54:36 -0000 Hi all, I have a problem with one particular primitive, or lack of it, in UDP, = UDP-Lite and SCTP. It's something I just don't get. Consider this text from draft-fairhurst-taps-transports-usage-udp: "GET_INTERFACE_MTU: The GET_INTERFACE_MTU function a network-layer function that indicates the largest unfragmented IP packet that may be sent." Indeed, this is a network-layer function. It's about the interface, not = about UDP. Does that mean that, to decide how many bytes fit in the = payload of a packet, the programmer needs to know if it's IPv4 or IPv6, = with or without options, and do the calculation? If so, isn't it extremely odd that UDP doesn't offer a primitive that = provides a more useful number: the available space in its payload, in = bytes? I also have the same question for SCTP. For TCP, it's obvious that the = application shouldn't bother, but not for UDP or SCTP. At the last meeting, knowing the MTU was mentioned as one of the needs = that latency-critical protocols have. I understand that - but I didn't = include this primitive in the last version of the usage draft because it = is a network-layer primitive... now I don't know how to approach this. Thoughts? Suggestions? Cheers, Michael From nobody Wed Dec 7 06:56:05 2016 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 00F9E129462 for ; Wed, 7 Dec 2016 06:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=unavailable 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 EBHvWZmJb59B for ; Wed, 7 Dec 2016 06:56:01 -0800 (PST) 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 2DFCA12711D for ; Wed, 7 Dec 2016 06:46:18 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cEdU7-0005Zp-RK for taps@ietf.org; Wed, 07 Dec 2016 15:46:15 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cEdU7-0001Gj-Cj; Wed, 07 Dec 2016 15:46:15 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7812D0DE-EC15-4B19-8C03-6D5A052CA971@ifi.uio.no> Date: Wed, 7 Dec 2016 15:46:15 +0100 To: taps WG , tcpm IETF list Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 15 sum msgs/h 5 total rcpts 49703 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.643, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B9B3C4B5CE926AAEF5399371213B2A4C9E4C0206 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 11790 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] Experimental TCP RFCs affecting the API? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 14:56:03 -0000 Hi, As I'm working on an update of draft-ietf-taps-transports-usage to also = incorporate Experimental TCP RFCs, I wonder which of them had an impact = on the API - I mean any form of text describing how applications use the = protocol. Clearly, TFO is such a case (RFC 7413). Any others? Thanks in advance! Cheers, Michael From nobody Wed Dec 7 08:25:25 2016 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 D622D12950B for ; Wed, 7 Dec 2016 08:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 GNyRkNspgGOk for ; Wed, 7 Dec 2016 08:25:21 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 46EB7129F6B for ; Wed, 7 Dec 2016 08:24:51 -0800 (PST) Received: from dhcp-207-163.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:cb5:2a3f:f95e:4536]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9A7BB1B001AA; Wed, 7 Dec 2016 18:22:58 +0000 (GMT) References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> To: Michael Welzl , taps WG From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Wed, 7 Dec 2016 16:24:46 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 16:25:24 -0000 Not quoite answering this question, but for DCCP this is clearly also a transport understanding of the maxmium datagram size, as in RFC 4340: "A DCCP implementation MUST maintain the maximum packet size (MPS) allowed for each active DCCP session." and "The MPS reported to the application SHOULD be influenced by the size expected to be required for DCCP headers and options." Gorry On 07/12/2016 14:54, Michael Welzl wrote: > Hi all, > > I have a problem with one particular primitive, or lack of it, in UDP, UDP-Lite and SCTP. It's something I just don't get. > > Consider this text from draft-fairhurst-taps-transports-usage-udp: > > "GET_INTERFACE_MTU: The GET_INTERFACE_MTU function a network-layer > function that indicates the largest unfragmented IP packet that > may be sent." > > Indeed, this is a network-layer function. It's about the interface, not about UDP. Does that mean that, to decide how many bytes fit in the payload of a packet, the programmer needs to know if it's IPv4 or IPv6, with or without options, and do the calculation? > If so, isn't it extremely odd that UDP doesn't offer a primitive that provides a more useful number: the available space in its payload, in bytes? > > I also have the same question for SCTP. For TCP, it's obvious that the application shouldn't bother, but not for UDP or SCTP. > At the last meeting, knowing the MTU was mentioned as one of the needs that latency-critical protocols have. I understand that - but I didn't include this primitive in the last version of the usage draft because it is a network-layer primitive... now I don't know how to approach this. > > Thoughts? Suggestions? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed Dec 7 11:30:32 2016 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 90FE7129A5E for ; Wed, 7 Dec 2016 11:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 nP1rmuGjogo4 for ; Wed, 7 Dec 2016 11:30:24 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 AA7C5129A64 for ; Wed, 7 Dec 2016 11:30:17 -0800 (PST) Received: from [128.9.184.157] ([128.9.184.157]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uB7JToli028617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 7 Dec 2016 11:29:50 -0800 (PST) To: Michael Welzl , taps WG References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> From: Joe Touch Message-ID: Date: Wed, 7 Dec 2016 11:29:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 19:30:30 -0000 FYI, there are two different "largest messages" at the transport layer: 1) the size of the message that CAN be delivered at all 2) the size of the message that can be delivered without network-layer fragmentation (there are no guarantees about link-layer - see ATM or the recent discussion on tunnel MTUs on INTAREA) MTU generally refers to the *link payload*. At that point, transports have to account for network headers, network options, transport headers, and transport options too. See RFC6691. MSS refers to the transport message size AFAICT. It is *sometimes* tuned to MTU-headers but not always. E.g., for IPv6, link MTU is required to be at least 1280, but the src-dst transit MTU is required to be at least 1500. So a transport that wants to match sizes and reduce fragmentation issues would pick 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. Joe On 12/7/2016 6:54 AM, Michael Welzl wrote: > Hi all, > > I have a problem with one particular primitive, or lack of it, in UDP, UDP-Lite and SCTP. It's something I just don't get. > > Consider this text from draft-fairhurst-taps-transports-usage-udp: > > "GET_INTERFACE_MTU: The GET_INTERFACE_MTU function a network-layer > function that indicates the largest unfragmented IP packet that > may be sent." > > Indeed, this is a network-layer function. It's about the interface, not about UDP. Does that mean that, to decide how many bytes fit in the payload of a packet, the programmer needs to know if it's IPv4 or IPv6, with or without options, and do the calculation? > If so, isn't it extremely odd that UDP doesn't offer a primitive that provides a more useful number: the available space in its payload, in bytes? > > I also have the same question for SCTP. For TCP, it's obvious that the application shouldn't bother, but not for UDP or SCTP. > At the last meeting, knowing the MTU was mentioned as one of the needs that latency-critical protocols have. I understand that - but I didn't include this primitive in the last version of the usage draft because it is a network-layer primitive... now I don't know how to approach this. > > Thoughts? Suggestions? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 9 00:09:55 2016 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 E2135129C92 for ; Fri, 9 Dec 2016 00:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 aMPS53NWUkKo for ; Fri, 9 Dec 2016 00:09:50 -0800 (PST) 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 4CF4D12A11B for ; Fri, 9 Dec 2016 00:09:50 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cFGFX-000FYl-Hj for taps@ietf.org; Fri, 09 Dec 2016 09:09:47 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cFGFX-0001BM-4M; Fri, 09 Dec 2016 09:09:47 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Fri, 9 Dec 2016 09:09:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> To: Joe Touch X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 9 sum msgs/h 4 total rcpts 49739 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.643, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DF99E76FE50F96916F366C43852B12E0F2055457 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 11794 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 08:09:53 -0000 > On 07 Dec 2016, at 20:29, Joe Touch wrote: >=20 > FYI, there are two different "largest messages" at the transport = layer: >=20 > 1) the size of the message that CAN be delivered at all True... I wasn't thinking of that, but yes. > 2) the size of the message that can be delivered without network-layer > fragmentation (there are no guarantees about link-layer - see ATM or = the > recent discussion on tunnel MTUs on INTAREA) >=20 > MTU generally refers to the *link payload*. At that point, transports > have to account for network headers, network options, transport = headers, > and transport options too. See RFC6691. >=20 > MSS refers to the transport message size AFAICT. It is *sometimes* = tuned > to MTU-headers but not always. >=20 > E.g., for IPv6, link MTU is required to be at least 1280, but the > src-dst transit MTU is required to be at least 1500. So a transport = that > wants to match sizes and reduce fragmentation issues would pick > 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to = trust > that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the = time. So I'm getting the impression that the answer to my question really is = that, to figure out 2) (which I was concerned with), an application = programmer needs to do the calculation her/himself. Not a big deal - and maybe some systems offer a function to give you the = size of a message that won't be fragmented. However: this calculation is transport protocol dependent, which we = really don't want to have in TAPS. I conclude: a TAPS system must implement a local function to provide = this information, both 1) and 2) above. Cheers, Michael From nobody Fri Dec 9 00:47:19 2016 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 733F112A234 for ; Fri, 9 Dec 2016 00:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 4Tsd6SFrWgn6 for ; Fri, 9 Dec 2016 00:47:10 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E292112A222 for ; Fri, 9 Dec 2016 00:47:06 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 923D41B001E4 for ; Fri, 9 Dec 2016 10:44:52 +0000 (GMT) Message-ID: <584A6F71.7020301@erg.abdn.ac.uk> Date: Fri, 09 Dec 2016 08:46:41 +0000 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: taps@ietf.org References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> In-Reply-To: <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 08:47:18 -0000 On 09/12/2016 08:09, Michael Welzl wrote: >> On 07 Dec 2016, at 20:29, Joe Touch wrote: >> >> FYI, there are two different "largest messages" at the transport layer: >> >> 1) the size of the message that CAN be delivered at all > True... I wasn't thinking of that, but yes. > > >> 2) the size of the message that can be delivered without network-layer >> fragmentation (there are no guarantees about link-layer - see ATM or the >> recent discussion on tunnel MTUs on INTAREA) >> >> MTU generally refers to the *link payload*. At that point, transports >> have to account for network headers, network options, transport headers, >> and transport options too. See RFC6691. >> >> MSS refers to the transport message size AFAICT. It is *sometimes* tuned >> to MTU-headers but not always. >> >> E.g., for IPv6, link MTU is required to be at least 1280, but the >> src-dst transit MTU is required to be at least 1500. So a transport that >> wants to match sizes and reduce fragmentation issues would pick >> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust >> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. > So I'm getting the impression that the answer to my question really is that, to figure out 2) (which I was concerned with), an application programmer needs to do the calculation her/himself. > Not a big deal - and maybe some systems offer a function to give you the size of a message that won't be fragmented. > > However: this calculation is transport protocol dependent, which we really don't want to have in TAPS. > > I conclude: a TAPS system must implement a local function to provide this information, both 1) and 2) above. Referning back to DCCP as a RFC reference which agrees with this. I agree with (2) for a datagram transport, similar to MPS in DCCP. If you are going to allow different transports to be selected by TAPS - it's hard to know even if the transport below the TAPS API will finally need to choose to add an option to satisfy the service (e.g., timestamp, checksum, whatever ) and the size of such an option likely varies depending on the finally chosen protocol. To me, this suggests it useful to know how many bytes the app can send with reasonable chance of unfragmented delivery. Apps should be allowed to send more if they wish, If an app is doing datagram path MTU discovery, this may resilt in raising the maximum unfragmented datagram size. I'm OK with being able to retrieve the absolute maximum allowed - that could be useful in determinine probe sizes for an application doing path MTU discovery. In DCCP there is a hard limt, called the current congestion control maximum packet size (CCMPS), the largest permitted by the stack using the current congestion control method. That's bound to be less than or equal to what is permittd for the local Interface MTU. Gorry > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 9 00:56:37 2016 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 D0B1612A25A for ; Fri, 9 Dec 2016 00:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 d0DamnrBjmVT for ; Fri, 9 Dec 2016 00:56:34 -0800 (PST) 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 DCAD112A23F for ; Fri, 9 Dec 2016 00:56:33 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cFGym-0004fy-2k for taps@ietf.org; Fri, 09 Dec 2016 09:56:32 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cFGyl-00022U-GT; Fri, 09 Dec 2016 09:56:31 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <584A6F71.7020301@erg.abdn.ac.uk> Date: Fri, 9 Dec 2016 09:56:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <584A6F71.7020301@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 36 msgs/h 16 sum rcpts/h 38 sum msgs/h 17 total rcpts 49768 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.643, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 292A66327FBD865C8E22D9216ADFF34CE4686E0D X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 15 total 11806 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 08:56:36 -0000 > On 09 Dec 2016, at 09:46, Gorry Fairhurst = wrote: >=20 > On 09/12/2016 08:09, Michael Welzl wrote: >>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>>=20 >>> FYI, there are two different "largest messages" at the transport = layer: >>>=20 >>> 1) the size of the message that CAN be delivered at all >> True... I wasn't thinking of that, but yes. >>=20 >>=20 >>> 2) the size of the message that can be delivered without = network-layer >>> fragmentation (there are no guarantees about link-layer - see ATM or = the >>> recent discussion on tunnel MTUs on INTAREA) >>>=20 >>> MTU generally refers to the *link payload*. At that point, = transports >>> have to account for network headers, network options, transport = headers, >>> and transport options too. See RFC6691. >>>=20 >>> MSS refers to the transport message size AFAICT. It is *sometimes* = tuned >>> to MTU-headers but not always. >>>=20 >>> E.g., for IPv6, link MTU is required to be at least 1280, but the >>> src-dst transit MTU is required to be at least 1500. So a transport = that >>> wants to match sizes and reduce fragmentation issues would pick >>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to = trust >>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of = the time. >> So I'm getting the impression that the answer to my question really = is that, to figure out 2) (which I was concerned with), an application = programmer needs to do the calculation her/himself. >> Not a big deal - and maybe some systems offer a function to give you = the size of a message that won't be fragmented. >>=20 >> However: this calculation is transport protocol dependent, which we = really don't want to have in TAPS. >>=20 >> I conclude: a TAPS system must implement a local function to provide = this information, both 1) and 2) above. > Referning back to DCCP as a RFC reference which agrees with this. >=20 > I agree with (2) for a datagram transport, similar to MPS in DCCP. If = you are going to allow different transports to be selected by TAPS - = it's hard to know even if the transport below the TAPS API will finally = need to choose to add an option to satisfy the service (e.g., timestamp, = checksum, whatever ) and the size of such an option likely varies = depending on the finally chosen protocol. To me, this suggests it useful = to know how many bytes the app can send with reasonable chance of = unfragmented delivery. >=20 > Apps should be allowed to send more if they wish, If an app is doing = datagram path MTU discovery, this may resilt in raising the maximum = unfragmented datagram size. >=20 > I'm OK with being able to retrieve the absolute maximum allowed - that = could be useful in determinine probe sizes for an application doing path = MTU discovery. In DCCP there is a hard limt, called the current = congestion control maximum packet size (CCMPS), the largest permitted by = the stack using the current congestion control method. That's bound to = be less than or equal to what is permittd for the local Interface MTU. >=20 > Gorry I agree with all that. But combining this with the wish to have message dependencies, a wish = that is in both draft-trammell-post-sockets and = draft-mcquistin-taps-low-latency-services, yet also not supported by any = of the already defined transport protocols, it gets clear that we must = define some extra functionality for a TAPS system, when we get to = charter item 3. These things can be achieved by only changing the implementation of = transports to locally provide some more of its internal information to a = system on top; they don't change anything on the wire... Cheers, Michael From nobody Fri Dec 9 07:18:43 2016 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 E770B129458 for ; Fri, 9 Dec 2016 07:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 v1lV5tSzQpd6 for ; Fri, 9 Dec 2016 07:18:34 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 8BBC2129460 for ; Fri, 9 Dec 2016 07:18:34 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uB9FI3Bp025957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Dec 2016 07:18:04 -0800 (PST) To: Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> From: Joe Touch Message-ID: <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> Date: Fri, 9 Dec 2016 07:18:01 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:18:41 -0000 On 12/9/2016 12:09 AM, Michael Welzl wrote: >> On 07 Dec 2016, at 20:29, Joe Touch wrote: >> >> FYI, there are two different "largest messages" at the transport layer: >> >> 1) the size of the message that CAN be delivered at all > True... I wasn't thinking of that, but yes. > > >> 2) the size of the message that can be delivered without network-layer >> fragmentation (there are no guarantees about link-layer - see ATM or the >> recent discussion on tunnel MTUs on INTAREA) >> >> MTU generally refers to the *link payload*. At that point, transports >> have to account for network headers, network options, transport headers, >> and transport options too. See RFC6691. >> >> MSS refers to the transport message size AFAICT. It is *sometimes* tuned >> to MTU-headers but not always. >> >> E.g., for IPv6, link MTU is required to be at least 1280, but the >> src-dst transit MTU is required to be at least 1500. So a transport that >> wants to match sizes and reduce fragmentation issues would pick >> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust >> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. > So I'm getting the impression that the answer to my question really is that, to figure out 2) (which I was concerned with), an application programmer needs to do the calculation her/himself. To figure out 2), the transport layer needs to know the unfragmented link MTU, the size of all of the network headers (including options), and the sizes of its own headers and options. It's also sometimes assumes that the transport can control the "DF" bit (for IPv4). However, this all breaks down if the app makes the wrong choice because the net can (will, and should) source fragment if it gets a message that turns out to be too big for one fragment anyway. > Not a big deal - and maybe some systems offer a function to give you the size of a message that won't be fragmented. Remember that - at best - you're optimizing for the next layer down only. You can't know whether that net layer message is link fragmented (e.g., as in ATM) or tunnel fragmented (as needs to be required or this whole MTU concept breaks down). > > However: this calculation is transport protocol dependent, which we really don't want to have in TAPS. If you want to fix this, you need to change the API to the net layer to provide immediate feedback. When transport hands a segment to network, it has to get a "call failed" if the message is too big - and we really do need transport layers to be able to pick between "too big for non-fragmented net layer" and "too big for the net layer even with frag". Merely handing info to the transport layer might not be enough, esp. when net layer option lengths change. Joe From nobody Fri Dec 9 08:00:45 2016 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 699681298A0; Fri, 9 Dec 2016 08:00:27 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148129922742.4581.9202503584691065373.idtracker@ietfa.amsl.com> Date: Fri, 09 Dec 2016 08:00:27 -0800 Archived-At: Cc: Aaron Falk , draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, The IESG , taps@ietf.org, rfc-editor@rfc-editor.org Subject: [Taps] Document Action: 'Services provided by IETF transport protocols and congestion control mechanisms' to Informational RFC (draft-ietf-taps-transports-14.txt) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:00:27 -0000 The IESG has approved the following document: - 'Services provided by IETF transport protocols and congestion control mechanisms' (draft-ietf-taps-transports-14.txt) as Informational RFC This document is the product of the Transport Services Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ Technical Summary This document describes, surveys, classifies and compares the protocol mechanisms provided by existing IETF protocols, as background for determining a common set of transport services. Protocols addressed include TCP, SCTP, UDP, UDP-Lite, DCCP, ICMP, RTP, FLUTE/ALC, NORM, TLS, DTLS, and HTTP when used as a pseudotransport. It captures important analysis needed for the TAPS working group goal of developing an abstract API enabling applications to make use of modern transports with the help of TAPS mechanisms, for example to probe and verify end-to-end protocol transparency. This is a useful first step by the TAPS working group to proposing future abstractions and mechanisms. Working Group Summary All the protocols referenced in this document are products of the IETF. The goal here is to introduce consisten terminology and pull together a common view of a number of well-known protocols. The working group struggled early on in finding the right level of abstraction but was able to achieve consensus on the approach contained in the doc. Each protocol section had one or two active authors who are experts in their section and went through multiple revisions. The result is that about a dozen contributors have provided text so the engagement was high, compared to the active mailing list members. A few objections have been raised about whether the overall effort will be useful but the contents of this draft have not been controversial. The working group held a last call that spanned an IETF meeting with a number of cleanup tasks identified. Some new introductory text and restructuring on the doc was introduced and a second, online last call, produced no comments. It is the opinion of the shepherd that the document is ready for publication. Document Quality The document looks fine (to the AD). This is a survey of existing transport protocols, so the usual questions about implementations, etc. don't apply in this case. Personnel The document shepherd is Aaron Falk. The responsible Area Director is Spencer Dawkins. From nobody Fri Dec 9 08:12:45 2016 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 06D4D129486 for ; Fri, 9 Dec 2016 08:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 H7RYtux2Mkmp for ; Fri, 9 Dec 2016 08:12:39 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (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 20793129484 for ; Fri, 9 Dec 2016 08:12:39 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1cFNmn-000339-Ao for taps@ietf.org; Fri, 09 Dec 2016 17:12:37 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cFNmm-0001zV-P2; Fri, 09 Dec 2016 17:12:37 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> Date: Fri, 9 Dec 2016 17:12:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 9 sum msgs/h 5 total rcpts 49839 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.643, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7F122750B0C396DE1E765856E2B20C702E65962B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 11845 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 16:12:42 -0000 > On 09 Dec 2016, at 16:18, Joe Touch wrote: >=20 >=20 >=20 > On 12/9/2016 12:09 AM, Michael Welzl wrote: >>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>>=20 >>> FYI, there are two different "largest messages" at the transport = layer: >>>=20 >>> 1) the size of the message that CAN be delivered at all >> True... I wasn't thinking of that, but yes. >>=20 >>=20 >>> 2) the size of the message that can be delivered without = network-layer >>> fragmentation (there are no guarantees about link-layer - see ATM or = the >>> recent discussion on tunnel MTUs on INTAREA) >>>=20 >>> MTU generally refers to the *link payload*. At that point, = transports >>> have to account for network headers, network options, transport = headers, >>> and transport options too. See RFC6691. >>>=20 >>> MSS refers to the transport message size AFAICT. It is *sometimes* = tuned >>> to MTU-headers but not always. >>>=20 >>> E.g., for IPv6, link MTU is required to be at least 1280, but the >>> src-dst transit MTU is required to be at least 1500. So a transport = that >>> wants to match sizes and reduce fragmentation issues would pick >>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to = trust >>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of = the time. >> So I'm getting the impression that the answer to my question really = is that, to figure out 2) (which I was concerned with), an application = programmer needs to do the calculation her/himself. >=20 > To figure out 2), the transport layer needs to know the unfragmented > link MTU, the size of all of the network headers (including options), > and the sizes of its own headers and options. >=20 > It's also sometimes assumes that the transport can control the "DF" = bit > (for IPv4). Yes - but that hardly sounds worse to me than requiring the application = programmer to do this protocol-specific calculation by hand... > However, this all breaks down if the app makes the wrong choice = because > the net can (will, and should) source fragment if it gets a message = that > turns out to be too big for one fragment anyway. >=20 >> Not a big deal - and maybe some systems offer a function to give you = the size of a message that won't be fragmented. >=20 > Remember that - at best - you're optimizing for the next layer down > only. You can't know whether that net layer message is link fragmented > (e.g., as in ATM) or tunnel fragmented (as needs to be required or = this > whole MTU concept breaks down). Sure - but that's something end systems just can't see. It's information = up to and including the IP layer that should be correctly handed over up = the stack, inside the host, with all the caveats this information comes = with. >> However: this calculation is transport protocol dependent, which we = really don't want to have in TAPS. >=20 > If you want to fix this, you need to change the API to the net layer = to > provide immediate feedback. When transport hands a segment to network, > it has to get a "call failed" if the message is too big - and we = really > do need transport layers to be able to pick between "too big for > non-fragmented net layer" and "too big for the net layer even with = frag". >=20 > Merely handing info to the transport layer might not be enough, esp. > when net layer option lengths change. True if you want to cleanly fix it across the RFC-specified stack, but = that's beyond the concern of TAPS - it becomes a requirement from the = TAPS WG. Does that make sense? Cheers, Michael From nobody Fri Dec 9 09:33:18 2016 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 55F231295AC for ; Fri, 9 Dec 2016 09:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 6NlKUArZ_r61 for ; Fri, 9 Dec 2016 09:33:14 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 ABB7F1299A2 for ; Fri, 9 Dec 2016 09:32:58 -0800 (PST) Received: from [128.9.184.112] ([128.9.184.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uB9HWEWT017428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Dec 2016 09:32:15 -0800 (PST) To: Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> From: Joe Touch Message-ID: <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> Date: Fri, 9 Dec 2016 09:32:12 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 17:33:16 -0000 On 12/9/2016 8:12 AM, Michael Welzl wrote: >> On 09 Dec 2016, at 16:18, Joe Touch wrote: >> >> >> >> On 12/9/2016 12:09 AM, Michael Welzl wrote: >>>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>>> >>>> FYI, there are two different "largest messages" at the transport layer: >>>> >>>> 1) the size of the message that CAN be delivered at all >>> True... I wasn't thinking of that, but yes. >>> >>> >>>> 2) the size of the message that can be delivered without network-layer >>>> fragmentation (there are no guarantees about link-layer - see ATM or the >>>> recent discussion on tunnel MTUs on INTAREA) >>>> >>>> MTU generally refers to the *link payload*. At that point, transports >>>> have to account for network headers, network options, transport headers, >>>> and transport options too. See RFC6691. >>>> >>>> MSS refers to the transport message size AFAICT. It is *sometimes* tuned >>>> to MTU-headers but not always. >>>> >>>> E.g., for IPv6, link MTU is required to be at least 1280, but the >>>> src-dst transit MTU is required to be at least 1500. So a transport that >>>> wants to match sizes and reduce fragmentation issues would pick >>>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust >>>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. >>> So I'm getting the impression that the answer to my question really is that, to figure out 2) (which I was concerned with), an application programmer needs to do the calculation her/himself. >> To figure out 2), the transport layer needs to know the unfragmented >> link MTU, the size of all of the network headers (including options), >> and the sizes of its own headers and options. >> >> It's also sometimes assumes that the transport can control the "DF" bit >> (for IPv4). > Yes - but that hardly sounds worse to me than requiring the application programmer to do this protocol-specific calculation by hand... The app programmer needs to know what the transport can support, the transport needs to know what net supports, etc. Pushing the link MTU up the line and expecting all the other layers to figure out what to do results in unnecessary complexity, never mind undermining one of the key features of layering. > >> However, this all breaks down if the app makes the wrong choice because >> the net can (will, and should) source fragment if it gets a message that >> turns out to be too big for one fragment anyway. >> >>> Not a big deal - and maybe some systems offer a function to give you the size of a message that won't be fragmented. >> Remember that - at best - you're optimizing for the next layer down >> only. You can't know whether that net layer message is link fragmented >> (e.g., as in ATM) or tunnel fragmented (as needs to be required or this >> whole MTU concept breaks down). > Sure - but that's something end systems just can't see. It's information up to and including the IP layer that should be correctly handed over up the stack, inside the host, with all the caveats this information comes with. Why does that apply at the link layer but not other layers? If transport can transfer and reassemble 1MB messages, then that's the "MTU" it needs to tell the app layer. The same is true for net to tell transport, etc. We've conflated the two between transport and net unnecessarily. > >>> However: this calculation is transport protocol dependent, which we really don't want to have in TAPS. >> If you want to fix this, you need to change the API to the net layer to >> provide immediate feedback. When transport hands a segment to network, >> it has to get a "call failed" if the message is too big - and we really >> do need transport layers to be able to pick between "too big for >> non-fragmented net layer" and "too big for the net layer even with frag". >> >> Merely handing info to the transport layer might not be enough, esp. >> when net layer option lengths change. > True if you want to cleanly fix it across the RFC-specified stack, but that's beyond the concern of TAPS - it becomes a requirement from the TAPS WG. Does that make sense? Then this is part of the API requirements that TAPS should be indicating, no? Joe From nobody Fri Dec 9 10:53:27 2016 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 346F0129483 for ; Fri, 9 Dec 2016 10:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 j89xTowi-Bjf for ; Fri, 9 Dec 2016 10:53:23 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 DFC56127A90 for ; Fri, 9 Dec 2016 10:53:23 -0800 (PST) Received: from [128.9.184.112] ([128.9.184.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uB9Iq9cs000159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Dec 2016 10:52:10 -0800 (PST) To: Michael Welzl , " Fairhurst" References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <584A6F71.7020301@erg.abdn.ac.uk> From: Joe Touch Message-ID: <2a2a4b20-fd76-8bbc-ce4c-7e87bf588481@isi.edu> Date: Fri, 9 Dec 2016 10:52:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 18:53:25 -0000 On 12/9/2016 12:56 AM, Michael Welzl wrote: > These things can be achieved by only changing the implementation of transports to locally provide some more of its internal information to a system on top; they don't change anything on the wire... FWIW, we really need to stop using that phrase ("on the wire"). A protocol is defined by: - it's interface to the layer above - its interface to the layer below - the messages (the "on the wire" part) - time - it's state machine and how it reacts to the above 4 items A protocol *implementation* can vary but still interoperate with other protocols only when NONE of the above change. Joe From nobody Fri Dec 9 12:14:40 2016 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 B74021296C3 for ; Fri, 9 Dec 2016 12:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_HELO_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 owNZUxHz5p8l for ; Fri, 9 Dec 2016 12:14:35 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA5312947B for ; Fri, 9 Dec 2016 12:14:34 -0800 (PST) Received: from [192.168.1.103] (p508F1379.dip0.t-ipconnect.de [80.143.19.121]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 8DC42721E280D; Fri, 9 Dec 2016 21:14:31 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Tuexen In-Reply-To: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> Date: Fri, 9 Dec 2016 21:14:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3251) Archived-At: Cc: taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 20:14:38 -0000 > On 7 Dec 2016, at 15:54, Michael Welzl wrote: >=20 > Hi all, >=20 > I have a problem with one particular primitive, or lack of it, in UDP, = UDP-Lite and SCTP. It's something I just don't get. >=20 > Consider this text from draft-fairhurst-taps-transports-usage-udp: >=20 > "GET_INTERFACE_MTU: The GET_INTERFACE_MTU function a network-layer > function that indicates the largest unfragmented IP packet that > may be sent." >=20 > Indeed, this is a network-layer function. It's about the interface, = not about UDP. Does that mean that, to decide how many bytes fit in the = payload of a packet, the programmer needs to know if it's IPv4 or IPv6, = with or without options, and do the calculation? > If so, isn't it extremely odd that UDP doesn't offer a primitive that = provides a more useful number: the available space in its payload, in = bytes? >=20 > I also have the same question for SCTP. For TCP, it's obvious that = the application shouldn't bother, but not for UDP or SCTP. In the API description in https://tools.ietf.org/html/rfc6458 the MTU = exposed to the application via the API is "the number of bytes available in an SCTP packet for = chunks." I think this is the best we can do at that interface... Best regards Michael > At the last meeting, knowing the MTU was mentioned as one of the needs = that latency-critical protocols have. I understand that - but I didn't = include this primitive in the last version of the usage draft because it = is a network-layer primitive... now I don't know how to approach this. >=20 > Thoughts? Suggestions? >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 9 12:23:54 2016 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 9414D129552 for ; Fri, 9 Dec 2016 12:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 KUZUA0cC8Oeg for ; Fri, 9 Dec 2016 12:23:51 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 EA2991293E1 for ; Fri, 9 Dec 2016 12:23:50 -0800 (PST) Received: from [128.9.184.112] ([128.9.184.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uB9KN4MP015791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Dec 2016 12:23:05 -0800 (PST) To: Michael Tuexen , Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> From: Joe Touch Message-ID: Date: Fri, 9 Dec 2016 12:23:03 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 20:23:52 -0000 On 12/9/2016 12:14 PM, Michael Tuexen wrote: >> On 7 Dec 2016, at 15:54, Michael Welzl wrote: >> >> Hi all, >> >> I have a problem with one particular primitive, or lack of it, in UDP, UDP-Lite and SCTP. It's something I just don't get. >> >> Consider this text from draft-fairhurst-taps-transports-usage-udp: >> >> "GET_INTERFACE_MTU: The GET_INTERFACE_MTU function a network-layer >> function that indicates the largest unfragmented IP packet that >> may be sent." >> >> Indeed, this is a network-layer function. It's about the interface, not about UDP. Does that mean that, to decide how many bytes fit in the payload of a packet, the programmer needs to know if it's IPv4 or IPv6, with or without options, and do the calculation? >> If so, isn't it extremely odd that UDP doesn't offer a primitive that provides a more useful number: the available space in its payload, in bytes? >> >> I also have the same question for SCTP. For TCP, it's obvious that the application shouldn't bother, but not for UDP or SCTP. > In the API description in https://tools.ietf.org/html/rfc6458 the MTU exposed to the application > via the API is "the number of bytes available in an SCTP packet for chunks." I think this is the best > we can do at that interface... AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can send without having SCTP coordinate frag/reassembly. That doesn't itself indicate whether it's SCTP doing the rest or the network layer. Joe From nobody Fri Dec 9 12:28:49 2016 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 D73221296C3 for ; Fri, 9 Dec 2016 12:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_HELO_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 7EfdJDQ9lhwp for ; Fri, 9 Dec 2016 12:28:46 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0337E1293E1 for ; Fri, 9 Dec 2016 12:28:46 -0800 (PST) Received: from [192.168.1.103] (p508F1379.dip0.t-ipconnect.de [80.143.19.121]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 99322721E280D; Fri, 9 Dec 2016 21:28:43 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Tuexen In-Reply-To: Date: Fri, 9 Dec 2016 21:28:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> To: Joe Touch X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 20:28:48 -0000 > On 9 Dec 2016, at 21:23, Joe Touch wrote: >=20 >=20 >=20 > On 12/9/2016 12:14 PM, Michael Tuexen wrote: >>> On 7 Dec 2016, at 15:54, Michael Welzl wrote: >>>=20 >>> Hi all, >>>=20 >>> I have a problem with one particular primitive, or lack of it, in = UDP, UDP-Lite and SCTP. It's something I just don't get. >>>=20 >>> Consider this text from draft-fairhurst-taps-transports-usage-udp: >>>=20 >>> "GET_INTERFACE_MTU: The GET_INTERFACE_MTU function a network-layer >>> function that indicates the largest unfragmented IP packet that >>> may be sent." >>>=20 >>> Indeed, this is a network-layer function. It's about the interface, = not about UDP. Does that mean that, to decide how many bytes fit in the = payload of a packet, the programmer needs to know if it's IPv4 or IPv6, = with or without options, and do the calculation? >>> If so, isn't it extremely odd that UDP doesn't offer a primitive = that provides a more useful number: the available space in its payload, = in bytes? >>>=20 >>> I also have the same question for SCTP. For TCP, it's obvious that = the application shouldn't bother, but not for UDP or SCTP. >> In the API description in https://tools.ietf.org/html/rfc6458 the MTU = exposed to the application >> via the API is "the number of bytes available in an SCTP packet for = chunks." I think this is the best >> we can do at that interface... > AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can = send > without having SCTP coordinate frag/reassembly. That doesn't itself You need to take the DATA or I-DATA chunk header into account... It is "the number of bytes in the packet for chunks", not "the number of bytes for the chunk value for DATA (or I-DATA) chunks". > indicate whether it's SCTP doing the rest or the network layer. As I said, that is what is exposed to the upper layer via the API. SCTP itself has procedures to detect the PMTU (of each path). It does PMTU discovery by interacting with the IP layer... Best regards Michael >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 9 13:13:19 2016 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 DAAC9129541 for ; Fri, 9 Dec 2016 13:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 TJi4htwgl_IL for ; Fri, 9 Dec 2016 13:13:16 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 5A30412896F for ; Fri, 9 Dec 2016 13:13:16 -0800 (PST) Received: from [128.9.184.112] ([128.9.184.112]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uB9LCnLx022273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Dec 2016 13:12:49 -0800 (PST) To: Michael Tuexen References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> From: Joe Touch Message-ID: <02059bca-cd0e-c5a5-8cb0-b558c57e3e66@isi.edu> Date: Fri, 9 Dec 2016 13:12:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:13:18 -0000 On 12/9/2016 12:28 PM, Michael Tuexen wrote: >> ... >>> In the API description in https://tools.ietf.org/html/rfc6458 the MTU exposed to the application >>> via the API is "the number of bytes available in an SCTP packet for chunks." I think this is the best >>> we can do at that interface... >> AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can send >> without having SCTP coordinate frag/reassembly. That doesn't itself > You need to take the DATA or I-DATA chunk header into account... > It is "the number of bytes in the packet for chunks", not "the number > of bytes for the chunk value for DATA (or I-DATA) chunks". Yes, but (see below). > >> indicate whether it's SCTP doing the rest or the network layer. > As I said, that is what is exposed to the upper layer via the API. > SCTP itself has procedures to detect the PMTU (of each path). > It does PMTU discovery by interacting with the IP layer... Yes, but it's possible that the chunksize the app sees from SCTP is related to SCTP's reassembly limit, not IP's and not the PMTU. At least that's how I read SCTP_MAXSEG. Joe From nobody Fri Dec 9 13:26:58 2016 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 E523A129584 for ; Fri, 9 Dec 2016 13:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_HELO_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 b6DC9cLRSAQF for ; Fri, 9 Dec 2016 13:26:55 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A75F129560 for ; Fri, 9 Dec 2016 13:26:55 -0800 (PST) Received: from [192.168.1.103] (p508F1227.dip0.t-ipconnect.de [80.143.18.39]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id D897B721E280D; Fri, 9 Dec 2016 22:26:52 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Tuexen In-Reply-To: <02059bca-cd0e-c5a5-8cb0-b558c57e3e66@isi.edu> Date: Fri, 9 Dec 2016 22:26:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> <02059bca-cd0e-c5a5-8cb0-b558c57e3e66@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:26:57 -0000 > On 9 Dec 2016, at 22:12, Joe Touch wrote: >=20 >=20 >=20 > On 12/9/2016 12:28 PM, Michael Tuexen wrote: >>> ... >>>> In the API description in https://tools.ietf.org/html/rfc6458 the = MTU exposed to the application >>>> via the API is "the number of bytes available in an SCTP packet for = chunks." I think this is the best >>>> we can do at that interface... >>> AFAICT, that's 1) in my list, e.g., the largest chunk that SCTP can = send >>> without having SCTP coordinate frag/reassembly. That doesn't itself >> You need to take the DATA or I-DATA chunk header into account... >> It is "the number of bytes in the packet for chunks", not "the number >> of bytes for the chunk value for DATA (or I-DATA) chunks". > Yes, but (see below). >=20 >>=20 >>> indicate whether it's SCTP doing the rest or the network layer. >> As I said, that is what is exposed to the upper layer via the API. >> SCTP itself has procedures to detect the PMTU (of each path). >> It does PMTU discovery by interacting with the IP layer... >=20 > Yes, but it's possible that the chunksize the app sees from SCTP is > related to SCTP's reassembly limit, not IP's and not the PMTU. >=20 > At least that's how I read SCTP_MAXSEG. Not sure what the reassembly limit is... SCTP handled arbitrary sized user messages a the receiver side by using partial delivery. The SCTP_MAXSEG allows a user to limit the size of DATA chunks without reducing the pmtu. Please note that this only affects DATA chunks, not the whole packet. So that is why I was not referring to this option. The socket options I was referring to are: * SCTP_GET_PEER_ADDR_INFO defined in = https://tools.ietf.org/html/rfc6458#section-8.2.2 * SCTP_PEER_ADDR_PARAMS defined in = https://tools.ietf.org/html/rfc6458#section-8.1.12 Best regards Michael >=20 > Joe From nobody Fri Dec 9 13:30:35 2016 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 C2390129581 for ; Fri, 9 Dec 2016 13:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 GZTjfvGytulg for ; Fri, 9 Dec 2016 13:30:33 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 86058129541 for ; Fri, 9 Dec 2016 13:30:33 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id uB9LUDAX017556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Dec 2016 13:30:13 -0800 (PST) To: Michael Tuexen References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> <02059bca-cd0e-c5a5-8cb0-b558c57e3e66@isi.edu> From: Joe Touch Message-ID: <6cd65f53-0a9f-dc60-1b9a-4d03fc000560@isi.edu> Date: Fri, 9 Dec 2016 13:30:13 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: uB9LUDAX017556 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:30:35 -0000 On 12/9/2016 1:26 PM, Michael Tuexen wrote: > > Not sure what the reassembly limit is... SCTP handled arbitrary sized > user messages a the receiver side by using partial delivery. > > The SCTP_MAXSEG allows a user to limit the size of DATA chunks without > reducing the pmtu. Yes, but that size can actually be larger than the PMTU, not just smaller. > Please note that this only affects DATA chunks, not > the whole packet. I was referring to the size the layer above SCTP deals with, not the layer below. Joe From nobody Fri Dec 9 13:38:26 2016 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 3026D129541 for ; Fri, 9 Dec 2016 13:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.497 X-Spam-Level: X-Spam-Status: No, score=-5.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_HELO_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 ruDaOMTZBtuc for ; Fri, 9 Dec 2016 13:38:23 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3721294AB for ; Fri, 9 Dec 2016 13:38:23 -0800 (PST) Received: from [192.168.1.103] (p508F1227.dip0.t-ipconnect.de [80.143.18.39]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id F1B73721E280D; Fri, 9 Dec 2016 22:38:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Tuexen In-Reply-To: <6cd65f53-0a9f-dc60-1b9a-4d03fc000560@isi.edu> Date: Fri, 9 Dec 2016 22:38:19 +0100 Content-Transfer-Encoding: 7bit Message-Id: <95955536-0235-403F-8F8D-049FCC8C118A@lurchi.franken.de> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> <02059bca-cd0e-c5a5-8cb0-b558c57e3e66@isi.edu> <6cd65f53-0a9f-dc60-1b9a-4d03fc000560@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 21:38:25 -0000 > On 9 Dec 2016, at 22:30, Joe Touch wrote: > > > > On 12/9/2016 1:26 PM, Michael Tuexen wrote: >> >> Not sure what the reassembly limit is... SCTP handled arbitrary sized >> user messages a the receiver side by using partial delivery. >> >> The SCTP_MAXSEG allows a user to limit the size of DATA chunks without >> reducing the pmtu. > Yes, but that size can actually be larger than the PMTU, not just smaller. Hmm. https://tools.ietf.org/html/rfc6458#section-8.1.16 states: Note that the underlying SCTP implementation may fragment into smaller sized chunks when the PMTU of the underlying association is smaller than the value set by the user. So this means the user can not rely on this option to turn off SCTP fragmentation and let SCTP pass IP-packets down the stack to let the IP do the fragmentation. That is why I said, the user can use this option to ask the SCTP layer to use a smaller value than the one deduced from the PMTU. That is something you can do safely. Best regards Michael > >> Please note that this only affects DATA chunks, not >> the whole packet. > I was referring to the size the layer above SCTP deals with, not the > layer below. > > Joe > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 9 14:14:29 2016 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 C6D6112954A for ; Fri, 9 Dec 2016 14:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 H-b8JONIWoDQ for ; Fri, 9 Dec 2016 14:14:26 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 65B30129531 for ; Fri, 9 Dec 2016 14:14:26 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id uB9MDqvF010804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Dec 2016 14:13:52 -0800 (PST) To: Michael Tuexen References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> <02059bca-cd0e-c5a5-8cb0-b558c57e3e66@isi.edu> <6cd65f53-0a9f-dc60-1b9a-4d03fc000560@isi.edu> <95955536-0235-403F-8F8D-049FCC8C118A@lurchi.franken.de> From: Joe Touch Message-ID: Date: Fri, 9 Dec 2016 14:13:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <95955536-0235-403F-8F8D-049FCC8C118A@lurchi.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: uB9MDqvF010804 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 22:14:28 -0000 On 12/9/2016 1:38 PM, Michael Tuexen wrote: >> On 9 Dec 2016, at 22:30, Joe Touch wrote: >> >> >> >> On 12/9/2016 1:26 PM, Michael Tuexen wrote: >>> Not sure what the reassembly limit is... SCTP handled arbitrary sized >>> user messages a the receiver side by using partial delivery. >>> >>> The SCTP_MAXSEG allows a user to limit the size of DATA chunks without >>> reducing the pmtu. >> Yes, but that size can actually be larger than the PMTU, not just smaller. > Hmm. https://tools.ietf.org/html/rfc6458#section-8.1.16 states: > > Note that the > underlying SCTP implementation may fragment into smaller sized chunks > when the PMTU of the underlying association is smaller than the value > set by the user. > > So this means the user can not rely on this option to turn off SCTP > fragmentation and let SCTP pass IP-packets down the stack to let > the IP do the fragmentation. > > That is why I said, the user can use this option to ask the SCTP > layer to use a smaller value than the one deduced from the PMTU. > That is something you can do safely. It seems like this setting is independent of PMTU. It could be larger than PMTU, in which case SCTP *or* IP could do fragmentation (and I don't see whether there's a way to know or force that decision). Yes, you can set it smaller too. Joe From nobody Mon Dec 12 01:31:48 2016 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 69F9C12951A for ; Mon, 12 Dec 2016 01:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 sXgn_FGqr_Q2 for ; Mon, 12 Dec 2016 01:31:44 -0800 (PST) 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 CB87B1294C1 for ; Mon, 12 Dec 2016 01:31:43 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cGMxQ-0000FZ-PR for taps@ietf.org; Mon, 12 Dec 2016 10:31:40 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cGMxQ-0005eC-1Z; Mon, 12 Dec 2016 10:31:40 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> Date: Mon, 12 Dec 2016 10:31:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 5 sum rcpts/h 10 sum msgs/h 6 total rcpts 49862 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.534, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 90B17833F0FEBD9D0D667ED871683A7D0B48DF6D X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 11853 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 09:31:46 -0000 Hi, Just trying to understand, so we're not talking past each other. Please = note that I'm not trying to argue in any direction with my comments = below, just asking for clarification: > On 09 Dec 2016, at 18:32, Joe Touch wrote: >=20 >=20 >=20 > On 12/9/2016 8:12 AM, Michael Welzl wrote: >>> On 09 Dec 2016, at 16:18, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 12/9/2016 12:09 AM, Michael Welzl wrote: >>>>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>>>>=20 >>>>> FYI, there are two different "largest messages" at the transport = layer: >>>>>=20 >>>>> 1) the size of the message that CAN be delivered at all >>>> True... I wasn't thinking of that, but yes. >>>>=20 >>>>=20 >>>>> 2) the size of the message that can be delivered without = network-layer >>>>> fragmentation (there are no guarantees about link-layer - see ATM = or the >>>>> recent discussion on tunnel MTUs on INTAREA) >>>>>=20 >>>>> MTU generally refers to the *link payload*. At that point, = transports >>>>> have to account for network headers, network options, transport = headers, >>>>> and transport options too. See RFC6691. >>>>>=20 >>>>> MSS refers to the transport message size AFAICT. It is *sometimes* = tuned >>>>> to MTU-headers but not always. >>>>>=20 >>>>> E.g., for IPv6, link MTU is required to be at least 1280, but the >>>>> src-dst transit MTU is required to be at least 1500. So a = transport that >>>>> wants to match sizes and reduce fragmentation issues would pick >>>>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to = trust >>>>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of = the time. >>>> So I'm getting the impression that the answer to my question really = is that, to figure out 2) (which I was concerned with), an application = programmer needs to do the calculation her/himself. >>> To figure out 2), the transport layer needs to know the unfragmented >>> link MTU, the size of all of the network headers (including = options), >>> and the sizes of its own headers and options. >>>=20 >>> It's also sometimes assumes that the transport can control the "DF" = bit >>> (for IPv4). >> Yes - but that hardly sounds worse to me than requiring the = application programmer to do this protocol-specific calculation by = hand... >=20 > The app programmer needs to know what the transport can support, the > transport needs to know what net supports, etc. >=20 > Pushing the link MTU up the line and expecting all the other layers to > figure out what to do results in unnecessary complexity, never mind > undermining one of the key features of layering. Either we just agree here, or you're saying that your 2) above should = not be exposed? Or something else? >>> However, this all breaks down if the app makes the wrong choice = because >>> the net can (will, and should) source fragment if it gets a message = that >>> turns out to be too big for one fragment anyway. >>>=20 >>>> Not a big deal - and maybe some systems offer a function to give = you the size of a message that won't be fragmented. >>> Remember that - at best - you're optimizing for the next layer down >>> only. You can't know whether that net layer message is link = fragmented >>> (e.g., as in ATM) or tunnel fragmented (as needs to be required or = this >>> whole MTU concept breaks down). >> Sure - but that's something end systems just can't see. It's = information up to and including the IP layer that should be correctly = handed over up the stack, inside the host, with all the caveats this = information comes with. > Why does that apply at the link layer but not other layers? If = transport > can transfer and reassemble 1MB messages, then that's the "MTU" it = needs > to tell the app layer. The same is true for net to tell transport, = etc. >=20 > We've conflated the two between transport and net unnecessarily. So this sounds like you're saying that your item 2) above should not be = exposed by the transport layer to the application. >>>> However: this calculation is transport protocol dependent, which we = really don't want to have in TAPS. >>> If you want to fix this, you need to change the API to the net layer = to >>> provide immediate feedback. When transport hands a segment to = network, >>> it has to get a "call failed" if the message is too big - and we = really >>> do need transport layers to be able to pick between "too big for >>> non-fragmented net layer" and "too big for the net layer even with = frag". >>>=20 >>> Merely handing info to the transport layer might not be enough, esp. >>> when net layer option lengths change. >> True if you want to cleanly fix it across the RFC-specified stack, = but that's beyond the concern of TAPS - it becomes a requirement from = the TAPS WG. Does that make sense? >=20 > Then this is part of the API requirements that TAPS should be > indicating, no? So what does that mean: that the API should contain a "don't fragment" = flag from the application? Cheers, Michael From nobody Mon Dec 12 01:39:18 2016 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 F39101295AA for ; Mon, 12 Dec 2016 01:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 vbntgAImH8C6 for ; Mon, 12 Dec 2016 01:38:59 -0800 (PST) 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 80BCA1294DA for ; Mon, 12 Dec 2016 01:38:54 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cGN4O-0001KH-TD for taps@ietf.org; Mon, 12 Dec 2016 10:38:52 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cGN4O-0006ep-E1; Mon, 12 Dec 2016 10:38:52 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Mon, 12 Dec 2016 10:38:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57CB71E2-B87E-4121-94DD-966FD822072C@ifi.uio.no> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <477E5339-173E-4483-913B-F7213AA9444B@lurchi.franken.de> <7F789A8B-54E0-435F-8AF7-7387E6A87970@lurchi.franken.de> <02059bca-cd0e-c5a5-8cb0-b558c57e3e66@isi.edu> <6cd65f53-0a9f-dc60-1b9a-4d03fc000560@isi.edu> <95955536-0235-403F-8F8D-049FCC8C118A@lurchi.franken.de> To: Joe Touch X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 6 sum rcpts/h 13 sum msgs/h 7 total rcpts 49865 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.534, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5726EF6350DCCAD422C5D9184A7756C6067A1D3E X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 11854 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Michael Tuexen , "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 09:39:09 -0000 > On 09 Dec 2016, at 23:13, Joe Touch wrote: >=20 >=20 >=20 > On 12/9/2016 1:38 PM, Michael Tuexen wrote: >>> On 9 Dec 2016, at 22:30, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 12/9/2016 1:26 PM, Michael Tuexen wrote: >>>> Not sure what the reassembly limit is... SCTP handled arbitrary = sized >>>> user messages a the receiver side by using partial delivery. >>>>=20 >>>> The SCTP_MAXSEG allows a user to limit the size of DATA chunks = without >>>> reducing the pmtu. >>> Yes, but that size can actually be larger than the PMTU, not just = smaller. >> Hmm. https://tools.ietf.org/html/rfc6458#section-8.1.16 states: >>=20 >> Note that the >> underlying SCTP implementation may fragment into smaller sized = chunks >> when the PMTU of the underlying association is smaller than the = value >> set by the user. >>=20 >> So this means the user can not rely on this option to turn off SCTP >> fragmentation and let SCTP pass IP-packets down the stack to let >> the IP do the fragmentation. >>=20 >> That is why I said, the user can use this option to ask the SCTP >> layer to use a smaller value than the one deduced from the PMTU. >> That is something you can do safely. >=20 > It seems like this setting is independent of PMTU. It could be larger > than PMTU, in which case SCTP *or* IP could do fragmentation (and I > don't see whether there's a way to know or force that decision). Why do you say that? IIUC, you can get "spinfo_mtu" ( = https://tools.ietf.org/html/rfc6458#section-8.2.2 ), and then set the = maximum fragmentation size ( = https://tools.ietf.org/html/rfc6458#section-8.1.16 ) to be equal to or = smaller than that value, in which case you can safely assume no = fragmentation inside the same host. Cheers, Michael From nobody Mon Dec 12 03:45:56 2016 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 73F6D1295AB for ; Mon, 12 Dec 2016 03:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 MM1ws17Kvxy7 for ; Mon, 12 Dec 2016 03:45:51 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 81E32129529 for ; Mon, 12 Dec 2016 03:45:51 -0800 (PST) Received: from dhcp-207-163.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:11e6:1921:b706:ab55]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id DFB6B1B0020A; Mon, 12 Dec 2016 13:43:56 +0000 (GMT) References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> To: Michael Welzl , Joe Touch From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Mon, 12 Dec 2016 11:45:41 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 11:45:54 -0000 On 12/12/2016 09:31, Michael Welzl wrote: > Hi, > > Just trying to understand, so we're not talking past each other. Please note that I'm not trying to argue in any direction with my comments below, just asking for clarification: > > >> On 09 Dec 2016, at 18:32, Joe Touch wrote: >> >> >> >> On 12/9/2016 8:12 AM, Michael Welzl wrote: >>>> On 09 Dec 2016, at 16:18, Joe Touch wrote: >>>> >>>> >>>> >>>> On 12/9/2016 12:09 AM, Michael Welzl wrote: >>>>>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>>>>> >>>>>> FYI, there are two different "largest messages" at the transport layer: >>>>>> >>>>>> 1) the size of the message that CAN be delivered at all >>>>> True... I wasn't thinking of that, but yes. >>>>> >>>>> >>>>>> 2) the size of the message that can be delivered without network-layer >>>>>> fragmentation (there are no guarantees about link-layer - see ATM or the >>>>>> recent discussion on tunnel MTUs on INTAREA) >>>>>> >>>>>> MTU generally refers to the *link payload*. At that point, transports >>>>>> have to account for network headers, network options, transport headers, >>>>>> and transport options too. See RFC6691. >>>>>> >>>>>> MSS refers to the transport message size AFAICT. It is *sometimes* tuned >>>>>> to MTU-headers but not always. >>>>>> >>>>>> E.g., for IPv6, link MTU is required to be at least 1280, but the >>>>>> src-dst transit MTU is required to be at least 1500. So a transport that >>>>>> wants to match sizes and reduce fragmentation issues would pick >>>>>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust >>>>>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. >>>>> So I'm getting the impression that the answer to my question really is that, to figure out 2) (which I was concerned with), an application programmer needs to do the calculation her/himself. >>>> To figure out 2), the transport layer needs to know the unfragmented >>>> link MTU, the size of all of the network headers (including options), >>>> and the sizes of its own headers and options. >>>> >>>> It's also sometimes assumes that the transport can control the "DF" bit >>>> (for IPv4). >>> Yes - but that hardly sounds worse to me than requiring the application programmer to do this protocol-specific calculation by hand... >> >> The app programmer needs to know what the transport can support, the >> transport needs to know what net supports, etc. >> >> Pushing the link MTU up the line and expecting all the other layers to >> figure out what to do results in unnecessary complexity, never mind >> undermining one of the key features of layering. > > Either we just agree here, or you're saying that your 2) above should not be exposed? Or something else? > > >>>> However, this all breaks down if the app makes the wrong choice because >>>> the net can (will, and should) source fragment if it gets a message that >>>> turns out to be too big for one fragment anyway. >>>> >>>>> Not a big deal - and maybe some systems offer a function to give you the size of a message that won't be fragmented. >>>> Remember that - at best - you're optimizing for the next layer down >>>> only. You can't know whether that net layer message is link fragmented >>>> (e.g., as in ATM) or tunnel fragmented (as needs to be required or this >>>> whole MTU concept breaks down). >>> Sure - but that's something end systems just can't see. It's information up to and including the IP layer that should be correctly handed over up the stack, inside the host, with all the caveats this information comes with. >> Why does that apply at the link layer but not other layers? If transport >> can transfer and reassemble 1MB messages, then that's the "MTU" it needs >> to tell the app layer. The same is true for net to tell transport, etc. >> >> We've conflated the two between transport and net unnecessarily. > > So this sounds like you're saying that your item 2) above should not be exposed by the transport layer to the application. > > >>>>> However: this calculation is transport protocol dependent, which we really don't want to have in TAPS. >>>> If you want to fix this, you need to change the API to the net layer to >>>> provide immediate feedback. When transport hands a segment to network, >>>> it has to get a "call failed" if the message is too big - and we really >>>> do need transport layers to be able to pick between "too big for >>>> non-fragmented net layer" and "too big for the net layer even with frag". >>>> >>>> Merely handing info to the transport layer might not be enough, esp. >>>> when net layer option lengths change. >>> True if you want to cleanly fix it across the RFC-specified stack, but that's beyond the concern of TAPS - it becomes a requirement from the TAPS WG. Does that make sense? >> >> Then this is part of the API requirements that TAPS should be >> indicating, no? > > So what does that mean: that the API should contain a "don't fragment" flag from the application? > Definitely. The use of DF in a datagram protocol is per-datagram decision - depending on what the app needs to happen. gorry > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Mon Dec 12 10:50:10 2016 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 1DFFA12961C for ; Mon, 12 Dec 2016 10:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 E8wN69O_kc07 for ; Mon, 12 Dec 2016 10:50:07 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 86C591295B5 for ; Mon, 12 Dec 2016 10:50:07 -0800 (PST) Received: from [128.9.184.157] ([128.9.184.157]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBCIno0f013449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Dec 2016 10:49:50 -0800 (PST) To: Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> From: Joe Touch Message-ID: <6668e9f5-4279-eb71-1053-55dbeec94953@isi.edu> Date: Mon, 12 Dec 2016 10:49:48 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:50:09 -0000 On 12/12/2016 1:31 AM, Michael Welzl wrote: > Hi, > > Just trying to understand, so we're not talking past each other. Please note that I'm not trying to argue in any direction with my comments below, just asking for clarification: Sure... > >> On 09 Dec 2016, at 18:32, Joe Touch wrote: >> >> >> >> On 12/9/2016 8:12 AM, Michael Welzl wrote: >>>> On 09 Dec 2016, at 16:18, Joe Touch wrote: >>>> >>>> >>>> >>>> On 12/9/2016 12:09 AM, Michael Welzl wrote: >>>>>> On 07 Dec 2016, at 20:29, Joe Touch wrote: >>>>>> >>>>>> FYI, there are two different "largest messages" at the transport layer: >>>>>> >>>>>> 1) the size of the message that CAN be delivered at all >>>>> True... I wasn't thinking of that, but yes. >>>>> >>>>> >>>>>> 2) the size of the message that can be delivered without network-layer >>>>>> fragmentation (there are no guarantees about link-layer - see ATM or the >>>>>> recent discussion on tunnel MTUs on INTAREA) >>>>>> >>>>>> MTU generally refers to the *link payload*. At that point, transports >>>>>> have to account for network headers, network options, transport headers, >>>>>> and transport options too. See RFC6691. >>>>>> >>>>>> MSS refers to the transport message size AFAICT. It is *sometimes* tuned >>>>>> to MTU-headers but not always. >>>>>> >>>>>> E.g., for IPv6, link MTU is required to be at least 1280, but the >>>>>> src-dst transit MTU is required to be at least 1500. So a transport that >>>>>> wants to match sizes and reduce fragmentation issues would pick >>>>>> 1280-IPh-IPo-TCPh-TCPo, but a transport is supposed to be able to trust >>>>>> that 1500-IPh-IPo-TCPh-TCPo can still get through at least some of the time. >>>>> So I'm getting the impression that the answer to my question really is that, to figure out 2) (which I was concerned with), an application programmer needs to do the calculation her/himself. >>>> To figure out 2), the transport layer needs to know the unfragmented >>>> link MTU, the size of all of the network headers (including options), >>>> and the sizes of its own headers and options. >>>> >>>> It's also sometimes assumes that the transport can control the "DF" bit >>>> (for IPv4). >>> Yes - but that hardly sounds worse to me than requiring the application programmer to do this protocol-specific calculation by hand... >> The app programmer needs to know what the transport can support, the >> transport needs to know what net supports, etc. >> >> Pushing the link MTU up the line and expecting all the other layers to >> figure out what to do results in unnecessary complexity, never mind >> undermining one of the key features of layering. > Either we just agree here, or you're saying that your 2) above should not be exposed? Or something else? I'm saying that exposing 2) is a bad idea because it requires extra information that can vary at other layers. >>>> However, this all breaks down if the app makes the wrong choice because >>>> the net can (will, and should) source fragment if it gets a message that >>>> turns out to be too big for one fragment anyway. >>>> >>>>> Not a big deal - and maybe some systems offer a function to give you the size of a message that won't be fragmented. >>>> Remember that - at best - you're optimizing for the next layer down >>>> only. You can't know whether that net layer message is link fragmented >>>> (e.g., as in ATM) or tunnel fragmented (as needs to be required or this >>>> whole MTU concept breaks down). >>> Sure - but that's something end systems just can't see. It's information up to and including the IP layer that should be correctly handed over up the stack, inside the host, with all the caveats this information comes with. >> Why does that apply at the link layer but not other layers? If transport >> can transfer and reassemble 1MB messages, then that's the "MTU" it needs >> to tell the app layer. The same is true for net to tell transport, etc. >> >> We've conflated the two between transport and net unnecessarily. > So this sounds like you're saying that your item 2) above should not be exposed by the transport layer to the application. Right - because it's irrelevant to the app. The app needs to know the "unit of transfer" of the next layer down. If transport frags and reassembles it to the network layer, then the network layer unit of transmission is not relevant to the app. >>>>> However: this calculation is transport protocol dependent, which we really don't want to have in TAPS. >>>> If you want to fix this, you need to change the API to the net layer to >>>> provide immediate feedback. When transport hands a segment to network, >>>> it has to get a "call failed" if the message is too big - and we really >>>> do need transport layers to be able to pick between "too big for >>>> non-fragmented net layer" and "too big for the net layer even with frag". >>>> >>>> Merely handing info to the transport layer might not be enough, esp. >>>> when net layer option lengths change. >>> True if you want to cleanly fix it across the RFC-specified stack, but that's beyond the concern of TAPS - it becomes a requirement from the TAPS WG. Does that make sense? >> Then this is part of the API requirements that TAPS should be >> indicating, no? > So what does that mean: that the API should contain a "don't fragment" flag from the application? The API between transport and app should expose the "unit of transfer" to the app. The API between transport and network layers needs to expose the DF bit *only* for IPv4 and only if it wants to avoid in-transit re-fragmentation, but that's a temporary issue as it applies only to IPv4. The real question is "what MTU does the network layer tell the transport layer". There are two different ones (ignoring DF for now because it's only IPv4): (a) - the smallest message that can transit the network layer without source fragmentation (b) - the smallest message that can transit the network with source fragmentation Right now, neither of these are part of the transport-network API; at best, we indicate the *link* MTU, from which transport needs to subtract IPheader and IPoptions to determine the transport MTU (which it then reduces by TCPhdr and TCPoptions, e.g. - but that's fine because it's inside the transport layer). Joe From nobody Mon Dec 12 10:52:11 2016 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 639361294B9 for ; Mon, 12 Dec 2016 10:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.795 X-Spam-Level: X-Spam-Status: No, score=-9.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 ZaOyLNS2q9eO for ; Mon, 12 Dec 2016 10:52:08 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 2F28A1294A6 for ; Mon, 12 Dec 2016 10:52:08 -0800 (PST) Received: from [128.9.184.157] ([128.9.184.157]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBCIovoE014195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Dec 2016 10:50:57 -0800 (PST) To: gorry@erg.abdn.ac.uk, Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> From: Joe Touch Message-ID: <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> Date: Mon, 12 Dec 2016 10:50:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0D34B45B6E28A7E578658475" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:52:09 -0000 This is a multi-part message in MIME format. --------------0D34B45B6E28A7E578658475 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/12/2016 3:45 AM, Gorry Fairhurst wrote: >> >> So what does that mean: that the API should contain a "don't >> fragment" flag from the application? >> > Definitely. > > The use of DF in a datagram protocol is per-datagram decision - > depending on what the app needs to happen. > > gorry IMO, the app should never need to play with DF. It needs to know what it thinks the transport can deliver - which might include transport frag/reassembly and network frag/reassembly. Joe --------------0D34B45B6E28A7E578658475 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 12/12/2016 3:45 AM, Gorry Fairhurst wrote:

So what does that mean: that the API should contain a "don't fragment" flag from the application?

Definitely.

The use of DF in a datagram protocol is per-datagram decision - depending on what the app needs to happen.

gorry

IMO, the app should never need to play with DF. It needs to know what it thinks the transport can deliver - which might include transport frag/reassembly and network frag/reassembly.

Joe


--------------0D34B45B6E28A7E578658475-- From nobody Mon Dec 12 10:58:26 2016 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 A3A661294C4 for ; Mon, 12 Dec 2016 10:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 s5EjmB_CNVWQ for ; Mon, 12 Dec 2016 10:58:23 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 57DA61294B9 for ; Mon, 12 Dec 2016 10:58:23 -0800 (PST) Received: from dhcp-207-163.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:11e6:1921:b706:ab55]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 30FAB1B001E4; Mon, 12 Dec 2016 20:56:32 +0000 (GMT) References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> To: Joe Touch , Michael Welzl From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Mon, 12 Dec 2016 18:58:22 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 18:58:24 -0000 On 12/12/2016 18:50, Joe Touch wrote: > > > On 12/12/2016 3:45 AM, Gorry Fairhurst wrote: >>> >>> So what does that mean: that the API should contain a "don't >>> fragment" flag from the application? >>> >> Definitely. >> >> The use of DF in a datagram protocol is per-datagram decision - >> depending on what the app needs to happen. >> >> gorry > > IMO, the app should never need to play with DF. It needs to know what it > thinks the transport can deliver - which might include transport > frag/reassembly and network frag/reassembly. How does the App handle probes for path MTU then in UDP? Gorry > Joe > > From nobody Mon Dec 12 11:10:52 2016 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 B057C129706 for ; Mon, 12 Dec 2016 11:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.795 X-Spam-Level: X-Spam-Status: No, score=-9.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 pThyyIAtG2l1 for ; Mon, 12 Dec 2016 11:10:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 068DE12961C for ; Mon, 12 Dec 2016 11:10:47 -0800 (PST) Received: from [128.9.184.157] ([128.9.184.157]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBCJ9Y1G022004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Dec 2016 11:09:35 -0800 (PST) To: gorry@erg.abdn.ac.uk, Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> From: Joe Touch Message-ID: <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> Date: Mon, 12 Dec 2016 11:09:32 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2257DEC36E10915058354244" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 19:10:52 -0000 This is a multi-part message in MIME format. --------------2257DEC36E10915058354244 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/12/2016 10:58 AM, Gorry Fairhurst wrote: >> >> IMO, the app should never need to play with DF. It needs to know what it >> thinks the transport can deliver - which might include transport >> frag/reassembly and network frag/reassembly. > How does the App handle probes for path MTU then in UDP? > > Gorry I think there needs to be two parts to the API: - largest transmission size - native transmission desired (true/false) If the app says "YES" to native transmission size, then that would suggest that UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not only set DF=1, but also not source fragment. I.e., I don't think it's the app's job to know how to explicitly control a mechanism two layers down, and DF isn't really what you want anyway. DF isn't the same as "don't source fragment". Joe --------------2257DEC36E10915058354244 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit



On 12/12/2016 10:58 AM, Gorry Fairhurst wrote:

IMO, the app should never need to play with DF. It needs to know what it
thinks the transport can deliver - which might include transport
frag/reassembly and network frag/reassembly.
How does the App handle probes for path MTU then in UDP?

Gorry
I think there needs to be two parts to the API:

- largest transmission size
- native transmission desired (true/false)

If the app says "YES" to native transmission size, then that would suggest that UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not only set DF=1, but also not source fragment.

I.e., I don't think it's the app's job to know how to explicitly control a mechanism two layers down, and DF isn't really what you want anyway. DF isn't the same as "don't source fragment".

Joe
--------------2257DEC36E10915058354244-- From nobody Mon Dec 12 12:53:49 2016 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 AF7B7129471 for ; Mon, 12 Dec 2016 12:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 4-pGtQAolwQ6 for ; Mon, 12 Dec 2016 12:53:44 -0800 (PST) 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 4C7951293F2 for ; Mon, 12 Dec 2016 12:53:44 -0800 (PST) Received: from [10.218.241.155] (unknown [85.255.232.247]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2A53E1B001B9; Mon, 12 Dec 2016 22:51:51 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Gorry (erg)" X-Mailer: iPhone Mail (14B150) In-Reply-To: <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> Date: Mon, 12 Dec 2016 20:53:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> To: Joe Touch Archived-At: Cc: Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 20:53:47 -0000 This is fine - it looks a like what I pointed to in the DCCP spec. But speci= fically, I agree you don't need the DF flag visible - if you have a way to c= onvey the info needed to set the flag at the transport (and anything else ap= propriate -as you note). I am all in favour of such appropriate abstraction.= Gorry > On 12 Dec 2016, at 19:09, Joe Touch wrote: >=20 >> On 12/12/2016 10:58 AM, Gorry Fairhurst wrote: >>>=20 >>> IMO, the app should never need to play with DF. It needs to know what it= =20 >>> thinks the transport can deliver - which might include transport = =20 >>> frag/reassembly and network frag/reassembly.=20 >> How does the App handle probes for path MTU then in UDP?=20 >>=20 >> Gorry > I think there needs to be two parts to the API: >=20 > - largest transmission size > - native transmission desired (true/false) >=20 > If the app says "YES" to native transmission size, then that would suggest= that UDP would do *nothing* and pass that same kind of flag down to IP, whe= re IP would not only set DF=3D1, but also not source fragment. >=20 > I.e., I don't think it's the app's job to know how to explicitly control a= mechanism two layers down, and DF isn't really what you want anyway. DF isn= 't the same as "don't source fragment". >=20 > Joe > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Dec 13 01:14:00 2016 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 462CC129A09 for ; Tue, 13 Dec 2016 01:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 8u9xeI7Nj-ka for ; Tue, 13 Dec 2016 01:13:56 -0800 (PST) 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 55ABE129A03 for ; Tue, 13 Dec 2016 01:13:56 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cGj9m-0003IY-6D for taps@ietf.org; Tue, 13 Dec 2016 10:13:54 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cGj9l-0004LY-JK; Tue, 13 Dec 2016 10:13:54 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> Date: Tue, 13 Dec 2016 10:13:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 8 sum msgs/h 4 total rcpts 49910 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.534, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1C684598475A4F7CEFCA2D56C18ACFBA342C8078 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 11879 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" , Joe Touch Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 09:13:59 -0000 Hi, This direction definitely makes sense to me, too. I see some tension = here, though - on the one hand, Joe is (as usual) arguing "cleanliness", = i.e. keep layering right. On the other hand, applications tend to want = to know a message size that doesn't get fragmented along an IPv4 path = (as identified by the authors of draft-trammell-post-sockets and = draft-mcquistin-taps-low-latency-services). Raising the abstraction level is fine, but I think Joe's suggestion = below misses something. In an earlier email, Joe wrote about these two sizes: *** 1) the size of the message that CAN be delivered at all 2) the size of the message that can be delivered without network-layer fragmentation *** and stated that 2) should not be exposed. So, in the proposal below, "largest transmission size" is 1) from above, = and sending it would fail if it's bigger than 2) above AND "native = transmission desired" is set to TRUE. So this is how the application = would then do its own form of PMTUD. Given that we don't know which protocol we're running over, probing = strategies that involve common MTU sizes (like using the table in = section 7.1 of RFC1191) can't work. So it's not the world's most = efficient PMTUD that applications will be using, to eventually find the = value of 2). A protocol like SCTP is even going to do PMTUD on its own, so it could = provide a number for 2), which would have less overhead than requiring = applications to do their own PMTUD. =3D> If we have to "go dirty" = anyway, which we already do by exposing the binary "native transmission = desired", why not offer the value of 2) as well? In other words: how is this boolean better than offering 2) ? Cheers, Michael > On 12 Dec 2016, at 21:53, Gorry (erg) wrote: >=20 > This is fine - it looks a like what I pointed to in the DCCP spec. But = specifically, I agree you don't need the DF flag visible - if you have = a way to convey the info needed to set the flag at the transport (and = anything else appropriate -as you note). I am all in favour of such = appropriate abstraction. >=20 > Gorry >=20 >> On 12 Dec 2016, at 19:09, Joe Touch wrote: >>=20 >>> On 12/12/2016 10:58 AM, Gorry Fairhurst wrote: >>>>=20 >>>> IMO, the app should never need to play with DF. It needs to know = what it=20 >>>> thinks the transport can deliver - which might include transport = =20 >>>> frag/reassembly and network frag/reassembly.=20 >>> How does the App handle probes for path MTU then in UDP?=20 >>>=20 >>> Gorry >> I think there needs to be two parts to the API: >>=20 >> - largest transmission size >> - native transmission desired (true/false) >>=20 >> If the app says "YES" to native transmission size, then that would = suggest that UDP would do *nothing* and pass that same kind of flag down = to IP, where IP would not only set DF=3D1, but also not source fragment. >>=20 >> I.e., I don't think it's the app's job to know how to explicitly = control a mechanism two layers down, and DF isn't really what you want = anyway. DF isn't the same as "don't source fragment". >>=20 >> Joe >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Tue Dec 13 02:05:53 2016 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 BFA52129597 for ; Tue, 13 Dec 2016 02:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 mnIGHVvfJCYg for ; Tue, 13 Dec 2016 02:05:49 -0800 (PST) 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 15293129A42 for ; Tue, 13 Dec 2016 02:05:49 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 03FC71B001E9; Tue, 13 Dec 2016 12:03:29 +0000 (GMT) Message-ID: <584FC7DF.5040108@erg.abdn.ac.uk> Date: Tue, 13 Dec 2016 10:05:19 +0000 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> In-Reply-To: <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joe Touch , "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 10:05:51 -0000 On 13/12/2016 09:13, Michael Welzl wrote: > Hi, > > This direction definitely makes sense to me, too. I see some tension here, though - on the one hand, Joe is (as usual) arguing "cleanliness", i.e. keep layering right. On the other hand, applications tend to want to know a message size that doesn't get fragmented along an IPv4 path (as identified by the authors of draft-trammell-post-sockets and draft-mcquistin-taps-low-latency-services). > Raising the abstraction level is fine, but I think Joe's suggestion below misses something. > > In an earlier email, Joe wrote about these two sizes: > > *** > 1) the size of the message that CAN be delivered at all > > 2) the size of the message that can be delivered without network-layer > fragmentation > *** > and stated that 2) should not be exposed. > > So, in the proposal below, "largest transmission size" is 1) from above, and sending it would fail if it's bigger than 2) above AND "native transmission desired" is set to TRUE. So this is how the application would then do its own form of PMTUD. > > Given that we don't know which protocol we're running over, probing strategies that involve common MTU sizes (like using the table in section 7.1 of RFC1191) can't work. So it's not the world's most efficient PMTUD that applications will be using, to eventually find the value of 2). > A protocol like SCTP is even going to do PMTUD on its own, so it could provide a number for 2), which would have less overhead than requiring applications to do their own PMTUD. => If we have to "go dirty" anyway, which we already do by exposing the binary "native transmission desired", why not offer the value of 2) as well? > In other words: how is this boolean better than offering 2) ? > > Cheers, > Michael > > > >> On 12 Dec 2016, at 21:53, Gorry (erg) wrote: >> >> This is fine - it looks a like what I pointed to in the DCCP spec. But specifically, I agree you don't need the DF flag visible - if you have a way to convey the info needed to set the flag at the transport (and anything else appropriate -as you note). I am all in favour of such appropriate abstraction. >> >> Gorry >> >>> On 12 Dec 2016, at 19:09, Joe Touch wrote: >>> >>>> On 12/12/2016 10:58 AM, Gorry Fairhurst wrote: >>>>> IMO, the app should never need to play with DF. It needs to know what it >>>>> thinks the transport can deliver - which might include transport >>>>> frag/reassembly and network frag/reassembly. >>>> How does the App handle probes for path MTU then in UDP? >>>> >>>> Gorry >>> I think there needs to be two parts to the API: >>> >>> - largest transmission size >>> - native transmission desired (true/false) >>> >>> If the app says "YES" to native transmission size, then that would suggest that UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not only set DF=1, but also not source fragment. >>> >>> I.e., I don't think it's the app's job to know how to explicitly control a mechanism two layers down, and DF isn't really what you want anyway. DF isn't the same as "don't source fragment". >>> >>> Joe >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps So I'd like to return to RFCs that have been through part of this discussion before, (1) I think we need a parameter returned to the App that is equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is useful to know how many bytes the app can send with reasonable chance of unfragmented delivery. (2) It's helpful for Apps to be able to retrieve the upper size allowed with potential fragmentation - that could be useful in determinine probe sizes for an application. Apps should know the hard limt, In DCCP this is called the current congestion control maximum packet size (CCMPS), the largest permitted by the stack using the current congestion control method. That's bound to be less than or equal to what is permitted for the local Interface MTU. This limit lets the App also take into consideration other size constraints in the stack below the API. (3) Apps need to be allowed to fragment datagrams more than MPS - This is not expected as the default, the stack needs to be told. (4) Apps need to be allowed to not allow datagram fragmentation - The stack needs to be told. You could do this by using the DF semantics (i.e., don't source fragment a DF-marked packet). Thinking more, this seems the easiest. Sorry, if this goes over what I said before, but I think we should first explore the approaches that have already been put forward in RFCs (alebit these were not RFCs about UDP). Gorry From nobody Tue Dec 13 04:53:27 2016 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 3F454129698 for ; Tue, 13 Dec 2016 04:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 HFTLerJqfiHC for ; Tue, 13 Dec 2016 04:53:23 -0800 (PST) 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 37DCE129673 for ; Tue, 13 Dec 2016 04:53:23 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cGma9-0002bA-K7 for taps@ietf.org; Tue, 13 Dec 2016 13:53:21 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1cGma8-0005EE-Us; Tue, 13 Dec 2016 13:53:21 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <584FC7DF.5040108@erg.abdn.ac.uk> Date: Tue, 13 Dec 2016 13:53:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9746E98C-5187-413B-B773-FC839ACDA7D5@ifi.uio.no> References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> <584FC7DF.5040108@erg.abdn.ac.uk> To: " Fairhurst" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 6 sum rcpts/h 12 sum msgs/h 7 total rcpts 49929 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.5, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.534, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8F8D717E4313A61BA9513AEBB86412C3AFD11A74 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -64 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 11890 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Joe Touch , "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 12:53:26 -0000 > On 13 Dec 2016, at 11:05, Gorry Fairhurst = wrote: >=20 > On 13/12/2016 09:13, Michael Welzl wrote: >> Hi, >>=20 >> This direction definitely makes sense to me, too. I see some tension = here, though - on the one hand, Joe is (as usual) arguing "cleanliness", = i.e. keep layering right. On the other hand, applications tend to want = to know a message size that doesn't get fragmented along an IPv4 path = (as identified by the authors of draft-trammell-post-sockets and = draft-mcquistin-taps-low-latency-services). >> Raising the abstraction level is fine, but I think Joe's suggestion = below misses something. >>=20 >> In an earlier email, Joe wrote about these two sizes: >>=20 >> *** >> 1) the size of the message that CAN be delivered at all >>=20 >> 2) the size of the message that can be delivered without = network-layer >> fragmentation >> *** >> and stated that 2) should not be exposed. >>=20 >> So, in the proposal below, "largest transmission size" is 1) from = above, and sending it would fail if it's bigger than 2) above AND = "native transmission desired" is set to TRUE. So this is how the = application would then do its own form of PMTUD. >>=20 >> Given that we don't know which protocol we're running over, probing = strategies that involve common MTU sizes (like using the table in = section 7.1 of RFC1191) can't work. So it's not the world's most = efficient PMTUD that applications will be using, to eventually find the = value of 2). >> A protocol like SCTP is even going to do PMTUD on its own, so it = could provide a number for 2), which would have less overhead than = requiring applications to do their own PMTUD. =3D> If we have to "go = dirty" anyway, which we already do by exposing the binary "native = transmission desired", why not offer the value of 2) as well? >> In other words: how is this boolean better than offering 2) ? >>=20 >> Cheers, >> Michael >>=20 >>=20 >>=20 >>> On 12 Dec 2016, at 21:53, Gorry (erg) wrote: >>>=20 >>> This is fine - it looks a like what I pointed to in the DCCP spec. = But specifically, I agree you don't need the DF flag visible - if you = have a way to convey the info needed to set the flag at the transport = (and anything else appropriate -as you note). I am all in favour of such = appropriate abstraction. >>>=20 >>> Gorry >>>=20 >>>> On 12 Dec 2016, at 19:09, Joe Touch wrote: >>>>=20 >>>>> On 12/12/2016 10:58 AM, Gorry Fairhurst wrote: >>>>>> IMO, the app should never need to play with DF. It needs to know = what it >>>>>> thinks the transport can deliver - which might include transport >>>>>> frag/reassembly and network frag/reassembly. >>>>> How does the App handle probes for path MTU then in UDP? >>>>>=20 >>>>> Gorry >>>> I think there needs to be two parts to the API: >>>>=20 >>>> - largest transmission size >>>> - native transmission desired (true/false) >>>>=20 >>>> If the app says "YES" to native transmission size, then that would = suggest that UDP would do *nothing* and pass that same kind of flag down = to IP, where IP would not only set DF=3D1, but also not source fragment. >>>>=20 >>>> I.e., I don't think it's the app's job to know how to explicitly = control a mechanism two layers down, and DF isn't really what you want = anyway. DF isn't the same as "don't source fragment". >>>>=20 >>>> Joe >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > So I'd like to return to RFCs that have been through part of this = discussion before, >=20 > (1) I think we need a parameter returned to the App that is equivalent = to Maximum Packet Size, MPS, in DCCP (RFC4340). It is useful to know how = many bytes the app can send with reasonable chance of unfragmented = delivery. I agree; that seems to be what I ended up proposing above. > (2) It's helpful for Apps to be able to retrieve the upper size = allowed with potential fragmentation - that could be useful in = determinine probe sizes for an application. Apps should know the hard = limt, In DCCP this is called the current congestion control maximum = packet size (CCMPS), the largest permitted by the stack using the = current congestion control method. That's bound to be less than or equal = to what is permitted for the local Interface MTU. This limit lets the = App also take into consideration other size constraints in the stack = below the API. Agreed; I think that was Joe's item 1) ("the size of the message that = CAN be delivered at all"). > (3) Apps need to be allowed to fragment datagrams more than MPS - This = is not expected as the default, the stack needs to be told. >=20 > (4) Apps need to be allowed to not allow datagram fragmentation - The = stack needs to be told. You could do this by using the DF semantics = (i.e., don't source fragment a DF-marked packet). Thinking more, this = seems the easiest. These two are hard to parse, making me wonder if they mean what was = intended. E.g. for (3): applications are always allowed to fragment = their data as they wish, right? Did you mean to say "Apps need to be = allowed to allow to fragment datagrams more than MPS" ? :-) I think = so... > Sorry, if this goes over what I said before, but I think we should = first explore the approaches that have already been put forward in RFCs = (alebit these were not RFCs about UDP). Makes perfect sense to me. Anyway it seems (if I parse them right) that = (3) and (4) are just Joe's "native transmission desired" boolean. So in conclusion, IIUC, this is just a way of saying that: your item 1: you (as I) also think we should have a "Maximum Packet = Size" type thing in addition to what Joe said, your items 2, 3 and 4: you (as I) agree to offer the other things that = Joe also thinks should be offered Right? Cheers, Michael From nobody Tue Dec 13 05:35:06 2016 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 7CD081296D5 for ; Tue, 13 Dec 2016 05:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 JWuk9ixvLbaW for ; Tue, 13 Dec 2016 05:35:01 -0800 (PST) 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 4CDC61296D3 for ; Tue, 13 Dec 2016 05:35:01 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 565081B001E9; Tue, 13 Dec 2016 15:32:40 +0000 (GMT) Message-ID: <584FF8E7.9070905@erg.abdn.ac.uk> Date: Tue, 13 Dec 2016 13:34:31 +0000 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> <584FC7DF.5040108@erg.abdn.ac.uk> <9746E98C-5187-413B-B773-FC839ACDA7D5@ifi.uio.no> In-Reply-To: <9746E98C-5187-413B-B773-FC839ACDA7D5@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Joe Touch , "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 13:35:05 -0000 On 13/12/2016 12:53, Michael Welzl wrote: >> On 13 Dec 2016, at 11:05, Gorry Fairhurst wrote: >> >> On 13/12/2016 09:13, Michael Welzl wrote: >>> Hi, >>> >>> This direction definitely makes sense to me, too. I see some tension here, though - on the one hand, Joe is (as usual) arguing "cleanliness", i.e. keep layering right. On the other hand, applications tend to want to know a message size that doesn't get fragmented along an IPv4 path (as identified by the authors of draft-trammell-post-sockets and draft-mcquistin-taps-low-latency-services). >>> Raising the abstraction level is fine, but I think Joe's suggestion below misses something. >>> >>> In an earlier email, Joe wrote about these two sizes: >>> >>> *** >>> 1) the size of the message that CAN be delivered at all >>> >>> 2) the size of the message that can be delivered without network-layer >>> fragmentation >>> *** >>> and stated that 2) should not be exposed. >>> >>> So, in the proposal below, "largest transmission size" is 1) from above, and sending it would fail if it's bigger than 2) above AND "native transmission desired" is set to TRUE. So this is how the application would then do its own form of PMTUD. >>> >>> Given that we don't know which protocol we're running over, probing strategies that involve common MTU sizes (like using the table in section 7.1 of RFC1191) can't work. So it's not the world's most efficient PMTUD that applications will be using, to eventually find the value of 2). >>> A protocol like SCTP is even going to do PMTUD on its own, so it could provide a number for 2), which would have less overhead than requiring applications to do their own PMTUD. => If we have to "go dirty" anyway, which we already do by exposing the binary "native transmission desired", why not offer the value of 2) as well? >>> In other words: how is this boolean better than offering 2) ? >>> >>> Cheers, >>> Michael >>> >>> >>> >>>> On 12 Dec 2016, at 21:53, Gorry (erg) wrote: >>>> >>>> This is fine - it looks a like what I pointed to in the DCCP spec. But specifically, I agree you don't need the DF flag visible - if you have a way to convey the info needed to set the flag at the transport (and anything else appropriate -as you note). I am all in favour of such appropriate abstraction. >>>> >>>> Gorry >>>> >>>>> On 12 Dec 2016, at 19:09, Joe Touch wrote: >>>>> >>>>>> On 12/12/2016 10:58 AM, Gorry Fairhurst wrote: >>>>>>> IMO, the app should never need to play with DF. It needs to know what it >>>>>>> thinks the transport can deliver - which might include transport >>>>>>> frag/reassembly and network frag/reassembly. >>>>>> How does the App handle probes for path MTU then in UDP? >>>>>> >>>>>> Gorry >>>>> I think there needs to be two parts to the API: >>>>> >>>>> - largest transmission size >>>>> - native transmission desired (true/false) >>>>> >>>>> If the app says "YES" to native transmission size, then that would suggest that UDP would do *nothing* and pass that same kind of flag down to IP, where IP would not only set DF=1, but also not source fragment. >>>>> >>>>> I.e., I don't think it's the app's job to know how to explicitly control a mechanism two layers down, and DF isn't really what you want anyway. DF isn't the same as "don't source fragment". >>>>> >>>>> Joe >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> So I'd like to return to RFCs that have been through part of this discussion before, >> >> (1) I think we need a parameter returned to the App that is equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is useful to know how many bytes the app can send with reasonable chance of unfragmented delivery. > I agree; that seems to be what I ended up proposing above. > > >> (2) It's helpful for Apps to be able to retrieve the upper size allowed with potential fragmentation - that could be useful in determinine probe sizes for an application. Apps should know the hard limt, In DCCP this is called the current congestion control maximum packet size (CCMPS), the largest permitted by the stack using the current congestion control method. That's bound to be less than or equal to what is permitted for the local Interface MTU. This limit lets the App also take into consideration other size constraints in the stack below the API. > Agreed; I think that was Joe's item 1) ("the size of the message that CAN be delivered at all"). > > >> (3) Apps need to be allowed to fragment datagrams more than MPS - This is not expected as the default, the stack needs to be told. >> >> (4) Apps need to be allowed to not allow datagram fragmentation - The stack needs to be told. You could do this by using the DF semantics (i.e., don't source fragment a DF-marked packet). Thinking more, this seems the easiest. > These two are hard to parse, Sorry - trying hard. > making me wonder if they mean what was intended. E.g. for (3): applications are always allowed to fragment their data as they wish, right? Did you mean to say "Apps need to be allowed to allow to fragment datagrams more than MPS" ? :-) I think so... Rewritten as: (3) Apps need to be able to ask the stack to try hard to send datagrams larger than the current MPS - This is not expected as the default, the stack needs to be told to enable this use of source/router fragmentation and send IPv4 datagrams with DF=0 (For some IPv4 paths, the PMTU, and hence MPS can be very small). (4) Apps need to be able to ask the stack to send datagrams larger than the current MPS, but NOT if this results in source fragmentation. Such packets need to be sent with DF=1. - This is not expected as the default, the stack needs to be told to enable this - for UDP it would be needed to perform PMTUD. That's I think what has been just called "native transmission desired ". > >> Sorry, if this goes over what I said before, but I think we should first explore the approaches that have already been put forward in RFCs (alebit these were not RFCs about UDP). > Makes perfect sense to me. Anyway it seems (if I parse them right) that (3) and (4) are just Joe's "native transmission desired" boolean. > So in conclusion, IIUC, this is just a way of saying that: > your item 1: you (as I) also think we should have a "Maximum Packet Size" type thing in addition to what Joe said, > your items 2, 3 and 4: you (as I) agree to offer the other things that Joe also thinks should be offered > > Right? We may now be in agreement > Cheers, > Michael Gorry From nobody Tue Dec 13 17:24:31 2016 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 8B508129531 for ; Tue, 13 Dec 2016 17:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 pN1puHrxiSfv for ; Tue, 13 Dec 2016 17:24:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 CF6051294A4 for ; Tue, 13 Dec 2016 17:24:27 -0800 (PST) Received: from [128.9.184.244] ([128.9.184.244]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBE1NQq9014341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 13 Dec 2016 17:23:27 -0800 (PST) To: gorry@erg.abdn.ac.uk, Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> <584FC7DF.5040108@erg.abdn.ac.uk> <9746E98C-5187-413B-B773-FC839ACDA7D5@ifi.uio.no> <584FF8E7.9070905@erg.abdn.ac.uk> From: Joe Touch Message-ID: Date: Tue, 13 Dec 2016 17:23:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <584FF8E7.9070905@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 01:24:29 -0000 On 12/13/2016 5:34 AM, Gorry Fairhurst wrote: > ... >>> >>> (1) I think we need a parameter returned to the App that is >>> equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is >>> useful to know how many bytes the app can send with reasonable >>> chance of unfragmented delivery. All we can know is whether it is unfragmented at the next layer down. >> >>> (2) It's helpful for Apps to be able to retrieve the upper size >>> allowed with potential fragmentation - that could be useful in >>> determinine probe sizes for an application. Apps should know the >>> hard limt, In DCCP this is called the current congestion control >>> maximum packet size (CCMPS), the largest permitted by the stack >>> using the current congestion control method. That's bound to be less >>> than or equal to what is permitted for the local Interface MTU. This >>> limit lets the App also take into consideration other size >>> constraints in the stack below the API. >> Again, next layer down only. We're generally talking about existing transports that try to pass the link MTU up through network and transport transparently, but that need not be the case. Keep in mind that the link MTU for ATM AAL5 isn't 48B, it's 9K - i.e., it is the message that the link will deliver intact, not the native link size. ... > (3) Apps need to be able to ask the stack to try hard to send > datagrams larger than the current MPS - I disagree. The app should see two values from transport: A) how big a message can you deliver at all? B) how big a message can you deliver "natively"? Any probing happens between those two values. > This is not expected as the default, the stack needs to be told to > enable this use of source/router fragmentation and send IPv4 datagrams > with DF=0 (For some IPv4 paths, the PMTU, and hence MPS can be very > small). I disagree. DF=0 is a network flag that should never be exposed to the app. Even if it is, this wouldn't be the control the app really wants. The app would want to prevent source fragmentation. DF=0 applies to IPv4 only and only affects *on path* fragmentation. But that's not the transport's job. Consider this: - transport has max and native message sizes - network has max and native message sizes - link has max and native message sizes Every layer has these. Sometimes they're the same (when a layer doesn't support frag/ressembly , e.g., UDP, Ethernet), sometimes they're not (IP, TCP). Somtimes they're unlimited (TCP has no max message size, AFAICT). > (4) Apps need to be able to ask the stack to send datagrams larger > than the current MPS, but NOT if this results in source fragmentation. Apps can control only transport fragmentation. They can't and shouldn't see or control network or link fragmentation UNLESS transport lets that pass through as a transport behavior. > Such packets need to be sent with DF=1. - This is not expected as the > default, the stack needs to be told to enable this - for UDP it would > be needed to perform PMTUD. That's I think what has been just called > "native transmission desired ". The issue is that this is an interaction between the app and transport. It has nothing to do with the network or link layers - unless the transport wants it to. It's up to the transport to decide whether to try to "pass through" the native network size. It's up to the network layer to decide whether to "pass through" the native link size. E.g., for IPv6, the lowest values to the answers above are: A) 1500B, including IP header and options B) 1280B, including IP header and options That necessarily means that IPv6 over IPv6 cannot truthfully answer (B) - it HAS to require the lower IPv6 to fragment and reassemble. Otherwise it would be reporting a value that would make it no longer compliant with RFC2460. So we need to be careful about this - there really aren't 4 values here. There are only two - the max and "native" *as reported by* the next layer down. There never has been and never can be a way that an app can solely manage PMTUD to match network *unless* the transport passes that information through. There never has been and never can be a way an app can match to a link layer native MTU (otherwise, we'd be spinning MTUs down to 48B for ATM). Joe From nobody Wed Dec 14 03:21:32 2016 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 B4E8E129D91 for ; Wed, 14 Dec 2016 03:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896] 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 lqeoXEqA_FHw for ; Wed, 14 Dec 2016 03:21:28 -0800 (PST) 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 CC0F8129C77 for ; Wed, 14 Dec 2016 03:20:58 -0800 (PST) Received: from dhcp-207-163.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:a467:de96:8224:a8ac]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id ED6471B0020A; Wed, 14 Dec 2016 13:19:03 +0000 (GMT) References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> <584FC7DF.5040108@erg.abdn.ac.uk> <9746E98C-5187-413B-B773-FC839ACDA7D5@ifi.uio.no> <584FF8E7.9070905@erg.abdn.ac.uk> To: Joe Touch , Michael Welzl From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <03c0b7e6-030a-3c15-b96f-1fb8e32e24de@erg.abdn.ac.uk> Date: Wed, 14 Dec 2016 11:20:54 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 11:21:31 -0000 It seems we can not find a common basis here. See below: On 14/12/2016 01:23, Joe Touch wrote: > > > On 12/13/2016 5:34 AM, Gorry Fairhurst wrote: >> ... >>>> >>>> (1) I think we need a parameter returned to the App that is >>>> equivalent to Maximum Packet Size, MPS, in DCCP (RFC4340). It is >>>> useful to know how many bytes the app can send with reasonable >>>> chance of unfragmented delivery. > > All we can know is whether it is unfragmented at the next layer down. > I disagree. The stack can tell the App a MPS value based on PMTUD (when it implements this, or understanding of headers). That's already specified for SCTP & DCCP. Sure, the path may change, but at least the App can access a recent result. >>> >>>> (2) It's helpful for Apps to be able to retrieve the upper size >>>> allowed with potential fragmentation - that could be useful in >>>> determinine probe sizes for an application. Apps should know the >>>> hard limt, In DCCP this is called the current congestion control >>>> maximum packet size (CCMPS), the largest permitted by the stack >>>> using the current congestion control method. That's bound to be less >>>> than or equal to what is permitted for the local Interface MTU. This >>>> limit lets the App also take into consideration other size >>>> constraints in the stack below the API. >>> > Again, next layer down only. We're generally talking about existing > transports that try to pass the link MTU up through network and > transport transparently, but that need not be the case. Keep in mind > that the link MTU for ATM AAL5 isn't 48B, it's 9K - i.e., it is the > message that the link will deliver intact, not the native link size. > ... > In this case, I think you are wrong, sorry. Apps can be told the largest message they can send over a transport. And some transports do in fact limit this. I don't see the relevance of the ATM example. Datagram protocols work at the transport layer. >> (3) Apps need to be able to ask the stack to try hard to send >> datagrams larger than the current MPS - > > I disagree. > We don't agree. Apps can send probe messages. > The app should see two values from transport: > > A) how big a message can you deliver at all? - Wasn't that the thing I originally cited as CCMPS > B) how big a message can you deliver "natively"? - Wasn't that MPS? > > Any probing happens between those two values. > That's a true! >> This is not expected as the default, the stack needs to be told to >> enable this use of source/router fragmentation and send IPv4 datagrams >> with DF=0 (For some IPv4 paths, the PMTU, and hence MPS can be very >> small). > > I disagree. > > DF=0 is a network flag that should never be exposed to the app. Even if > it is, this wouldn't be the control the app really wants. The app would > want to prevent source fragmentation. DF=0 applies to IPv4 only and only > affects *on path* fragmentation. > > But that's not the transport's job. > I disagree, if MPS > datagram > CCMPS the stack needs to know whether to source fragment (3), or for IPv4 whether to allow network fragmentation (4). Potentially you could discard if neither (3) or (4) is allowed. > Consider this: > - transport has max and native message sizes > - network has max and native message sizes > - link has max and native message sizes > > Every layer has these. Sometimes they're the same (when a layer doesn't > support frag/reassembly , e.g., UDP, > UDP does support fragmentation. > Ethernet) ... Which is link layer. > , sometimes they're not > (IP, TCP). Somtimes they're unlimited (TCP has no max message size, AFAICT). > TCP isn't datagram either - and is stream-based - so segments are not necessarily packets. >> (4) Apps need to be able to ask the stack to send datagrams larger >> than the current MPS, but NOT if this results in source fragmentation. > Apps can control only transport fragmentation. They can't and shouldn't > see or control network or link fragmentation UNLESS transport lets that > pass through as a transport behavior. > If we were talking about TCP-like protocols that would be fine, but I'm talking about datagram protocols where the PDU being sent is a datagram. >> Such packets need to be sent with DF=1. - This is not expected as the >> default, the stack needs to be told to enable this - for UDP it would >> be needed to perform PMTUD. That's I think what has been just called >> "native transmission desired ". > > The issue is that this is an interaction between the app and transport. > It has nothing to do with the network or link layers - unless the > transport wants it to. It's up to the transport to decide whether to try > to "pass through" the native network size. It's up to the network layer > to decide whether to "pass through" the native link size. > > E.g., for IPv6, the lowest values to the answers above are: > A) 1500B, including IP header and options > B) 1280B, including IP header and options > > That necessarily means that IPv6 over IPv6 cannot truthfully answer (B) > - it HAS to require the lower IPv6 to fragment and reassemble. Otherwise > it would be reporting a value that would make it no longer compliant > with RFC2460. > Sure, MPS would then be less than 1280 less headers, etc. > So we need to be careful about this - there really aren't 4 values here. > There are only two - the max and "native" *as reported by* the next > layer down. > There are two from the stack (MPS, CCMPS). There is one towards the stack (allow fragmentation below the transport in IPv4, discard if not sendable, or source fragment). > There never has been and never can be a way that an app can solely > manage PMTUD to match network *unless* the transport passes that > information through. There never has been and never can be a way an app > can match to a link layer native MTU (otherwise, we'd be spinning MTUs > down to 48B for ATM). > To be clear, I see "MTU" as an IP-layer parameter. The ATM cell, is in my mind a link frame (an HDLC frame is also a link frame, etc). To me, the interface presented to the network layer (IP MTU) is that supplied by the adaption layer that runs over the link frames. > Joe > Gorry From nobody Wed Dec 14 11:14:10 2016 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 2A5C6129EBA for ; Wed, 14 Dec 2016 11:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 YsjJJgiPJZ49 for ; Wed, 14 Dec 2016 11:14:07 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 81C5B129EC1 for ; Wed, 14 Dec 2016 11:14:02 -0800 (PST) Received: from [128.9.184.244] ([128.9.184.244]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBEJCuoD009674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Dec 2016 11:12:57 -0800 (PST) To: gorry@erg.abdn.ac.uk, Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> <584FC7DF.5040108@erg.abdn.ac.uk> <9746E98C-5187-413B-B773-FC839ACDA7D5@ifi.uio.no> <584FF8E7.9070905@erg.abdn.ac.uk> <03c0b7e6-030a-3c15-b96f-1fb8e32e24de@erg.abdn.ac.uk> From: Joe Touch Message-ID: Date: Wed, 14 Dec 2016 11:12:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <03c0b7e6-030a-3c15-b96f-1fb8e32e24de@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 19:14:09 -0000 Hi, Gorry, Let me see of I can explain my viewpoint. I'll start by noting that there's a difference between "what transports currently do" and what they "should" do. I agree with you that current transports do have access to network MTUs and DF control, but don't always pass all that to the user. Here's what I think is currently required: 1122 indicates the interface between IP and transport as indicating the max send and receive transport sizes - but for IPv6 that would be 1500 - IPheaders, not 1280 - IP headers or even 1500 or 1280. 1122 also indicates that the transport - not the application - gets to set DF in the SEND call to IP. However, there does not appear to be any provision to limit source fragmentation between transport and IP, nor any requirement for UDP to pass that control to the app. ---- So 1122 is consistent with my view that: - the application sees a transport MSS (I'm not sure whether to call that max or native yet...) - the transport sees the max network MSS (i.e., allowing source fragmentation), not the native network MSS I don't understand why 1122 requires transport control over DF, but UDP is not required to pass that control to the user. --- My conclusion is that the app-transport API *should* be required to give the user control over whether to use the max or native transport MSS, just as the transport-API should be required to give the transport control over whether to use the max or native network MSS, and so forth for the network-link API. However, none of that implies that the user ever will be able to match the link MTU. There's always the possibility that one of these layers decides to never report a true native size, e.g., ATM (as a link layer) never reports 48 to IP. This means that apps can't ever really force a probe of much of anything, too. Only transports can. (FWIW, when I say that UDP doesn't support fragmentation, I mean that UDP doesn't have UDP fragmentation. The fragmentation is at the IP layer; UDP is ignorant of it). Joe From nobody Wed Dec 14 14:39:06 2016 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 36392129B41 for ; Wed, 14 Dec 2016 14:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896] 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 87vg7cGsy6Gw for ; Wed, 14 Dec 2016 14:39:01 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 89292129B63 for ; Wed, 14 Dec 2016 14:38:30 -0800 (PST) Received: from [128.9.184.244] ([128.9.184.244]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id uBEMbPaZ012188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 14 Dec 2016 14:37:25 -0800 (PST) To: gorry@erg.abdn.ac.uk, Michael Welzl References: <5F2E34E4-7D32-4BDB-B762-2ADB7994672B@ifi.uio.no> <0213051A-C761-43B3-8750-1B999A8A893A@ifi.uio.no> <00e457fb-4708-6b43-46d4-e065b14dedd9@isi.edu> <19C25F7D-BB05-457C-89E2-450A1E808FDD@ifi.uio.no> <3a5ce4a7-5365-59d9-0ff2-eadeebae4d0a@isi.edu> <4FF8823B-4C6E-41B4-9C30-C6028A2EDBD6@ifi.uio.no> <725460cb-73ab-8c16-8647-9d8711b48fa7@isi.edu> <3fb7b303-91da-83af-9b9d-14b2ea196c9d@isi.edu> <7EDE888D-1E12-4725-849E-D080D6998D6D@erg.abdn.ac.uk> <8EFE0C27-355F-4E63-8E1F-D7E059D0E249@ifi.uio.no> <584FC7DF.5040108@erg.abdn.ac.uk> <9746E98C-5187-413B-B773-FC839ACDA7D5@ifi.uio.no> <584FF8E7.9070905@erg.abdn.ac.uk> <03c0b7e6-030a-3c15-b96f-1fb8e32e24de@erg.abdn.ac.uk> From: Joe Touch Message-ID: Date: Wed, 14 Dec 2016 14:37:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] MTU / equivalent at the transport layer X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 22:39:04 -0000 One piece of potentially important information: PMTUD and PLMTUD are intended to avoid the need for on-path fragmentation. That's why there is control only over the DF bit, not source fragmentation. AFAICT, this points to a (AFAICT) a problem with IPv6 PMTUD as described in RFC1981. That doc claims to try to optimize to the native link MTU, but that doesn't appear to be possible given the way IPv4 and IPv6 interact with transports. There's no signal to IP that says "don't source fragment". Joe On 12/14/2016 11:12 AM, Joe Touch wrote: > Hi, Gorry, > > Let me see of I can explain my viewpoint. > > I'll start by noting that there's a difference between "what transports > currently do" and what they "should" do. I agree with you that current > transports do have access to network MTUs and DF control, but don't > always pass all that to the user. > > Here's what I think is currently required: > > 1122 indicates the interface between IP and transport as indicating the > max send and receive transport sizes - but for IPv6 that would be 1500 - > IPheaders, not 1280 - IP headers or even 1500 or 1280. > > 1122 also indicates that the transport - not the application - gets to > set DF in the SEND call to IP. > > However, there does not appear to be any provision to limit source > fragmentation between transport and IP, nor any requirement for UDP to > pass that control to the app. > > ---- > > So 1122 is consistent with my view that: > > - the application sees a transport MSS (I'm not sure whether to call > that max or native yet...) > > - the transport sees the max network MSS (i.e., allowing source > fragmentation), not the native network MSS > > I don't understand why 1122 requires transport control over DF, but UDP > is not required to pass that control to the user. > > --- > > My conclusion is that the app-transport API *should* be required to give > the user control over whether to use the max or native transport MSS, > just as the transport-API should be required to give the transport > control over whether to use the max or native network MSS, and so forth > for the network-link API. > > However, none of that implies that the user ever will be able to match > the link MTU. There's always the possibility that one of these layers > decides to never report a true native size, e.g., ATM (as a link layer) > never reports 48 to IP. > > This means that apps can't ever really force a probe of much of > anything, too. Only transports can. > > (FWIW, when I say that UDP doesn't support fragmentation, I mean that > UDP doesn't have UDP fragmentation. The fragmentation is at the IP > layer; UDP is ignorant of it). > > Joe From nobody Wed Dec 21 07:25:27 2016 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 48BBB1296D2 for ; Wed, 21 Dec 2016 07:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, 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 9xyTlkl8rkzK for ; Wed, 21 Dec 2016 07:25:25 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 445161296B4 for ; Wed, 21 Dec 2016 07:25:25 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w33so208697113qtc.3 for ; Wed, 21 Dec 2016 07:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=GsdSZfw0VOEmLDU6fysQCVhgN8X/350BGoSAwfJQimA=; b=TAn3/MmrCECPXx8c/cxqHLVJZ5TIRjjzoEHyuFHOsDGArVLwvLWHtUuLm9/ZdlONbi RPYCzYGIsIATjGx643+J7VxK/D2QC5zLszfcx9Yc/HKGhWwamowEyyRNhaMUFfjU6Bfm cXe5iSxtiMfzLvDj83DIHk6y56NZHz9jzdKzyjtiuDc9nzPT84nkSbNd7iXajjisoOAn x5r+jtObgr0DP0EOPARbet5B9qJaPKw60QSQLAlZqYCHFChiMQ4bAAJmjAwWZ3+AE89A tww5+D6tFtHWtwJQaJ5Hrg7t+6UuiQebcWgBXTVx7rrO3OgC78idNh08O4+67/IWVKzJ yuJA== 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 :content-transfer-encoding; bh=GsdSZfw0VOEmLDU6fysQCVhgN8X/350BGoSAwfJQimA=; b=iVbIubY9A0a4ejleHbSAeW/taro84OYtkQXVPWgN0CoDanqbcTsAyt375Fk+UdHOzB jTqI33GSX/rBmMRS87aEprPdLk/jAhO5Bi2nuhyUkTHM5SdYfAZimAASdWrG4q0mudSp EbWJMV1v0vhxsFrOOZvuD38MKQRBlyMa0gCtZ7lfIUo3dGaRY6H8JUljbCAsX7kCtV/z hkx8w9A8TZs3ihDtU6Q7gsM+TTSQ6YzVV2XtAHHIV7K8qyqQvgH8Q/4+PPg7bD74rvCV rY6FWJ+MigZlmAnM3QY64uyQUw6GyTMJ8R/H6C2Evq3yrfGDMu+Oe7fMictLfwNCYruN RFMQ== X-Gm-Message-State: AIkVDXIMCLe5NHO+WTyZ9ErilJrWxlYYgEj9g4hvgR2H8mItTvV/gUeDOEMlbWgWIWh98Q== X-Received: by 10.200.41.171 with SMTP id 40mr5527969qts.235.1482333924129; Wed, 21 Dec 2016 07:25:24 -0800 (PST) Received: from [172.19.41.189] ([2001:4878:8000:60:b556:d7bd:4e5b:4e55]) by smtp.gmail.com with ESMTPSA id r8sm15717505qtc.32.2016.12.21.07.25.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Dec 2016 07:25:23 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Wed, 21 Dec 2016 10:25:22 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9.6r5310) Archived-At: Subject: [Taps] agenda planning for chicago X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 15:25:26 -0000 The secretariat has issued the call for wg sessions. It would be helpful if we had an early idea of the agenda for a TAPS meeting in March. Should we try again to get in the talks on post-sockets and NEAT? Are there any other implementation projects that would like to present? Any other topics to discuss? —aaron From nobody Wed Dec 21 17:20:15 2016 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 61003129656 for ; Wed, 21 Dec 2016 17:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.402 X-Spam-Level: X-Spam-Status: No, score=-7.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 TsHMx8m0R1B5 for ; Wed, 21 Dec 2016 17:20:13 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 2D5CB129655 for ; Wed, 21 Dec 2016 17:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1482369612; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eyp2UeR9o5/Gi9Xebb6UvAKalyY1wfY1z4ORKpYVt8c=; b=bLbEGjpcKeT5VwnOPYgVD5bKnklXtUOgGSDfFcZhcoxdB3avwhKjQG2fF/3rFKds Dxw/w1xHufvfoR9Vv8Yv84v3gZPu18Q5hQNFpUzeWhV6PHATvqh8P+wQODOl9vJT 6jA92ASqwLLt8/b0K3Qc5O4NLIuZSOc6WuGGPCU71WiRLjm4+xUPTlDNyg70oiM1 6rayE9Pw8lffuZtZnZJEqInFN+ciJjinGxYCcLV10x6XoTNkm6wWfzTolxVPYAqs YzZ2xxD6ofLEj1E+p1mGr9Zhi1blqzmK/fAyQYv8jPQSmStBo9h0hVfg3qQ/BGX6 HPSemLAadNSiRVrboKzoDQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id CE.F5.05661.C4A2B585; Wed, 21 Dec 2016 17:20:12 -0800 (PST) X-AuditID: 11973e13-bf50e9a00000161d-08-585b2a4c21bc Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay2.apple.com (Apple SCV relay) with SMTP id 59.2C.09148.C4A2B585; Wed, 21 Dec 2016 17:20:12 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.63.130] (unknown [17.153.63.130]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OIK001P4BPN1380@nwk-mmpp-sz09.apple.com>; Wed, 21 Dec 2016 17:20:12 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Wed, 21 Dec 2016 17:20:11 -0800 Content-transfer-encoding: quoted-printable Message-id: <62A6A8AA-2805-4894-A7F4-1A2FF09D9F52@apple.com> References: To: Aaron Falk X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FDorOujFR1hsOyvukXb72msFndiHJg8 ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MKzs3shZMYavY8OIZYwPjF5YuRk4OCQETidmv Gtm6GLk4hAT2Mkoc+9vFDJNYuOcoE0TiIKPEzv397CAJXgFBiR+T7wF1c3AwC6hLTJmSC1HT xSSxb9k5sLiwgITE5j2JIOXCAvoS33a9ZgOx2QRUJI5/2wA2n1PAVmLmpsNgI1kEVCUufDjA BGIzC0hLLP02mRHC1pZ48u4CK8hIXgEbif2vXUDCQkDm3MZDYCUiQK3LXrSzQZwsK7Hy6UZW kHMkBNawSfTM+ME6gVF4FpKrZyFcPQvJhgWMzKsYhXITM3N0M/NM9RILCnJS9ZLzczcxgkJ6 up3wDsbTq6wOMQpwMCrx8DpMiYoQYk0sK67MPcQozcGiJM5bKhMdISSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoFR07XxQM98592L/oY9ubzpYl3S7ZWF04S5hZa/7YplOnb13YLivXc7v91b ddM7589EzfVZxkw/epIFJrDtTu7rTwzVP6L8W/z5rzsKKrUyJlmhJ43P8TyZFSGnfzs0oMMh 96Hg1rwupblcjAVOnw7K3H8jf6nQR02No6TE71zVpA3MyjXll/KVWIozEg21mIuKEwEbPjAf SgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUi2FAcoOujFR1h8OqVjEXb72msFndiHJg8 ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MKzs3shZMYavY8OIZYwPjF5YuRk4OCQETiYV7 jjJB2GISF+6tZ+ti5OIQEjjIKLFzfz87SIJXQFDix+R7QA0cHMwC6hJTpuRC1HQxSexbdg4s LiwgIbF5TyJIubCAvsS3Xa/ZQGw2ARWJ4982MIPYnAK2EjM3HQYbySKgKnHhwwGwvcwC0hJL v01mhLC1JZ68u8AKMpJXwEZi/2sXkLAQkDm38RBYiQhQ67IX7WwQJ8tKrHy6kXUCo+AsJIfO Qjh0FpKhCxiZVzEKFKXmJFYa6SUWFOSk6iXn525iBIdmofMOxmPLrA4xCnAwKvHwzpgWFSHE mlhWXJl7iFGCg1lJhHeKRnSEEG9KYmVValF+fFFpTmrxIcZkoFcmMkuJJucD4yavJN7QxMTA xNjYzNjY3MScNGElcV5zvogIIYH0xJLU7NTUgtQimC1MHJxSDYxzHQLe/177+7pri8v+pMxz taI//t1xNXJQTd3UFybOdk/vu6Ja7IJY3VLlNyqcS/hSXZ4lRF5PyVJs0RFKCnnFZnFmmUzR zMKKtxV7594pOJgopPPVLa7f4KJsW0TK2yVbNt0+fSbtygUHjzjtEOuDczYLTs6TDvRp6372 uOrf2kd9r5z5VZRYijMSDbWYi4oTAZ8h6rCRAgAA Archived-At: Cc: taps WG Subject: Re: [Taps] agenda planning for chicago X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 01:20:14 -0000 Hi Aaron, We should have updates by March on the Post-Sockets progress, as well as = filling in details that we we're able to get to last time. Please do = allocate an agenda slot for that! Thanks, Tommy > On Dec 21, 2016, at 7:25 AM, Aaron Falk wrote: >=20 > The secretariat has issued the call for wg sessions. It would be = helpful if we had an early idea of the agenda for a TAPS meeting in = March. Should we try again to get in the talks on post-sockets and = NEAT? Are there any other implementation projects that would like to = present? Any other topics to discuss? >=20 > =E2=80=94aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Dec 22 17:16:52 2016 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 31D70129498 for ; Thu, 22 Dec 2016 17:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 gSTzR-5tGkTY for ; Thu, 22 Dec 2016 17:16:48 -0800 (PST) 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 4881A129422 for ; Thu, 22 Dec 2016 17:16:48 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1cKETW-0002pa-52 for taps@ietf.org; Fri, 23 Dec 2016 02:16:46 +0100 Received: from 213-147-160-96.nat.highway.bob.at ([213.147.160.96] helo=[192.168.0.102]) by mail-mx1.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1cKETV-0000oN-CU; Fri, 23 Dec 2016 02:16:46 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Michael Welzl In-Reply-To: Date: Fri, 23 Dec 2016 02:16:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Aaron Falk X-Mailer: Apple Mail (2.3259) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 2 total rcpts 50246 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8525D8CE89D72BEB1AA988296706F268EBCDF1E4 X-UiO-SPAM-Test: remote_host: 213.147.160.96 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] agenda planning for chicago X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 01:16:50 -0000 Hi, We NEATers would love to give the presentation that was dropped the last = time. Other news from my / our side: - getting closer to the finish line with the -usage draft: quite a lot = of updates already done, one major one due early Jan, then we want to = submit=E2=80=A6 - some ideas (thanks to everyone for input at the last meeting! that was = helpful!) for the minset draft, it=E2=80=99s bound to change quite a bit = and hopefully provoke an interesting discussion; for now, the plan is to = also finish that off fast, i.e. maybe in january=E2=80=A6 cheers Michael > On Dec 21, 2016, at 4:25 PM, Aaron Falk wrote: >=20 > The secretariat has issued the call for wg sessions. It would be = helpful if we had an early idea of the agenda for a TAPS meeting in = March. Should we try again to get in the talks on post-sockets and = NEAT? Are there any other implementation projects that would like to = present? Any other topics to discuss? >=20 > =E2=80=94aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps