Thanks for submitting this. I like the idea of trying to get a handle on the minimal transport services that TAPS can support.
Detailed comments on: https://tools.ietf.org/html/draft-gjessing-taps-minset-00 In Section 1: I think the word "non-functional" is a little awkward, since it suggests "dysfunctional" and we probably should seek a different word for clarity. In Section 3: My initial comments are on the list of features (this may have to be fed back to the 1st TAPS ID, but it is more clear here at the moment, so I'll comment here and see what people think: o unicast: TCP SCTP UDP-Lite DCCP NORM - Add UDP-Lite o IPv6 multicast and anycast: UDP - Add UDP-Lite o multicast: NORM - ??? Is this reliable, the multicast part includes UDP, UDP-Lite (as non-reliable) o unidirectional: UDP - Add UDP-Lite o bidirectional: TCP - Add DCCP, SCTP o IPv6 jumbograms: UDP - Add UDP-Lite o 2-tuple endpoints: UDP - Add UDP-Lite o error detection (checksum): TCP UDP - Add UDP-Lite, DCCP o error detection (UDP checksum): NORM -??? I see this is via UDP, but is it a real difference, NORM is only specified over UDP o strong error detection (CRC32C): SCTP - Possible with TCP option, or AUTH or TLS (and possible with UDP/UDP-Lite/DCCP using DTLS o congestion control: TCP SCTP NORM - Add DCCP o no congestion control: UDP - Add UDP-Lite On section 4 I can offer more comments later, but initially I just note that I think the Service Code in DCCP *IS* specified by the Application in the same way that the port is chosen. Gorry _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
