See below > > On 4/4/2016 11:24 AM, [email protected] wrote: >> Hi Joe, >> >> We don't seem to be agreeing. > > Not yet at least ;-) > > ... >>> For MSS and segment size, the same ought to be true for UDP. >>> >> 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.
>>> 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. And I agree, to implement this, you can do exactly that and provide additional data per datagram buffer to communicate the DSCP, ECN, TTL ... Gorry > Joe >> >> Gorry >> >>> Joe >>> >>>> >>>> Gorry >>>> >>>>> On 4/3/2016 4:54 AM, [email protected] wrote: >>>>>> When someone talks about using TCP or SCTP then they are typically >>>>>> using >>>>>> an API to the transport that hides a lot of details. >>>>> >>>>> I'm not sure I agree with this. >>>>> >>>>> IMO, TCP defines an API that is intended to provide a service >>>>> capability >>>>> that it renders on top of less-capable underlying services. >>>>> >>>>> UDP does this much less so, so that might be a simpler place to >>>>> start, >>>>> but only because the level of service is simpler - not because of >>>>> "hiding a lot of details". >>>>> >>>>> Joe >>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>> >>> > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
