Hi Joe, We don't seem to be agreeing.
> Hi, Gorry, > > On 4/4/2016 10:55 AM, [email protected] wrote: >> I was thinking in terms of what we were trying to achieve within TAPS, >> and >> from that perspective things like: ECN-marks, Maximum datagram/segment >> size, etc. I do not think through the TCP API (for instance), since >> these >> concern the path and are only needed by CC or PMTUD algorithms within >> TCP. >> >> These same values do need to be accessed (visible) over the current UDP >> API so that apps can implement mechanisms that use these. > > These are different things, IMO. > > The TCP API needs a way to set any flags in the TCP header, either > directly or indirectly. > Agree > TCP does NOT require a way to set the MSS or segment size, IMO - that > ought to be something it figures out from the interface parameters, IP > settings, remote end, and path. It may be useful to set these things for > instrumentation purposes, but not for regular operation. > Agree. > 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.. > 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? 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
