On 4/4/2016 11:24 AM, go...@erg.abdn.ac.uk 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. >> 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. Joe > > Gorry > >> Joe >> >>> >>> Gorry >>> >>>> On 4/3/2016 4:54 AM, go...@erg.abdn.ac.uk 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 >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>> >> _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
