> On May 12, 2017, at 3:24 PM, Gorry Fairhurst <[email protected]> wrote: > > See below. > > On 12/05/2017, 13:31, Michael Welzl wrote: >> Hi, >> >> Thanks a lot for all your comments (plus the nits we authors of the other >> -usage draft received offline). >> >> I’ll try to address them all - but there are a two technical questions in >> this email that made me stop, so I’ll cut all the editorial stuff away and >> discuss them here - in line below: >> >> >>> - Why do this??? - Isn't it better to set flow labels per interface or for >>> the whole stack, how can any specific transport or application pick unique >>> labels? >>> TEXT: >>>> o Specify IPv6 flow label field >>>> Protocols: SCTP >>> (i.e., Is this automatable by the host and a host wide >>> configuration?) >> Somehow the question seems irrelevant in the context of this draft, which is >> a list of transport features of protocols. These features are defined in the >> RFCs spec’ing the protocols - for SCTP, this is defined, and that’s why it’s >> here. >> >> We can discuss this for the proposed services that a system should offer, >> which we try to write up in the minset draft: >> I do think that an application should be allowed to assign a label to a TAPS >> flow (as we call them), which could then map to this function. I mean, isn’t >> a flow label supposed to identify a transport flow? Then a system-wide >> configuration wouldn't seem right to me. > I think we may disagree. Flow ids identify flows to the network layer, they > have no role at the transport layer, and need to be unique (as best they can) > for a source address.
We disagree indeed - in particular about the “unique (as best they can)..” bit. Where is this written?? > I much prefer the idea that the Flow id is generated by the IP system, by > using a hash - possibly utilising transport data as a part of this hash, and > including the protocol number. RFC 6437 introduces the flow label as a replacement for the 5-tuple - “possibly utilising transport data as a part of this hash” seems to me to be a very weak requirement here! Anyway classifiers in the network wouldn’t work on the flow label alone, but, from RFC 6437, section 2 which is called “specification”: "Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address fields to identify the flow to which a particular packet belongs." Then what is the flow label good for, if it’s unique per source address? It doesn’t add any information to this 3-tuple in this case! > That seems to be what ECMP is expecting and I suspect ECMP is an improtant > use-case. > > The alternative (if I understand) could be: I could imagine each application > could (in theory) be provided with an API to find out what flow-ids are > currently being used for each interface it cares about and to then reserve > one of the unused IDs for the specific interface(s) that it wishes to use. > Then we need to ensure all upper layer entities coordinate on this. To me, > this seems over-kill, and the approach taken with ephemeral port assignment > is much simpler - the application simply doesn't get involved with choosing > the number. > > Now if what you are saying is that you want the App to somehow signal that it > can use an existing flow ID that is in use, and combine data with that flow > to get the same network treeatment, I can understand the case. However, > that's not exactly the same thing. I understand that it would be nice to avoid upper-layer coordination here. However, I see at least two use cases for the application being more in control: 1) avoiding fate sharing (encouraging ECMP), e.g. for increased resilience 2) the opposite: grouping flows, to be able to apply priorities on them, using a mechanism such as the Congestion Manager or https://tools.ietf.org/html/draft-welzl-tcp-ccc So this is not about giving the application control of the specific flow label number, but allowing it to say “use the same number for these flows” or not. I think this could nicely be done by letting it number flows, and grouping them via equal numbering - without guaranteeing that these numbers map onto the exact same numbers as a flow label. >>> ------------------- >>> Get Interface MTU is missing from pass 2 and 3: >>> >>> ADD to pass 2: >>> >>> GET_INTERFACE_MTU.UDP: >>> Pass 1 primitive: GET_INTERFACE_MTU >>> Returns: Maximum datagram size (bytes) >> But this doesn’t exist! > I think I don't understand your comment ... and interpretting low-numbered > RFCs is never easy - I'll use RFC1122 as my basis: > > RFC 1122 says: > " A host MUST implement a mechanism to allow the transport layer > to learn MMS_S, the maximum transport-layer message size that > may be sent for a given {source, destination, TOS} triplet..." > " and EMTU_S must be less than or equal to the MTU of the network > interface corresponding to the source address of the datagram." > > TCP handles this for the app. … and UDP is another such transport layer. If you try to send a message that’s too large, it throws an error, based on the information it gets via the paragraph you quote above. But that’s UDP, not the application on top. >> It’s strictly an IP function and I couldn’t find it described for UDP >> anywhere. I think we agreed on how a TAPS system should handle this, and >> this is reflected in >> https://tools.ietf.org/html/draft-gjessing-taps-minset-04#section-6.4.1 >> … which may require a system to implement new local functionality, maybe >> based on this MTU function - but to my understanding it’s just not something >> that UDP offers. > It's something that a UDP App really needs to pay attention to as per RFC8085 > - we may differ on whether you call that "offers" or needs to function. > Either way, an app that plans to use any form of PMTUD needs to use this > number. I agree; and we have put related functions into the minset draft. But here we’re describing what it is that UDP itself (not a full-fleged TAPS system) currently offers… > As put in RFC1122: > " A host that does not implement local fragmentation MUST ensure > that the transport layer (for TCP) or the application layer > (for UDP) obtains MMS_S from the IP layer and does not send a > datagram exceeding MMS_S in size.” Okaaay, you found an instance of “ _ or the application layer (for UDP) _ “. I agree this should be included! But, this is not the interface MTU. From RFC 1122: *** If no local fragmentation is performed, the value of MMS_S will be: MMS_S = EMTU_S - <IP header size> and EMTU_S must be less than or equal to the MTU of the network interface corresponding to the source address of the datagram. paragraph further above defines MMS_S as the maximum transport-layer m *** So first of all, there’s the “if” - this would only be the value without local fragmentation. Can we assume that there won’t be local fragmentation? Then, EMTU_S <= interface MTU, and MMS_S is even smaller: very reasonably, the IP header size is subtracted. Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
