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

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 24 Mar 2017 13:29:25 +0000

This looks like good progress. A few very specific comments below:

---
I see phrase:
"   Because QoS is out of scope of TAPS, this document assumes a "best
    effort" service model [RFC5290], [RFC7305].  "

I'm not sure we need to state this. Although I agree that TAPS will not 
propose new QoS techniques, the service provided by TAPS is, I think, 
also not confinded to "best effort".

---
I am not sure that IP options from UDP are entirely automatbale. 
Per-packet IP options could be related to application use of the 
network, and I think this would require some form of API interaction.

---
I see LE service as something interesting, yet this does not exactly fit 
the rest of the draft. The cited reference is to a DiffServ PHB, and the 
LEDBAT referenced is a transport protocol mechanism, not a protocol. I'm 
not sure this inclusion is justified in the current tetx.
---
Abort without delivering...

Abortis currently specified for SCTP and TCP. If one assumes the bound 
semantics for UDP(Lite) this also seems also the correct primitive for 
UDP(Lite.

Should this ID specify a connect primitive also for bound use of UDP(Lite)?

---

What should be said about SCTP usage of IP OPTIONS? I would have 
expected if the endpoint network layer set these, they would also work 
for SCTP?

---

Finally,

I think I can agree the argument that UDP(Lite) message handling is 
different to SCTP.

---

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Sun, 26 Mar 2017 06:14:14 -0500

Hi,

Thanks a lot for reading and commenting!

> On Mar 24, 2017, at 8:29 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> I'm not sure we need to state this. Although I agree that TAPS will not propose new QoS techniques, the service provided by TAPS is, I think, also not confinded to "best effort”.

Hmm... I was also thinking about the behavior of the actual TAPS system in the end host, where you may ask for something but might not get it (e.g. requested unordered message delivery might turn into ordered bytestream delivery).
So for now, best effort is indeed the underlying assumption - e.g. the proposed “capacity profile” doesn’t come with any guarantees, it *might* set the DSCP for you, and that *might* have a certain effect.
If we take that assumption away, the proposed system would be different - it would have to fail and say “no, sorry” more often, which I don’t think is a good way ahead. What do you think?

> ---
> I am not sure that IP options from UDP are entirely automatbale. Per-packet IP options could be related to application use of the network, and I think this would require some form of API interaction.
> 
> —

We called everything that doesn’t require application-specific knowledge (knowledge that only applications have) “automatable”. So my first question is: what is it that only an application knows, and that influences the choice of IP options?

(generally though I’d be fine with introducing some transport features that help the system do its automation - the conclusion talks about this, using the choice of paths as an example).

> I see LE service as something interesting, yet this does not exactly fit the rest of the draft. The cited reference is to a DiffServ PHB, and the LEDBAT referenced is a transport protocol mechanism, not a protocol. I'm not sure this inclusion is justified in the current tetx.

True that LEDBAT is a mechanism, not a protocol - but we specifically wanted to include this in TAPS, which is why the charter mentions “congestion control mechanisms", in item 1: "Define a set of Transport Services, identifying the services provided by existing IETF protocols and congestion control mechanisms.”

I addressed this in the usage draft by making ** Enable and configure a "Low Extra Delay Background Transfer” ** a CONNECTION.MAINTENANCE feature, i.e. something you use to configure a connection.
This seems to me to be the most likely implementation - it also matches how e.g. the CDG TCP congestion control mechanism (which was found to exhibit LBE’ behaviour) works. The LBE stuff in minset comes from the usage draft.

> Abortis currently specified for SCTP and TCP. If one assumes the bound semantics for UDP(Lite) this also seems also the correct primitive for UDP(Lite.
> 

Okay, I think you found an error here:
Both “connect" and “close" primitives exist in draft-ietf-taps-transports-usage-udp, and were taken over into step 2 of draft-ietf-taps-transports-usage. Step 3, which is where the transport features in minset come from, misses UDP(-Lite) under “close” !
As I was writing the more elaborate description of “close” in step 3, "Close after reliably delivering all remaining data, causing an event informing the application on the other side”, I felt I really couldn't place UDP(-Lite) there, I think this is how it was dropped. UDP(-Lite) would have survived if this would have been called “ABORT”, and here’s the mistake: semantically, as you identify here, UDP(-Lite)’s “close” is really equivalent to “abort”, not “close”. I can fix this in the next update of the -usage draft, and adjust the -minset draft accordingly.

> ---
> 
> What should be said about SCTP usage of IP OPTIONS? I would have expected if the endpoint network layer set these, they would also work for SCTP?

Look for “SET_IP_OPTIONS” in draft-ietf-taps-transports-usage-udp: your text here cites RFC 1122 saying that UDP offers access to this functionality. I haven’t found anything equivalent for SCTP. It may exist in implementations?  I’m not sure how this is done - maybe there’s a general call to configure IP options for all outgoing packets on an interface, or to a certain destination? If so, this would be worth pointing out at this point, when it comes to discussing possible fall-backs.

> ---
> 
> Finally,
> 
> I think I can agree the argument that UDP(Lite) message handling is different to SCTP.
> 
> ---
> 
> Gorry

Thanks again!

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Sun, 26 Mar 2017 06:19:09 -0500

> As I was writing the more elaborate description of “close” in step 3, "Close after reliably delivering all remaining data, causing an event informing the application on the other side”, I felt I re…

What I just wrote here about being semantically equivalent to abort is wrong. The full description of abort, in step 3 of the usage draft, is:
"Abort without delivering remaining data, causing an event informing the application on the other side"

UDP(-Lite) doesn’t inform the application on the other side. I guess we should give it a new name (“Abort without delivering remaining data, without causing an event informing the application on the other side”) and then process it in -minset like we processed all the others.

Cheers,
Michael

---

From: "Gorry (erg)" <[email-masked]>
Date: Sun, 26 Mar 2017 12:13:46 -0500

This reply is just about the DSCP and QoS. 

 Everything you say about TAPS trying to set DSCP values seems consistent with normal diffserv use to me: Just because an app sets a DSCP does not mean the actually sent packets are assigned a PHB along the path, it simply marks them for this treatment, and packets may also be remarked or dropped. Since there are no guarentees, there is no need for a primitive telling an app it did not get what it hoped for. So to me, this is normal Diffserv QoS treatment. No guarentees.

The words in the charter say "
Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds like a plea not to redesign NSIS RSVP etc...

Gorry

On 26 Mar 2017, at 06:14, Michael Welzl <[email-masked]> wrote:

>> I'm not sure we need to state this. Although I agree that TAPS will not propose new QoS techniques, the service provided by TAPS is, I think, also not confined to "best effort”.
>

---

From: Michael Welzl <[email-masked]>
Date: Sun, 26 Mar 2017 13:59:32 -0500

> On Mar 26, 2017, at 12:13 PM, Gorry (erg) <[email-masked]> wrote:
> 
> 

But not even guaranteeing that packets will be marked would go to far? Or wouldn’t it?
(Just checking - because I think we could make the system guarantee that, as all transports allow setting the DSCP; it was just my decision to combine DSCP-setting with a few other things together and call them "capacity profile", but that’s certainly up for debate).

> Signaling-based Quality-of-Service (QoS) mechanisms" --- which sounds like a plea not to redesign NSIS RSVP etc…

That would be my interpretation too.

Cheers,
Michael

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 26 Mar 2017 20:21:02 -0500

On 26/03/2017, 13:59, Michael Welzl wrote:
>> On Mar 26, 2017, at 12:13 PM, Gorry (erg)<[email-masked]>  wrote:
>>
>>
It clearly doen't help deploy diffserv if your local system bleaches the 
DCSP value to zero. That happens though. So we need to live with that. 
I'd therefore say it is OK.
> (Just checking - because I think we could make the system guarantee that, as all transports allow setting the DSCP; it was just my decision to combine DSCP-setting with a few other things together…
That's more interesting to debate.
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps
Gorry