On 4/4/2016 12:49 PM, [email protected] wrote: ... >>> No. It's true that UDP needs to know this, but this info needs to arrive >>> at the App, either from a primitive that returns the size or from a >>> failed >>> send call when probing for a maximum datagram size. The app also may >>> need >>> to control DF if it wants to do path probing of PMTU, whereas in TCP >>> this >>> is handed within the transport protocol.. >> >> Ahh - I see this now. However, IMO, that ought to be something it gets >> from the IP layer, not from UDP. UDP has an MSS that's defined by the >> protocol itself which is not all that useful to indicate to the app. >> > I see what you are saying for reading the MTU less headers, but whatever > the method, the APP needs to work out what to do with this. For setting DF > this is not necessarily an IP setting for all packets, it can be a per UDP > datagram choice.
Sure, but again that argues for a transparent supplement to the UDP API, not for a UDP-specific API. >>>> For ECN, UDP ought to be ignorant - as should its API. The only >>>> question >>>> is whether the UDP API should have a "pass through" for signals from >>>> lower layers, whether IP, Ethernet, etc. IMO, those aren't part of the >>>> UDP API; they're part of the OS endpoint API to these other protocols. >>>> >>> I don't understand what you are saying about an "OS endpoint API to IP". >>> To me the API has to signal per-datagram on send whether ECT(0) or >>> ECT(1) >>> or neither is to be set, the receive API needs to see the received ECN >>> field for each datagram. >>> >>> Do you see a different way to do this? >> >> Here's the issue - when a message arrives, right now we think of it >> being "from UDP" as part of the UDP API. However, there are no ECN >> markings in UDP. It makes sense to forward the IP source/dest in the UDP >> API because that part of the IP header is defined as part of UDP (as the >> pseudoheader). However, it makes no sense to have that information >> available as part of what UDP passes to the app per se. >> >> So maybe each UDP message is allowed to forward a single opaque (to UDP) >> structure that contains information from any of its underlying layers >> (i.e., a pass-through signal mechanism). But I would consider that not >> really integral to the API of UDP. >> >> I do agree this needs to be per message, not per endpoint. >> > That sounds a lot like you are thinking about a concrete API. Way more abstract. The issue is that these features are not inherent in UDP - they are inherent in the IP over which UDP runs (and depend on that IP version). > And I agree, > to implement this, you can do exactly that and provide additional data per > datagram buffer to communicate the DSCP, ECN, TTL ... My point is that - at the abstract level - UDP should not have an API that talks about DSCP, ECN, or TTL - that ought to be something opaque that UDP hands down underneath. We shouldn't need to update the UDP API whenever IP or other layers change. Joe _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
