Re: [Taps] IETF planning

Mirja Kühlewind <> Wed, 28 October 2015 12:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1D2D91B5495 for <>; Wed, 28 Oct 2015 05:23:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.91
X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g0gapzClN8kN for <>; Wed, 28 Oct 2015 05:23:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C31171B5493 for <>; Wed, 28 Oct 2015 05:23:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D4AAD930E; Wed, 28 Oct 2015 13:23:38 +0100 (MET)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id l-31me78MUbr; Wed, 28 Oct 2015 13:23:38 +0100 (MET)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (Postfix) with ESMTPSA id 77324D9304; Wed, 28 Oct 2015 13:23:37 +0100 (MET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Mirja Kühlewind <>
In-Reply-To: <>
Date: Wed, 28 Oct 2015 13:23:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Michael Welzl <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc: Aaron Falk <>, "<> Fairhurst" <>, "" <>, Stein Gjessing <>, Brian Trammell <>
Subject: Re: [Taps] IETF planning
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Oct 2015 12:23:42 -0000

Hi Micheal,

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


> Am 28.10.2015 um 09:05 schrieb Michael Welzl <>:
> 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