Subject: Re: [Taps] [ietf-tapswg/api-drafts] Reliable Data Transfer (Message) default - from Kyle Rose's review (#520)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 2 Apr 2020 13:59:16 +0100

We seem to need to decide what "Reliable Data Transfer" means to an 
Application.

My point. expanding here a little, is:

TAPS has to by default do something if the app doesn't say what it 
wants. So this is really about the default service chosen by TAPS.  A 
safe assumption is that an app not designed for reordering, loss, 
duplication etc  will receive the default service, that's why I think 
this should be "Reliable Data Transfer".

Apps that CAN handle all of these need to tell the TAPS Interface that 
they do not need a "Reliable Data Transfer". If the app does not do 
this, and happens to exist on a stack that only supports datagrams, then 
it would not be able to connect.

Gorry

On 02/04/2020 13:32, mwelzl wrote:
>
> List discussion:
>
> *Kyle:*
>
>     7.4.7. Reliable Data Transfer (Message)
>
>       * The default isn't "true", it's whatever the underlying
>         connection had, right?
>
> *@philsbln <https://github.com/philsbln>*:
>
>     Ack
>
> *@mwelzl <https://github.com/mwelzl>*:
>
>     I agree too, but doesn’t this warrant some more discussion?
>     I think our defaults all translate into things that can work in
>     some way when TCP is used - with “Reliable Data Transfer” being an
>     exception, as it just can’t work in a UDP-only system. Are there
>     others? I think I’ll open an issue for this one.
>
> *@gorryfair <https://github.com/gorryfair>*:
>
>     I don't agree at all - To me this was just the default behaviour
>     of the API.
>
>     I think the default needs to be "reliable" and an app will have to
>     over-ride that to get datagram/unreliable operation. That doesn't
>     mean if you have only UDP (for instance) that you can't offer
>     TAPS, to me it simply means you always need to say that the app
>     wants this service.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://github.com/ietf-tapswg/api-drafts/issues/520>, or unsubscribe 
> <https://github.com/notifications/unsubscribe-auth/ABYLLEX6WIN7O2AJT7BBDC3RKSAWLANCNFSM4L2L2TNQ>.
>

---

From: Kyle Rose <[email-masked]>
Date: Thu, 2 Apr 2020 15:35:15 -0400

I'm okay with this.

On Thu, Apr 2, 2020 at 8:59 AM Gorry Fairhurst <[email-masked]> wrote:

> TAPS has to by default do something if the app doesn't say what it wants.
> So this is really about the default service chosen by TAPS.  A safe
> assumption is that an app not designed for reordering, loss, duplication
> etc  will receive the default service, that's why I think this should be
> "Reliable Data Transfer".
>
> they do not need a "Reliable Data Transfer". If the app does not do this,
> and happens to exist on a stack that only supports datagrams, then it would
> not be able to connect.
>
> Gorry
>    - The default isn't "true", it's whatever the underlying connection
>    had, right?
>
> I think our defaults all translate into things that can work in some way
> when TCP is used - with “Reliable Data Transfer” being an exception, as it
> just can’t work in a UDP-only system. Are there others? I think I’ll open
> an issue for this one.
>
> I don't agree at all - To me this was just the default behaviour of the
> API.
>
> over-ride that to get datagram/unreliable operation. That doesn't mean if
> you have only UDP (for instance) that you can't offer TAPS, to me it simply
> means you always need to say that the app wants this service.
>
> —
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
>