Subject: [Taps] Comments on draft-gjessing-taps-minset-00

From: [email-masked]
Date: Fri, 26 Jun 2015 10:21:31 +0100

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

---

From: Stein Gjessing <[email-masked]>
Date: Fri, 26 Jun 2015 12:07:12 +0200

Hi Gorry,

Thank you very much for your feedback.
We will add what you point out that we have missed in Section 3.

Some more comments in-line.

> "dysfunctional" and we probably should seek a different word for clarity.

You are the english speaking person her, so you are probably right.
However “non-functional” has a technical meaning in software design, and that is what I
meant here. See e.g..   https://en.wikipedia.org/wiki/Functional_requirement

> - ??? Is this reliable, the multicast part includes UDP, UDP-Lite (as

I am not sure what you mean here.  Does not NORM implement multicast?
There is no statement about it being reliable or not (but may be it should?)

> -??? I see this is via UDP, but is it a real difference, NORM is only

Yes, so if we want to include NORM (or may be we should not in the initial minimal version?) 
then we must include that it supports error detection as in UDP (?).

> the Service Code in DCCP *IS* specified by the Application in the same way

OK, so we have to include this.

Cheers,
Stein

> 
> Gorry
> 
> 
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: [email-masked]
Date: Fri, 26 Jun 2015 11:14:23 +0100

See in-line,

Gorry

> meant here. See e.g..
> https://en.wikipedia.org/wiki/Functional_requirement
>
Yes I see this use, but still wonder if this is the best word.

> There is no statement about it being reliable or not (but may be it
What I intended to say was:

The set of transports supporting multicast IPv4 or IPv6 is {UDP, UDP-Lite,
NORM}

And hence NORM supports this over UDP, and adds reliability (in various
forms).

> then we must include that it supports error detection as in UDP (?).
Yes - NORM is over UDP, and hence I think its error *detection* model is
the same as UDP.

---

From: Brian Adamson <[email-masked]>
Date: Fri, 26 Jun 2015 10:43:37 -0400

Yes - the error detection for NORM since it rides on top of UDP is the same as UDP and you would not want to run NORM over UDP-Lite as NORM’s use of FEC is for packet erasure filling and not error correction.  I.e., it assumes any messages received are error-free.