> > > 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. > And does this particular list of things vary between IPv4 or IPv6? - I suggest not really, apart from different naming of the TTL to HOP_COUNT?
> We shouldn't need to update the UDP API whenever IP or other layers > change. > That's a good goal. > Joe > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps > Gorry _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
