Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Fri, 12 May 2017 13:29 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5AF1294FF for <taps@ietfa.amsl.com>; Fri, 12 May 2017 06:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XzCInrCFRq5 for <taps@ietfa.amsl.com>; Fri, 12 May 2017 06:29:32 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4260D12EB5F for <taps@ietf.org>; Fri, 12 May 2017 06:24:47 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 1BC791B014D0; Fri, 12 May 2017 16:19:32 +0100 (BST)
Message-ID: <5915B787.4000307@erg.abdn.ac.uk>
Date: Fri, 12 May 2017 14:24:23 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Michael Welzl <michawe@ifi.uio.no>
CC: "taps@ietf.org" <taps@ietf.org>
References: <15106817-a81c-d247-5fad-a67c5faa93f3@erg.abdn.ac.uk> <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no>
In-Reply-To: <8A063CAE-55DF-4C38-8631-DC854564DE22@ifi.uio.no>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/GvB5iIVFwb_2BBFYGhmaAvTBvRQ>
Subject: Re: [Taps] New rev of udp-usage (01) and review comments on taps-transport-usage-04
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 May 2017 13:29:35 -0000
See below. On 12/05/2017, 13:31, Michael Welzl wrote: > Hi, > > Thanks a lot for all your comments (plus the nits we authors of the other -usage draft received offline). > > I’ll try to address them all - but there are a two technical questions in this email that made me stop, so I’ll cut all the editorial stuff away and discuss them here - in line below: > > >> - Why do this??? - Isn't it better to set flow labels per interface or for the whole stack, how can any specific transport or application pick unique labels? >> TEXT: >>> o Specify IPv6 flow label field >>> Protocols: SCTP >> (i.e., Is this automatable by the host and a host wide >> configuration?) > Somehow the question seems irrelevant in the context of this draft, which is a list of transport features of protocols. These features are defined in the RFCs spec’ing the protocols - for SCTP, this is defined, and that’s why it’s here. > > We can discuss this for the proposed services that a system should offer, which we try to write up in the minset draft: > I do think that an application should be allowed to assign a label to a TAPS flow (as we call them), which could then map to this function. I mean, isn’t a flow label supposed to identify a transport flow? Then a system-wide configuration wouldn't seem right to me. I think we may disagree. Flow ids identify flows to the network layer, they have no role at the transport layer, and need to be unique (as best they can) for a source address. I much prefer the idea that the Flow id is generated by the IP system, by using a hash - possibly utilising transport data as a part of this hash, and including the protocol number. That seems to be what ECMP is expecting and I suspect ECMP is an improtant use-case. The alternative (if I understand) could be: I could imagine each application could (in theory) be provided with an API to find out what flow-ids are currently being used for each interface it cares about and to then reserve one of the unused IDs for the specific interface(s) that it wishes to use. Then we need to ensure all upper layer entities coordinate on this. To me, this seems over-kill, and the approach taken with ephemeral port assignment is much simpler - the application simply doesn't get involved with choosing the number. Now if what you are saying is that you want the App to somehow signal that it can use an existing flow ID that is in use, and combine data with that flow to get the same network treeatment, I can understand the case. However, that's not exactly the same thing. >> ------------------- >> Get Interface MTU is missing from pass 2 and 3: >> >> ADD to pass 2: >> >> GET_INTERFACE_MTU.UDP: >> Pass 1 primitive: GET_INTERFACE_MTU >> Returns: Maximum datagram size (bytes) > But this doesn’t exist! I think I don't understand your comment ... and interpretting low-numbered RFCs is never easy - I'll use RFC1122 as my basis: RFC 1122 says: " A host MUST implement a mechanism to allow the transport layer to learn MMS_S, the maximum transport-layer message size that may be sent for a given {source, destination, TOS} triplet..." " and EMTU_S must be less than or equal to the MTU of the network interface corresponding to the source address of the datagram." TCP handles this for the app. > It’s strictly an IP function and I couldn’t find it described for UDP anywhere. I think we agreed on how a TAPS system should handle this, and this is reflected in > https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-6.4.1 > … which may require a system to implement new local functionality, maybe based on this MTU function - but to my understanding it’s just not something that UDP offers. It's something that a UDP App really needs to pay attention to as per RFC8085 - we may differ on whether you call that "offers" or needs to function. Either way, an app that plans to use any form of PMTUD needs to use this number. As put in RFC1122: " A host that does not implement local fragmentation MUST ensure that the transport layer (for TCP) or the application layer (for UDP) obtains MMS_S from the IP layer and does not send a datagram exceeding MMS_S in size." > > Cheers, > Michael Gorry
- [Taps] New rev of udp-usage (01) and review comme… Gorry Fairhurst
- Re: [Taps] New rev of udp-usage (01) and review c… Michael Welzl
- Re: [Taps] New rev of udp-usage (01) and review c… Gorry Fairhurst
- Re: [Taps] New rev of udp-usage (01) and review c… Michael Welzl
- Re: [Taps] New rev of udp-usage (01) and review c… Gorry Fairhurst
- Re: [Taps] New rev of udp-usage (01) and review c… Michael Welzl
- Re: [Taps] New rev of udp-usage (01) and review c… Erik Kline
- Re: [Taps] New rev of udp-usage (01) and review c… Michael Welzl
- Re: [Taps] New rev of udp-usage (01) and review c… Joe Touch
- Re: [Taps] New rev of udp-usage (01) and review c… Michael Welzl
- Re: [Taps] New rev of udp-usage (01) and review c… Gorry Fairhurst