Re: [Taps] IETF planning

Michael Welzl <michawe@ifi.uio.no> Wed, 28 October 2015 08:05 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C4E1ACE9F for <taps@ietfa.amsl.com>; Wed, 28 Oct 2015 01:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.61
X-Spam-Level:
X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGrlX71rwsyV for <taps@ietfa.amsl.com>; Wed, 28 Oct 2015 01:05:22 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41FC1B3709 for <taps@ietf.org>; Wed, 28 Oct 2015 01:05:21 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1ZrLjR-0004Pa-9A; Wed, 28 Oct 2015 09:05:17 +0100
Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1ZrLjQ-0004ex-P9; Wed, 28 Oct 2015 09:05:17 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <6507117D-40F1-48FF-ADB0-F624C33731FD@tik.ee.ethz.ch>
Date: Wed, 28 Oct 2015 09:05:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <029C74BE-7B33-4DC2-B449-07BACCCBDD2A@ifi.uio.no>
References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <B36B9E5E-0EB5-418A-A6A1-E103C8ECF500@ifi.uio.no> <CCC80AEF-66CD-4497-A374-2ED89DF4FA17@trammell.ch> <CAD62q9XQMSyuG_=HYjXKe12iE=-F3HasXqrmJs+RAQeBZbddCQ@mail.gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <CAD62q9XjebXmRHUebJLrd35=PnrLPGCZFv4LBO5omYBh2J+72Q@mail.gmail.com> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <CAD62q9WAaHZ_OrueAa5u0rMuZGssC0mR+3gVWEBQ7DmDMm0cAQ@mail.gmail.com> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <2DC75956-A94E-40DE-8A40-B8A6BABE8ED8@ifi.uio.no> <782D504B-656F-4C98-9790-A2B2FFC36473@tik.ee.ethz.ch> <3C8D178C-CEF2-4395-B4B7-2FB80F39F733@ifi.uio.no> <6507117D-40F1-48FF-ADB0-F624C33731FD@tik.ee.ethz.ch>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
X-Mailer: Apple Mail (2.2104)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 34438 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: A523ABB0D170B1E83B41259904F3710D291F14FE
X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 1988 max/h 14 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/baCotDYakSLkc_2bbcCGH-8budo>
Cc: Aaron Falk <aaron.falk@gmail.com>, "<gorry@erg.abdn.ac.uk> Fairhurst" <gorry@erg.abdn.ac.uk>, "taps@ietf.org" <taps@ietf.org>, Stein Gjessing <steing@ifi.uio.no>, Brian Trammell <ietf@trammell.ch>
Subject: Re: [Taps] IETF planning
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2015 08:05:24 -0000

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