Re: [Taps] IETF planning

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

Hi Micheal,

this is only a personal opinion and I do not object to work on this doc.

Mija



> Am 28.10.2015 um 09:05 schrieb Michael Welzl <[e-mail]>:
> 
> Hi Mirja,
> 
> I’m not sure where this discussion is leading us: twice you just say you disagree without giving a reason; then you seem to get kind of hung up on the “no congestion control” bit immediately after quoting my statement:
> 
> **
> 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.e. the service would be "congestion control”, not “no congestion control”. The latter is just what you'd get in the first iteration when working through the UDP usage guidelines.
> 
> 
> I’ll cut most of the text here to try to wrap this up, then answer a particular point, and then get to your conclusion:
> 
> 
>> 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!
> 
> No, you do *not* have to analyze the protocol, as this is not only about interfaces, it’s based on any text in the RFCs that describes what a protocol provides to the upper layer and how it is used. RFC 5405, as an obvious source of text on how to use UDP and what it provides to the layer above, tells us:
> "It is important to stress
>   that an application SHOULD perform congestion control over all UDP
>   traffic it sends to a destination, independently from how it
>   generates this traffic."
> 
> So, once we include UDP, we get congestion control as a service for TCP and SCTP, from this text.
> 
> 
>> 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.
> 
> That’s not what I did. I strictly used only text that talks about what a protocol provides to the upper layer and how it is used.
> 
> 
>> 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!
> 
> Noting your statement from a previous email: "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 agree and think we should just move on.
> 
> Cheers,
> Michael