Re: [Taps] IETF planning

[Mirja Kühlewind <[e-mail]>]

Hi,

see inline.

> Am 27.10.2015 um 19:56 schrieb Michael Welzl <[e-mail]>:
> 
> 
>> On 27. okt. 2015, at 15.46, Mirja Kühlewind <[e-mail]> wrote:
>> 
>> Hi Michael,
>> 
>> for me, when I was reading the following, that was when I found it quite arbitrary again:
>> 
>> "In the list resulting from the second pass, some services are missing
>>  because they are implicit in some protocols, and they only become
>>  explicit when we consider the superset of all services offered by all
>>  protocols. „
>> 
>> So how do we know that we actually caught everything?
> 
> Everything here is based on text parts of the RFCs that focus on what a protocol provides to the upper layer and how it is used.
> This should be everything that’s relevant as a service.
I disagree.

> Now, when you have all these bits covered, for all the protocols you want to cover, this should give you *exactly* the services of relevance - that’s the idea of this procedure.
> 
> For example, now the document contains only TCP and SCTP. There is no mention of congestion control, because, to choose between these two, congestion control is not a relevant service: they both have it, in the same way. If the document would only cover TCP and SCTP, I think that’s exactly how it should be.
I disagree.

> 
> When we add UDP, the obvious RFC to cover is the one on usage guidelines (RFC5405). It will tell us that UDP does not have congestion control, which means that the application has to take care of it. Thus, “no congestion control” becomes a part of the services. Because “lack of XY” is a bit strange as a service, it’d be obvious to write “congestion control” as a service for the other protocols instead.

I don’t think „no congestion control“ is a service. That’s not a logic I understand; sorry.

I don’t think that the point we want to capture is if there is congestion control or not; it’s rather with choices you have about congestion control. And today you might pick one congestion control by name, where the name is a random pick and does not say anything about the mechanism that is used. I’d hope that taps could actually provide an interface that’s actual useful and understandable such that the transport layer can pick the right congestion control for you.

I thought that one of the main points!

> 
> Consider another example. Assume, for a second, that all protocols had the same checksum, and no option to turn it off or configure it. This is not true, but just imagine it for the example.
> In this case, there would never be text in any of the RFCs talking about the relevance of the checksum to the application - and it would never appear as a service, which is exactly the right decision, it would be an integral part of communication that is the same everywhere. Anyway, in reality, as soon as we add UDP-Lite and/or DCCP, we have configurable checksums as a service in the list. But if these protocols are not covered, what’s the point of describing a “configurable checksum” service?
> (I’m ignoring the fact that the checksum can be disabled in UDP now, for simplicity)
> 
Okay, even if extending existing protocols not in the charter, just because every protocol would use the same checksum, that does not mean that it would not be useful to maybe disable it. And if that would be detected by taps which would mean a small protocol change, we could go to the respective wg (e.g. tsvwg or tcpm) and figure out if they would consider such an extension useful. I’m absolutely not convinced here that we don’t want to do that.

Further, back to your example above. To call „no congestion control“ a service you have to analyze the protocol itself. „no congestion control“ is not exposed in any interface!!! And analyzing the protocol is what we do in the taps-transport doc!

When I was reading draft-well-taps-transports I’d had the feeding you’ve started with the interfaces but then detected that obvious things are missing, so you basically also started analyzing the protocols itself but very selectively and from my point of view even more arbitrary.

The true might be somewhere in between here and we might need to do both to get an as complete as possible picture. As I said in my previous mail, we could even even merge both docs and or have two separate ones. Again as I said before to me the approach you take is less logical and I don’t think it will led to a complete or ‚right‘ solution either.

From my point of view, let's keep in mind all the discussion we had and what we learned to far, and let’s move on!

Mirja


> 
> 
>> Further see below.
>> 
>>> Am 27.10.2015 um 15:27 schrieb Michael Welzl <[e-mail]>:
>>> 
>>> 
>>>> On 27. okt. 2015, at 15.00, Mirja Kühlewind <[e-mail]> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I didn’t say anything so far because I don’t mind to have a second protocol here, but I personally don’t see this doc as really needed. Effectively we will have two docs that have the same results (a list of features) at the end.
>>> 
>>> I think draft-welzl-taps-transports highlights how many services (or transport features or whatever we want to call them) are lost when we just compile a list as in draft-ietf-taps-transports.
>>> To give a few examples: SCTP: "ordered and unordered delivery within a stream” does not make it clear that you can in fact specify per-message whether ordering matters or not.
>>> In TCP, during the lifetime of a connection, you can change the DSCP value.
>>> In TCP, you can open a connection to listen at one local interface or any; in SCTP, you can specify a list of local interfaces
>>> 
>>> We can debate whether these things are unnecessary details, but they are things that appear in draft-welzl-taps-transports as a result of the systematic approach I’ve taken.
>>> 
>> 
>> For me that would be good feedback for taps-transport, to include these things. We have for each protocol a section on interface(s). We could even include more background text there if needed.
>> 
>> However, for the things you’ve mentioned that’s for me rather a question on the level of detail of certain features. We’ve already discussed that we might need something like ‚aspects‘ for each feature. I believe we decided to not provide more details in this doc because we wanted to move on. However, I also believe that people in this group understand well that in some cases we’ll need more detailed information on the feature. And for me even if we submit and publish the taps-transport as it is, this is not written in stone and we can still say later on, that we rename a feature or split it up or whatever.
> 
> Indeed, taps-transport is just at a slightly higher abstraction layer than draft-welzl-taps-transports.
> 
> 
>> For me that would even be part of the second doc in the charter.
> 
> Here I disagree. I think we need more detail to end up with an implementable system, as in draft-welzl-taps-transports. The second doc in the charter is about narrowing down the services, not adding more detail.
> 
> 
>> Again, I’m okay to have two docs here. I don’t think a second doc is absolutely necessary. An alternative would be to merge both docs… just as a side note. But I’m okay with both, two or one docs.
> 
> I think merging them would get messy.
> 
> 
>>>> I personally find the approach taken in the new doc even more arbitrary and reading this discussion of what should be in and out just underlines this point.
>>> 
>>> Even more arbitrary => could you please explain?
>>> I think the discussion of what should be in and out has absolutely nothing to do with the arbitrariness of the approach taken in the doc.
>> 
>> See above. For me the only question is, how can we make sure we cover the right things and don’t forget important stuff. And in both cases the answer is we can’t.
> 
> Given the RFC text describes well what a protocol offers to the upper layer and how it’s used, my procedure (above) should give you exactly what’s needed.
> 
> 
>> For me analyzing (only) the interfaces, is the more arbitrary approach because the current interfaces are already arbitrary to some extend and that’s exactly what we want to change. But that’s my personal view and there might not be an objective conclusion here.
> 
> This document is not about analyzing only the interfaces: it’s about analyzing RFC text that describes what a protocol offers to the upper layer and how it’s used. Because TCP and SCTP have abstract API descriptions, that makes up more than 90% of this text in case of these two protocols.
> 
> When you say that the current interfaces (which, for the context of draft-welzl-taps-transports, are the abstract interfaces in the RFCs) are "already arbitrary to some extent”, you really criticize the text in the RFC that describes how to use a protocol; then, I think you should be specific and explain what you think is wrong per protocol, and maybe suggest an update or errata. I do think that a lot of thinking has gone into these text bits… even though real-life implementations may diverge from these abstract APIs.
> 
> I also don’t think we want to *change* these interfaces, but describe how to create a generic one that is built upon them.
> 
> 
>>>> From my point of view the taps-transports is ready now. Btw. we did not leave out (hopefully) any features of RTP, we just decided to keep the description very short and only focus in the description on those parts that are actually transport related. 
>>>> 
>>>> I agree that the taps-transport doc is quite long, but for the wg I don’t the the purpose of this doc in having it but in getting it. I mean the process we had so far to get this doc in the right shape was very helpful and I believe we are ready to move on. The only think that is interesting now for the wg is the final list of feature, which is there and ready to use. 
>>>> 
>>>> As a side note, I also believe that other people might be interesting in reading the doc for other reasons than participating in taps because it’s actually a quite nice overview doc now.
>>> 
>>> I agree that it’s a nice document and ready. As for “The only thing interesting for the wg is he final list of features, which is there and ready to use”, see the discussion above: the draft-ietf-taps-transports is a nice and useful survey, but I do not think it is a good basis for an implementable TAPS system, which we eventually want (doc 3).
>> 
>> I don’t have the feeling that the new doc is much better. Important is that the wg knows that these features are not written in stone and we still have to think about the right choices here for any future work. I believe that’s true for both docs.
> 
> I don’t get that; can you give an example?
> 
> Cheers,
> Michael