From nobody Mon May 4 07:36:36 2015 Return-Path: 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 A8B6A1A1A79 for ; Mon, 4 May 2015 07:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 3vH7n3-cyoYr for ; Mon, 4 May 2015 07:36:32 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EFA1A00FA for ; Mon, 4 May 2015 07:36:32 -0700 (PDT) Received: by iejt8 with SMTP id t8so131169791iej.2 for ; Mon, 04 May 2015 07:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=qRpPiRGg8NOJce5HlwaqAMeZpNAKKdMdoAivlnnO7KM=; b=UIXwcL0Cu7OdBgzdHGf48VAVgPpysRLCTmN/ei1HMNMNWezVyJqc7pPm6z+DEusV4j u/tHSNrSavUi4P1x/KELl1RBp/qjtgYL2NHn8XL+M1RbEFL8U1pKnz/JuhMlpVEGpWQ8 dKEgJcFkecH/JMRGlohRqjqHEGWpkwJyleJwklewIX+Ae2RlnPoXrki1z7bH1gIu2Vbc W+JUEM7kg9tk6j9hUzsj2eKdASgIJwW8/jNfnfjImZI6VaIWts1f8VkpdP++Li/45QRh CrzcdWW/IGh7ZATlA+/OWaHdwbDPLRaflfMy5fag2SyzyG4hpV1LTEgKyPv87hD4i0hp FTUg== MIME-Version: 1.0 X-Received: by 10.107.7.196 with SMTP id g65mr27822243ioi.28.1430750191757; Mon, 04 May 2015 07:36:31 -0700 (PDT) Received: by 10.64.112.97 with HTTP; Mon, 4 May 2015 07:36:31 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 May 2015 10:36:31 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Taps] draft minutes from taps meeting in Dallas - input due by May 5 X-BeenThere: taps@ietf.org 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: Mon, 04 May 2015 14:36:35 -0000 Reminder: please take a look at the minutes below as they will be submitted tomorrow. Thanks. --aaron On Thu, Apr 30, 2015 at 3:47 PM, Aaron Falk wrote: > Please provide comments and corrections by May 5th. Many thanks to > Wes Eddy for great notes. > > --aaron > > > Transport Services (TAPS) Working Group > Monday, March 23, 2015 1300 - 1500 CDT > Parisian Room > > Chair's Slides (5 min) > Aaron Falk > > Draft Status and badgering of volunteers (15 min) > draft-ietf-taps-transports-03 > Brian Trammell > > Applications view of transport abstractions (30 min) > RTCWeb data channel services - Michael Tuexen > Multisource video / TV - Marie-Jose Montpetit > Discussion > > Two or three transport feature matrices (45 min) > Gorry Fairhurst > Michael Welzl > Dave Thaler > Discussion > > > > The room was very full of people. > > Aaron explained the agenda for the meeting. > > Aaron reviewed the schedule and charter for the working group. > The initial informational document is what we're talking about today. > It probably won't be done by June, but may be "just 1 IETF behind". > > > ---- > > Brian Trammell talked about the status of the document describing > transport services. > > Brian described the changes made in the -03 revision, since the last > meeting. > > The list of components described in -03 were reviewed. > > Planned changes for the -04 revision were discussed, including some > additional protocol contributions (RTP, HTTP, websockets) that people > have volunteered to add text for, and some (MPTCP, TLS/DTLS) that > Brian is looking for people to work on. > > - Mirja pointed out that Simone from Simula already volunteered > - Kevin Fall will do TLS/DTLS > > Brian thinks we could only be "1/2 an IETF behind", if people can > contribute text in the next few weeks. The section 4 table will be > filled in in a revision -07 and in July it could be in WGLC, if the > work can get done on the mailing list. > > About a dozen people indicated they're willing to do a thorough review > in this timeframe, when Aaron asked. > > Brian reviewed "how to contribute", including the github URL: > https://github.com/britam/taps-transports > > - Karen Nielson asked about the intended scope of "API" > > - Brian said this is a question for the room > > - Mirja answered that the current APIs are described as a point of > reference, but that the interface definition coming in the future is > separate > > - The intention of this effort is not to obsolete existing APIs, but > to make it easier for people building applications to use new > mechanisms when they exist and can be used, without making them do > probing, etc. on their own (described by Aaron). > > - Karen clarified her question is about whether information about > other APIs is something we want for this? > > - Mirja said contribute it, and it may or may not be included > > - Gorry said that maybe this would be useful as a separate I-D and > that only a few paragraphs would be the goal here in the present > document > > - Michael Welzl agreed with Aaron, but said we need a > rule/guideline/logic for what to include or not, and that some > things shouldn't be exposed to the app (this comment "opened up a > can of worms") > > - Joe Hildebrand thinks its useful to document things the transport > people know about but the apps people don't. > > He also has a preference to save the discussion for who is worthy > enough to get access to certain types of information until later > > - Keith Moore is concerned about notion of hiding complexity from > applications, and wants it clear that applications need predictable > behavior from lower layers, and that "smart" API may have complex > behavior and not be very predictable > > - Mirja suggested the network (below the transport) can be responsible > for predictable performance, and that the features (step 2) will be > used to decide what should be exposed > > - Brian tried to explain difference between components and features, > along with common implementations of those things, and the need to > be careful about the distinctions in order to avoid confusion > > - Michael Welzl says "in case of doubt, make the list longer now", > removing things is not desirable. > > ---- > Michael Tuexen talked about RTCWEB's API > > It's not set in stone, but being worked on between W3C and IETF for > javascript Browser-to-browser data flow and signaling can go between > them via servers. > > Michael described the protocol stack used, and noted that the API > doesn't expose all of them to the application (for instance, ICE > things happen without the application being involved with details) > > Data channel concepts, abilities, and properties were explained. > Michael described the differences between what SCTP provides and what > the user has available via data channels in the RTCWEB API > > - Keith Moore commented that he had a client whose flows shared fate > and found that this API couldn't be used to do that, and that it was > easier to do an IP tunnel underneath this API. It's nice and > pretty, but not that useful. There's a lot bigger world than web > browsers and javascript. > > - Michael agreed that the scope is limited > > ---- > Marie-Jose discussed multi-source video and (IP)TV. > > She reviewed the -03 draft from her perspective of video. > > Definitions and uses for multi-source video were discussed along with > issues people experience in doing this > > RTP and HTTP are considered "transport" by many people (compared to > UDP and TCP). She suggests discussing whether to add these to the > draft. > > Definition of reliable transport -- suggests that a better word is > needed > > - Christian Huitema from Microsoft said that TCP doesn't mean that > you'll always succeed, but that it will try or fail > > - Marie-Jose does not disagree with this > > - Dave Crocker - largest point is that when different communities use > the same word differently it creates problem. suggests "usability" > as a term > > - Someone from CableLabs asked how this is different than QoS > > - Marie-Jose said that QoS and QoE are things she will not get into > > - David Black strongly agrees with Quality of Experience; if the video > won't render, the user is not happy. codec + network determine QoE. > > - Marie: it's called "engineering=E2=80=9D. > > - David: that's this organization's middle name. > > - Aaron said that "timely delivery" is fundamental and maybe not > QoS/QoE > > - Marie said that delivering in time as well as quality are different > layers > > - Christian Huitema from Microsoft said that having the application > express what it wants (FEC or retransmission) would be useful > > - Dave Crocker contemplating terms and likes QoE > > - Toerless Eckert talked about packets in a video stream having > different priorities (you don't want to lose I-frames) ... similar > things in markets, IoT, etc. > > - Marie suggested supporting exposing and querying the capabilities of > the lower layers e.g. IEEE 1905. > > - Matt Mathis is in complete agreement. History littered with stories > about apps reinventing "broken almost TCP or something". both a > simple and a rich way for applications to use the API are necessary > > - Keith Moore totally agrees. applications could get more predictable > behavior by forcing them to make decisions. > > Library developers writing code for others to reuse are a small > number of people, and most sane developers will reuse libraries > rather than redo things from scratch > > - Jana Iyengar said to think about exposing info to functions rather > than to protocols, because the functions may exist in multiple > layers. He does not think QoE is a good term. > > - Mirja and Brian T both wanted to make the point that some things can > be exposed (like TCP working but UDP not, over a given path) to save > duplicated effort > > > ---- > Gorry Fairhurst talked about set of transport service features > > He showed the table from the draft of protocol components that offer API > features. > > - Jana asked if we were going to do the trimming here. > > - Gorry suggested 2 lists: > - things done in transport > - things offered to upper layer > > - Jana suggests a filter on top for things that are actually deployed > (i.e. DCCP, UDP-Lite, etc don't count) > > - Mirja suggests we discuss ECN because the job wasn't done well in > getting it running, and that checks aren't properly done in the > transport about whether it's working so that's why it can be exposed > > - Gorry said that it leads to mechanics above > > - Mirja said that's why they should be in the transport already > > - Christian (Microsoft) said that some functions are missing. > congestion control and security points. > > - Gorry said that he's looking for volunteers on this. > > - Magnus reacting to ECN, he worked on ECN for RTP and said it does > need to be tied into the higher layers, for instance the codec or > something above RTP is what needs to deal with it. > > - Magnus also pointed out that some multicast/RMT protocols are used > in unicast world. > > - Brian Adamson will offer text on this. > > - Colin Perkins said this is a restrictive/traditional view of > transports and that RTP should go in here. Colin will help Varun > write something here. > > - Jana Iyengar said this is what he meant by functions versus > protocols earlier > > - Keith Moore asked if there was time to discuss if this was all a bad > idea. He needs to discuss this on the mailing list. > > - Mark Nottingham asked how to account for differences in quality or > properties of different implementations. HTTP2 was remapped onto > the same transport protocol and has vastly different properties. > > - Gorry said it's just documenting what's out there, in order to have > the discussion later. > > - Keith said that adding more layers of abstraction will not make > things better. He spent 5 years trying to build an API similar, and > path selection was one feature that would have needed 10 more > bullets to explain why the application needs to know what its IP > addresses are. > > - Joe Hildebrand with IAB hat on is interested in seeing work progress > by doing at least the first and second step, and maybe Experimental > third step, but sees architectural value in at least first 2 steps. > > - Chris Newman sees visibility as missing in the list because the > logging and auditing of all the knobs of the lower layers is > important and applications should be able to get that. > > - Gorry asked if this influences selection of transport > > - Chris says absolutely, and totally disagrees with Mirja's statement > about just expressing the needs and letting the transport be > selected; he would be unable to use that kind of system, he wants to > know what was selected and all the details. > > - Brian Trammell - we need to write down visibility of what's going on > inside the transport as a requirement and move on (room seems to > agree) > > - Matt Mathis - browser people have abstracted everything away about > the network, and idempotence is important (and not understood by > web) but should be on the list somehow > > - Phil Halam-Baker done security, apps, most parts of stack, and says > to never ever tell someone they can't do something. there are two > ways to look at the problem, one is the sockets api, or just dns and > service names and that's all. More abstraction *can* help, but not > just a little, way more abstraction > > - Colin Perkins said that some applications need to know "how well it > worked perfectly". was surprised that some primitive for building > nat traversal or discovering middleboxes wasn't on the list. > > - Brian suggests spud BoF as place to discuss this. > > - Colin said there's also talking to middleboxes for things like > partial encryption, decoupled congestion control loops, etc. > > - Toerless asked about naming. > > - Gorry said it varies between transports. > > - Toerless said waterfall process to do APIs at the end is not really > working, and there should be compromise position that we'll do APIs > at the end and track inputs to it (e.g. via wiki) in the meantime > > - Dave Thaler said there's a lot of angst around the notion of APIs, > and there are vastly divergent views. it's useful to know what RMT > ran into when they did this decomposition of building blocks for > multicast services > > - Jana: +1 to what Dave just said > > - Mirja: working group is not chartered to hide information, but to > expose more; she asks "why?" when people ask for information so that > she can make sure they're getting the right information > > - Chis Newman suggests secure by default as a philosophy. From nobody Tue May 26 05:41:23 2015 Return-Path: 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 629B91B2B22; Tue, 26 May 2015 05:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 jmyH4aKQGPzL; Tue, 26 May 2015 05:41:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 306C01A1E0B; Tue, 26 May 2015 05:41:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 05:41:18 -0700 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 12:41:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services Working Group of the IETF. Title : Services provided by IETF transport protocols and congestion control mechanisms Authors : Godred Fairhurst Brian Trammell Mirja Kuehlewind Filename : draft-ietf-taps-transports-04.txt Pages : 35 Date : 2015-05-26 Abstract: This document describes services provided by existing IETF protocols and congestion control mechanisms. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 26 06:26:17 2015 Return-Path: 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 D9ACE1B2BE7 for ; Tue, 26 May 2015 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Tm7Gd3o_rIJK for ; Tue, 26 May 2015 06:26:12 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id E83321B2C16 for ; Tue, 26 May 2015 06:25:39 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2:41ba:8843:3f44:1b1b] (unknown [IPv6:2001:470:26:9c2:41ba:8843:3f44:1b1b]) by trammell.ch (Postfix) with ESMTPSA id 9B6721A0567 for ; Tue, 26 May 2015 15:25:37 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_1EAD2F40-C7DE-4C76-81E8-08586F0D7A55"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 15:25:37 +0200 Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> To: taps WG X-Mailer: Apple Mail (2.2098) Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Tue, 26 May 2015 13:26:15 -0000 --Apple-Mail=_1EAD2F40-C7DE-4C76-81E8-08586F0D7A55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've submitted revision -04 of taps-transports, which includes: (1) a new section on HTTP as a pseudotransport over TCP (thanks, Dragana = Damjanovic!) (2) a new section on NORM (thanks, Brian Adamson!) (3) frontmatter in Section 4 normalizing and categorizing the transport = protocol components; please review this and suggest necessary or useful = changes for using this as background for selecting taps features. Next up is completing the outstanding sections on transports and = transport-like things, of which we have four: 3.2 MP-TCP 3.7 RTP 3.9 TLS/DTLS pseudotransport 3.11 WebSockets We hope to get an -05 with text for these out in the next couple of = weeks, and will follow up with contributors for each of these sections = shortly. Thanks, cheers, Brian (for the editors of taps-transports) > On 26 May 2015, at 14:41, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services Working Group of = the IETF. >=20 > Title : Services provided by IETF transport protocols = and congestion control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-04.txt > Pages : 35 > Date : 2015-05-26 >=20 > Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-taps-transports-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_1EAD2F40-C7DE-4C76-81E8-08586F0D7A55 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVZHRRAAoJENt3nsOmbNJc9PgH/2/2SyaWaTSG+fEjcwCiQwfY 8O0Mfe3hzjmNeA9AwEpu6g33g41JMeMXT6qWNvocFa/AHVi9kts7spGq+OpMWdTm 7GtqxUb9YveZR0opoQNBHSdDhG6fZjA8QAX6XKb14rUbix4ZA+vL4Sc1eOKOuu1Q jLK5nIdmUW4kTVL/c7dibEtc5zjuljpl0RHqcE5wQer680Zt4rMsMV2mU2M0ai+m CcFpizngPzq15I1t5+R8HQYTNr+cP+HjinLEQQaD5Yg/qvh7NGzGH7bUT7Vni3iz wDdAcwrB5r9M4AG/jd1zQ4mjVtuIMO/YiBu9K6VQYsE5j8/Km9St1AATNhZ5Ics= =G+oa -----END PGP SIGNATURE----- --Apple-Mail=_1EAD2F40-C7DE-4C76-81E8-08586F0D7A55-- From nobody Tue May 26 15:36:30 2015 Return-Path: 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 79F531B32CD for ; Tue, 26 May 2015 15:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 lg6SP-x7YnQh for ; Tue, 26 May 2015 15:36:27 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5471B32C8 for ; Tue, 26 May 2015 15:36:27 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t4QMaHV8010505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 26 May 2015 15:36:17 -0700 (PDT) Message-ID: <5564F560.3080507@isi.edu> Date: Tue, 26 May 2015 15:36:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brian Trammell , taps WG References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Tue, 26 May 2015 22:36:28 -0000 Hi, Brian (et al.), On 5/26/2015 6:25 AM, Brian Trammell wrote: ... > (3) frontmatter in Section 4 normalizing and categorizing the > transport protocol components; please review this and suggest necessary > or useful changes for using this as background for selecting taps features. I like the definitions but IMO the protocol descriptions don't follow the definitions. I.e., I agree that a transport protocol service (TPS) is a feature or capability made available to the app, and that a transport protocol component (TPC) is an implementation of such a feature. I realize I sound like a broken record, but the descriptions of the protocols herein still does not match the definition of TPS or TPC. E.g., for TCP, none of the following is exposed to the user: - segmentation - flow control - congestion control - error detection At best, the effects of the above are exposed to the user in very indirect fashion, certainly not as a "service" that can be used. In addition, TCP provides all of the following services (the latter two depending on being supported), which are not listed: - PUSH - URG - authentication (via TCP-AO or legacy TCP MD5) - control over user timeout (UTO option) This continues to be a pervasive issue in this doc, i.e., not just for this protocol. Joe From nobody Tue May 26 23:22:22 2015 Return-Path: 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 E90891A1A2F for ; Tue, 26 May 2015 23:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 w1YujTDZFpTS for ; Tue, 26 May 2015 23:22:17 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196A41A0399 for ; Tue, 26 May 2015 23:22:17 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so6562321igb.0 for ; Tue, 26 May 2015 23:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:mime-version:thread-index:date:message-id:subject:to :content-type:content-transfer-encoding; bh=5FePDAaDptmtEsommZxGQnWchGX2v83a+TAf2a0Umt8=; b=NI3bwrTIxjFRxtED4k8/2ithl8jPcYrqBK+9bHiptDibBTwdUu3DDxeNvQ2j9SKD6X Hdj5FjGwo8oDGKkfnFHMYaUD4OnUy6sqNqo1KWgTG1bRZzW0AHSg+5Dj3yQP+LyYiijl vr1nXzjXflZE+xsmDQU+FsaMvOheWp0hwH2g4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type:content-transfer-encoding; bh=5FePDAaDptmtEsommZxGQnWchGX2v83a+TAf2a0Umt8=; b=bEHQGBaZ5sOKWDB7EjVVk3PXb29z+YNNPmyXLmoEs2LYsyYUdAhQg+8HX0arCauLmJ ir88p89SE+gTb5a1y67os24VrO2Rs6c6DkejYwtrP4myc60fLgT9LUQOYg4OtghAsn5N Se/lgZVRnnqSfeF/AHoR3iqZvZRS4wBxjDSKaBwf4LUW8bNZ3vhwbw1KOhID+uQmf4gY ZDusHC0YVYujOTHY1XLQJ+5i3o9+g/LDM0vYQ4Uzgr5WLAdcppQUKWrICvrpDDM0Jwxj dS1SqJ4TwXtB1RXPpIADcIkMus5atQzo8R3kab5oOPYGm3piduIpfQ5tICJ3Eb//W2UP 41Ow== X-Gm-Message-State: ALoCoQlbNk+StOgOqcZ3+gH6upZV9+0pYBktyW78Q/lqAnU8Icy3ALVOSRh8VQ1+EY6UbgIWUto+iyM41boFs8RJ58ZZm8TzFcyg7d8hjjZHpZC4LdoQo3Y= X-Received: by 10.50.109.138 with SMTP id hs10mr1865265igb.48.1432707736556; Tue, 26 May 2015 23:22:16 -0700 (PDT) From: Karen Elisabeth Egede Nielsen MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCYRXX2MMOgX9xxRhmK0YY7Jlc+Gw== Date: Wed, 27 May 2015 08:22:15 +0200 Message-ID: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> To: Aaron Falk , taps@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Subject: [Taps] API richness X-BeenThere: taps@ietf.org 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, 27 May 2015 06:22:21 -0000 HI, As an example of presently relied on API richness, then the following parameters of TCP/SCTP are parameters that today typically are tuned by signaling applications on a per connection/association basis or an a per signaling application basis. Here multiple signaling applications may share the same TCP/SCTP transport layer instance (SW block) but may configure their usage of the protocol (of their TCP connection/SCTP assoc differently). In terms of Taps terminology I think this corresponds to a shared " Transport Service Instance". I may note that the parameters even typically are exposed at O&M level as configurable by the Operators, here even possibly on an association/connection basis. For TCP: RTO_MIN, RTO_MAX, MAXRT, SND BUF, RCV BUF, Delay_ack, No_delay, TCP keep alive settings, For SCTP: RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, No_delay, HBI, Association.Max.Retrans, Path.Max.Retrans, There are other parameters as well that are tuned on a per TCP connection/SCTP association basis, but this is in more special cases. For example TCP (and even SCTP) ABC slow start parameter L, TCP time wait period. The above parameters relates only to the core TCP and SCTP functions relied on by signaling applications. Speaking additional features, e.g., ECN, special SCTP features management opens up for more of course. The CC algorithm today is not tuned - default is used - in the future this should be different, but I think that there is general agreement that such should indeed be tuned at the TAPS API. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Aaron Falk >Sent: Monday, May 04, 2015 4:37 PM >To: taps@ietf.org >Subject: Re: [Taps] draft minutes from taps meeting in Dallas - input due >by >May 5 > >Reminder: please take a look at the minutes below as they will be submitte= d >tomorrow. Thanks. > >--aaron > >On Thu, Apr 30, 2015 at 3:47 PM, Aaron Falk wrote: >> Please provide comments and corrections by May 5th. Many thanks to >> Wes Eddy for great notes. >> >> --aaron >> >> >> Transport Services (TAPS) Working Group Monday, March 23, 2015 1300 - >> 1500 CDT Parisian Room >> >> Chair's Slides (5 min) >> Aaron Falk >> >> Draft Status and badgering of volunteers (15 min) >> draft-ietf-taps-transports-03 >> Brian Trammell >> >> Applications view of transport abstractions (30 min) >> RTCWeb data channel services - Michael Tuexen >> Multisource video / TV - Marie-Jose Montpetit >> Discussion >> >> Two or three transport feature matrices (45 min) >> Gorry Fairhurst >> Michael Welzl >> Dave Thaler >> Discussion >> >> >> >> The room was very full of people. >> >> Aaron explained the agenda for the meeting. >> >> Aaron reviewed the schedule and charter for the working group. >> The initial informational document is what we're talking about today. >> It probably won't be done by June, but may be "just 1 IETF behind". >> >> >> ---- >> >> Brian Trammell talked about the status of the document describing >> transport services. >> >> Brian described the changes made in the -03 revision, since the last >> meeting. >> >> The list of components described in -03 were reviewed. >> >> Planned changes for the -04 revision were discussed, including some >> additional protocol contributions (RTP, HTTP, websockets) that people >> have volunteered to add text for, and some (MPTCP, TLS/DTLS) that >> Brian is looking for people to work on. >> >> - Mirja pointed out that Simone from Simula already volunteered >> - Kevin Fall will do TLS/DTLS >> >> Brian thinks we could only be "1/2 an IETF behind", if people can >> contribute text in the next few weeks. The section 4 table will be >> filled in in a revision -07 and in July it could be in WGLC, if the >> work can get done on the mailing list. >> >> About a dozen people indicated they're willing to do a thorough review >> in this timeframe, when Aaron asked. >> >> Brian reviewed "how to contribute", including the github URL: >> https://github.com/britam/taps-transports >> >> - Karen Nielson asked about the intended scope of "API" >> >> - Brian said this is a question for the room >> >> - Mirja answered that the current APIs are described as a point of >> reference, but that the interface definition coming in the future is >> separate >> >> - The intention of this effort is not to obsolete existing APIs, but >> to make it easier for people building applications to use new >> mechanisms when they exist and can be used, without making them do >> probing, etc. on their own (described by Aaron). >> >> - Karen clarified her question is about whether information about >> other APIs is something we want for this? >> >> - Mirja said contribute it, and it may or may not be included >> >> - Gorry said that maybe this would be useful as a separate I-D and >> that only a few paragraphs would be the goal here in the present >> document >> >> - Michael Welzl agreed with Aaron, but said we need a >> rule/guideline/logic for what to include or not, and that some >> things shouldn't be exposed to the app (this comment "opened up a >> can of worms") >> >> - Joe Hildebrand thinks its useful to document things the transport >> people know about but the apps people don't. >> >> He also has a preference to save the discussion for who is worthy >> enough to get access to certain types of information until later >> >> - Keith Moore is concerned about notion of hiding complexity from >> applications, and wants it clear that applications need predictable >> behavior from lower layers, and that "smart" API may have complex >> behavior and not be very predictable >> >> - Mirja suggested the network (below the transport) can be responsible >> for predictable performance, and that the features (step 2) will be >> used to decide what should be exposed >> >> - Brian tried to explain difference between components and features, >> along with common implementations of those things, and the need to >> be careful about the distinctions in order to avoid confusion >> >> - Michael Welzl says "in case of doubt, make the list longer now", >> removing things is not desirable. >> >> ---- >> Michael Tuexen talked about RTCWEB's API >> >> It's not set in stone, but being worked on between W3C and IETF for >> javascript Browser-to-browser data flow and signaling can go between >> them via servers. >> >> Michael described the protocol stack used, and noted that the API >> doesn't expose all of them to the application (for instance, ICE >> things happen without the application being involved with details) >> >> Data channel concepts, abilities, and properties were explained. >> Michael described the differences between what SCTP provides and what >> the user has available via data channels in the RTCWEB API >> >> - Keith Moore commented that he had a client whose flows shared fate >> and found that this API couldn't be used to do that, and that it was >> easier to do an IP tunnel underneath this API. It's nice and >> pretty, but not that useful. There's a lot bigger world than web >> browsers and javascript. >> >> - Michael agreed that the scope is limited >> >> ---- >> Marie-Jose discussed multi-source video and (IP)TV. >> >> She reviewed the -03 draft from her perspective of video. >> >> Definitions and uses for multi-source video were discussed along with >> issues people experience in doing this >> >> RTP and HTTP are considered "transport" by many people (compared to >> UDP and TCP). She suggests discussing whether to add these to the >> draft. >> >> Definition of reliable transport -- suggests that a better word is >> needed >> >> - Christian Huitema from Microsoft said that TCP doesn't mean that >> you'll always succeed, but that it will try or fail >> >> - Marie-Jose does not disagree with this >> >> - Dave Crocker - largest point is that when different communities use >> the same word differently it creates problem. suggests "usability" >> as a term >> >> - Someone from CableLabs asked how this is different than QoS >> >> - Marie-Jose said that QoS and QoE are things she will not get into >> >> - David Black strongly agrees with Quality of Experience; if the video >> won't render, the user is not happy. codec + network determine QoE. >> >> - Marie: it's called "engineering=E2=80=9D. >> >> - David: that's this organization's middle name. >> >> - Aaron said that "timely delivery" is fundamental and maybe not >> QoS/QoE >> >> - Marie said that delivering in time as well as quality are different >> layers >> >> - Christian Huitema from Microsoft said that having the application >> express what it wants (FEC or retransmission) would be useful >> >> - Dave Crocker contemplating terms and likes QoE >> >> - Toerless Eckert talked about packets in a video stream having >> different priorities (you don't want to lose I-frames) ... similar >> things in markets, IoT, etc. >> >> - Marie suggested supporting exposing and querying the capabilities of >> the lower layers e.g. IEEE 1905. >> >> - Matt Mathis is in complete agreement. History littered with stories >> about apps reinventing "broken almost TCP or something". both a >> simple and a rich way for applications to use the API are necessary >> >> - Keith Moore totally agrees. applications could get more predictable >> behavior by forcing them to make decisions. >> >> Library developers writing code for others to reuse are a small >> number of people, and most sane developers will reuse libraries >> rather than redo things from scratch >> >> - Jana Iyengar said to think about exposing info to functions rather >> than to protocols, because the functions may exist in multiple >> layers. He does not think QoE is a good term. >> >> - Mirja and Brian T both wanted to make the point that some things can >> be exposed (like TCP working but UDP not, over a given path) to save >> duplicated effort >> >> >> ---- >> Gorry Fairhurst talked about set of transport service features >> >> He showed the table from the draft of protocol components that offer >> API features. >> >> - Jana asked if we were going to do the trimming here. >> >> - Gorry suggested 2 lists: >> - things done in transport >> - things offered to upper layer >> >> - Jana suggests a filter on top for things that are actually deployed >> (i.e. DCCP, UDP-Lite, etc don't count) >> >> - Mirja suggests we discuss ECN because the job wasn't done well in >> getting it running, and that checks aren't properly done in the >> transport about whether it's working so that's why it can be exposed >> >> - Gorry said that it leads to mechanics above >> >> - Mirja said that's why they should be in the transport already >> >> - Christian (Microsoft) said that some functions are missing. >> congestion control and security points. >> >> - Gorry said that he's looking for volunteers on this. >> >> - Magnus reacting to ECN, he worked on ECN for RTP and said it does >> need to be tied into the higher layers, for instance the codec or >> something above RTP is what needs to deal with it. >> >> - Magnus also pointed out that some multicast/RMT protocols are used >> in unicast world. >> >> - Brian Adamson will offer text on this. >> >> - Colin Perkins said this is a restrictive/traditional view of >> transports and that RTP should go in here. Colin will help Varun >> write something here. >> >> - Jana Iyengar said this is what he meant by functions versus >> protocols earlier >> >> - Keith Moore asked if there was time to discuss if this was all a bad >> idea. He needs to discuss this on the mailing list. >> >> - Mark Nottingham asked how to account for differences in quality or >> properties of different implementations. HTTP2 was remapped onto >> the same transport protocol and has vastly different properties. >> >> - Gorry said it's just documenting what's out there, in order to have >> the discussion later. >> >> - Keith said that adding more layers of abstraction will not make >> things better. He spent 5 years trying to build an API similar, and >> path selection was one feature that would have needed 10 more >> bullets to explain why the application needs to know what its IP >> addresses are. >> >> - Joe Hildebrand with IAB hat on is interested in seeing work progress >> by doing at least the first and second step, and maybe Experimental >> third step, but sees architectural value in at least first 2 steps. >> >> - Chris Newman sees visibility as missing in the list because the >> logging and auditing of all the knobs of the lower layers is >> important and applications should be able to get that. >> >> - Gorry asked if this influences selection of transport >> >> - Chris says absolutely, and totally disagrees with Mirja's statement >> about just expressing the needs and letting the transport be >> selected; he would be unable to use that kind of system, he wants to >> know what was selected and all the details. >> >> - Brian Trammell - we need to write down visibility of what's going on >> inside the transport as a requirement and move on (room seems to >> agree) >> >> - Matt Mathis - browser people have abstracted everything away about >> the network, and idempotence is important (and not understood by >> web) but should be on the list somehow >> >> - Phil Halam-Baker done security, apps, most parts of stack, and says >> to never ever tell someone they can't do something. there are two >> ways to look at the problem, one is the sockets api, or just dns and >> service names and that's all. More abstraction *can* help, but not >> just a little, way more abstraction >> >> - Colin Perkins said that some applications need to know "how well it >> worked perfectly". was surprised that some primitive for building >> nat traversal or discovering middleboxes wasn't on the list. >> >> - Brian suggests spud BoF as place to discuss this. >> >> - Colin said there's also talking to middleboxes for things like >> partial encryption, decoupled congestion control loops, etc. >> >> - Toerless asked about naming. >> >> - Gorry said it varies between transports. >> >> - Toerless said waterfall process to do APIs at the end is not really >> working, and there should be compromise position that we'll do APIs >> at the end and track inputs to it (e.g. via wiki) in the meantime >> >> - Dave Thaler said there's a lot of angst around the notion of APIs, >> and there are vastly divergent views. it's useful to know what RMT >> ran into when they did this decomposition of building blocks for >> multicast services >> >> - Jana: +1 to what Dave just said >> >> - Mirja: working group is not chartered to hide information, but to >> expose more; she asks "why?" when people ask for information so that >> she can make sure they're getting the right information >> >> - Chis Newman suggests secure by default as a philosophy. > >_______________________________________________ >Taps mailing list >Taps@ietf.org >https://www.ietf.org/mailman/listinfo/taps From nobody Wed May 27 06:02:52 2015 Return-Path: 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 D46551A88BE for ; Wed, 27 May 2015 06:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_5SscSacyr3 for ; Wed, 27 May 2015 06:02:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C59D1A88C6 for ; Wed, 27 May 2015 06:02:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3B2D9D9303; Wed, 27 May 2015 15:02:45 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WBzdclzMtcSR; Wed, 27 May 2015 15:02:44 +0200 (MEST) Received: from [192.168.130.36] (chello084113020103.2.12.vie.surfer.at [84.113.20.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BFA64D9305; Wed, 27 May 2015 15:02:44 +0200 (MEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <5564F560.3080507@isi.edu> Date: Wed, 27 May 2015 15:02:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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, 27 May 2015 13:02:51 -0000 Hi Joe, I agree. This is a working document and we are still in the phase of = collecting data while the next step is to discuss which things that are = currently listed must/should be listed or not and also which of the = things must/should be exposed to the app. However, I think we are on the write track for the TSC because these are = thing that are implemented independent of the question if these things = should be exposed to the app or not. However, features in contrast = should really only be the things that should be exposed. The list in = section 4 currently copies everything from above and we need to have the = discuss now what should stay there and what not.=20 Mirja > Am 27.05.2015 um 00:36 schrieb Joe Touch : >=20 > Hi, Brian (et al.), >=20 > On 5/26/2015 6:25 AM, Brian Trammell wrote: > ... >> (3) frontmatter in Section 4 normalizing and categorizing the >> transport protocol components; please review this and suggest = necessary >> or useful changes for using this as background for selecting taps = features. >=20 > I like the definitions but IMO the protocol descriptions don't follow > the definitions. >=20 > I.e., I agree that a transport protocol service (TPS) is a feature or > capability made available to the app, and that a transport protocol > component (TPC) is an implementation of such a feature. >=20 > I realize I sound like a broken record, but the descriptions of the > protocols herein still does not match the definition of TPS or TPC. >=20 > E.g., for TCP, none of the following is exposed to the user: > - segmentation > - flow control > - congestion control > - error detection > At best, the effects of the above are exposed to the user in very > indirect fashion, certainly not as a "service" that can be used. >=20 > In addition, TCP provides all of the following services (the latter = two > depending on being supported), which are not listed: > - PUSH > - URG > - authentication (via TCP-AO or legacy TCP MD5) > - control over user timeout (UTO option) >=20 > This continues to be a pervasive issue in this doc, i.e., not just for > this protocol. >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed May 27 10:20:44 2015 Return-Path: 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 729EA1A8828 for ; Wed, 27 May 2015 10:20:43 -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 qclPoy_XYcBz for ; Wed, 27 May 2015 10:20:41 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960C51A882B for ; Wed, 27 May 2015 10:20:41 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4RHK9bA024510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2015 10:20:11 -0700 (PDT) Message-ID: <5565FCC9.1040905@isi.edu> Date: Wed, 27 May 2015 10:20:09 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Mirja_K=FChlewind?= References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> In-Reply-To: <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t4RHK9bA024510 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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, 27 May 2015 17:20:43 -0000 On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: > Hi Joe, > > I agree. This is a working document and we are still in the phase of > collecting data while the next step is to discuss which things that are > currently listed must/should be listed or not and also which of the > things must/should be exposed to the app. To be clear, can you clarify the focus?: - what IS/IS NOT (i.e., current requirements) - what WILL BE/WILL NOT BE (i.e., future goals) AFAICT, this is about IS/IS NOT. With that in mind, it should not be necessary to "collect data" and then decide later what is exposed or not. > However, I think we are on the write track for the TSC because these > are thing that are implemented independent of the question if these > things should be exposed to the app or not. There seems to be ample confusion about: - upper layer interface (abstract "API"): services to the user - lower layer interface: services needed from the next protocol layer - the protocol itself (as an abstract specification: i.e., the finite state machine rules that relate commands and responses to the ULI, calls and returns to the LLI, and internal state and events (e.g., timers) - the *implementation* of any of the above, e.g.: - Unix sockets API - interface to IPv4 - Differences that include Reno vs. Cubic..., MTU algs, etc. > However, features in > contrast should really only be the things that should be exposed. IMO, implementation issues should be fully out of scope. > The > list in section 4 currently copies everything from above and we need to > have the discuss now what should stay there and what not. Frankly, RFC 793 specified exactly what is needed here (it may need to be augmented with options and later extensions), but that needs to be a *starting point* for these discussions. And the current doc doesn't come close to what's in 793. If we're not starting there, there's little point in starting IMO. Joe > Mirja > > >> Am 27.05.2015 um 00:36 schrieb Joe Touch : >> >> Hi, Brian (et al.), >> >> On 5/26/2015 6:25 AM, Brian Trammell wrote: >> ... >>> (3) frontmatter in Section 4 normalizing and categorizing the >>> transport protocol components; please review this and suggest necessary >>> or useful changes for using this as background for selecting taps features. >> >> I like the definitions but IMO the protocol descriptions don't follow >> the definitions. >> >> I.e., I agree that a transport protocol service (TPS) is a feature or >> capability made available to the app, and that a transport protocol >> component (TPC) is an implementation of such a feature. >> >> I realize I sound like a broken record, but the descriptions of the >> protocols herein still does not match the definition of TPS or TPC. >> >> E.g., for TCP, none of the following is exposed to the user: >> - segmentation >> - flow control >> - congestion control >> - error detection >> At best, the effects of the above are exposed to the user in very >> indirect fashion, certainly not as a "service" that can be used. >> >> In addition, TCP provides all of the following services (the latter two >> depending on being supported), which are not listed: >> - PUSH >> - URG >> - authentication (via TCP-AO or legacy TCP MD5) >> - control over user timeout (UTO option) >> >> This continues to be a pervasive issue in this doc, i.e., not just for >> this protocol. >> >> Joe >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > From nobody Thu May 28 01:49:50 2015 Return-Path: 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 EB8DB1A0020 for ; Thu, 28 May 2015 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2HQZTjYtHyA for ; Thu, 28 May 2015 01:49:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444531A002A for ; Thu, 28 May 2015 01:49:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 32E04D9307; Thu, 28 May 2015 10:49:44 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DVenoywHejcA; Thu, 28 May 2015 10:49:44 +0200 (MEST) Received: from [192.168.130.36] (chello084113020103.2.12.vie.surfer.at [84.113.20.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CD9F8D9305; Thu, 28 May 2015 10:49:43 +0200 (MEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?windows-1252?Q?Mirja_K=FChlewind?= In-Reply-To: <5565FCC9.1040905@isi.edu> Date: Thu, 28 May 2015 10:49:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 08:49:49 -0000 Hi Joe, see below... > Am 27.05.2015 um 19:20 schrieb Joe Touch : >=20 >=20 > On 5/27/2015 6:02 AM, Mirja K=FChlewind wrote: >> Hi Joe, >>=20 >> I agree. This is a working document and we are still in the phase of >> collecting data while the next step is to discuss which things that = are >> currently listed must/should be listed or not and also which of the >> things must/should be exposed to the app. >=20 > To be clear, can you clarify the focus?: >=20 > - what IS/IS NOT (i.e., current requirements) >=20 > - what WILL BE/WILL NOT BE (i.e., future goals) >=20 > AFAICT, this is about IS/IS NOT. With that in mind, it should not be > necessary to "collect data" and then decide later what is exposed or = not. It=92s about IS/IS NOT. However, currently there is very little = (explicitly) exposed to the app. So the question is actually what should be exposed from the transport = service components that are currently implemented in the then different = existing transport protocols. >=20 >> However, I think we are on the write track for the TSC because these >> are thing that are implemented independent of the question if these >> things should be exposed to the app or not. >=20 > There seems to be ample confusion about: >=20 > - upper layer interface (abstract "API"): services to the user >=20 > - lower layer interface: services needed from the next protocol layer >=20 > - the protocol itself (as an abstract specification: i.e., the finite > state machine rules that relate commands and responses to the ULI, = calls > and returns to the LLI, and internal state and events (e.g., timers) >=20 > - the *implementation* of any of the above, e.g.: > - Unix sockets API > - interface to IPv4 > - Differences that include Reno vs. Cubic..., MTU algs, etc. >=20 >> However, features in >> contrast should really only be the things that should be exposed. >=20 > IMO, implementation issues should be fully out of scope. It=92s not about implementation issues but it=92s not always absolutely = clear which level of detail must be exposed to the app. Is it enough to = only have an interface where you can choose to use congestion control or = not, or do you need to choose between delay-based and lost-based = congestion control, or foreground and background congestion control, or = one specify algorithm, or just specify one specify detail of the = algorithm e.g. don=92t increase fast than one packet per RTT=85?=20 So the approach for the current document is to summarize what=92s = already there. We had some discussions about the level of detail of this = document, and I believe we currently have a good compromise where we = give some implementation details but also try to not make this document=20= unnecessary long. >=20 >> The >> list in section 4 currently copies everything from above and we need = to >> have the discuss now what should stay there and what not. >=20 > Frankly, RFC 793 specified exactly what is needed here (it may need to > be augmented with options and later extensions), but that needs to be = a > *starting point* for these discussions. >=20 > And the current doc doesn't come close to what's in 793. >=20 > If we're not starting there, there's little point in starting IMO. 793 is the starting point. However this doc is not only on TCP. If you = think that there important points missing, please propose new text or = changes to the current text! Mirja =20 >=20 > Joe >=20 >=20 >> Mirja >>=20 >>=20 >>> Am 27.05.2015 um 00:36 schrieb Joe Touch : >>>=20 >>> Hi, Brian (et al.), >>>=20 >>> On 5/26/2015 6:25 AM, Brian Trammell wrote: >>> ... >>>> (3) frontmatter in Section 4 normalizing and categorizing the >>>> transport protocol components; please review this and suggest = necessary >>>> or useful changes for using this as background for selecting taps = features. >>>=20 >>> I like the definitions but IMO the protocol descriptions don't = follow >>> the definitions. >>>=20 >>> I.e., I agree that a transport protocol service (TPS) is a feature = or >>> capability made available to the app, and that a transport protocol >>> component (TPC) is an implementation of such a feature. >>>=20 >>> I realize I sound like a broken record, but the descriptions of the >>> protocols herein still does not match the definition of TPS or TPC. >>>=20 >>> E.g., for TCP, none of the following is exposed to the user: >>> - segmentation >>> - flow control >>> - congestion control >>> - error detection >>> At best, the effects of the above are exposed to the user in very >>> indirect fashion, certainly not as a "service" that can be used. >>>=20 >>> In addition, TCP provides all of the following services (the latter = two >>> depending on being supported), which are not listed: >>> - PUSH >>> - URG >>> - authentication (via TCP-AO or legacy TCP MD5) >>> - control over user timeout (UTO option) >>>=20 >>> This continues to be a pervasive issue in this doc, i.e., not just = for >>> this protocol. >>>=20 >>> Joe >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu May 28 02:09:04 2015 Return-Path: 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 3E9DB1A00C3 for ; Thu, 28 May 2015 02:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 kO_dqCRlwu9e for ; Thu, 28 May 2015 02:09:00 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id B032B1A00C0 for ; Thu, 28 May 2015 02:08:59 -0700 (PDT) Received: from [192.168.130.34] (chello084113020103.2.12.vie.surfer.at [84.113.20.103]) by trammell.ch (Postfix) with ESMTPSA id E48541A0683; Thu, 28 May 2015 11:08:57 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_645A5A27-8265-48F4-920E-15B12DE5E974"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> Date: Thu, 28 May 2015 11:08:56 +0200 Message-Id: <489673F6-2C7D-4C7F-8383-DBFC26895C1D@trammell.ch> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2098) Archived-At: Cc: taps WG , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 09:09:02 -0000 --Apple-Mail=_645A5A27-8265-48F4-920E-15B12DE5E974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Mirja, Joe, two more points inline... > On 28 May 2015, at 10:49, Mirja K=FChlewind = wrote: >=20 > Hi Joe, >=20 > see below... >=20 >=20 >> Am 27.05.2015 um 19:20 schrieb Joe Touch : >>=20 >>=20 >> On 5/27/2015 6:02 AM, Mirja K=FChlewind wrote: >>> Hi Joe, >>>=20 >>> I agree. This is a working document and we are still in the phase of >>> collecting data while the next step is to discuss which things that = are >>> currently listed must/should be listed or not and also which of the >>> things must/should be exposed to the app. >>=20 >> To be clear, can you clarify the focus?: >>=20 >> - what IS/IS NOT (i.e., current requirements) >>=20 >> - what WILL BE/WILL NOT BE (i.e., future goals) >>=20 >> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >> necessary to "collect data" and then decide later what is exposed or = not. >=20 > It=92s about IS/IS NOT. However, currently there is very little = (explicitly) exposed to the app. >=20 > So the question is actually what should be exposed from the transport = service components that are currently implemented in the then different = existing transport protocols. >=20 >>> However, I think we are on the write track for the TSC because these >>> are thing that are implemented independent of the question if these >>> things should be exposed to the app or not. >>=20 >> There seems to be ample confusion about: >>=20 >> - upper layer interface (abstract "API"): services to the user >>=20 >> - lower layer interface: services needed from the next protocol layer >>=20 >> - the protocol itself (as an abstract specification: i.e., the finite >> state machine rules that relate commands and responses to the ULI, = calls >> and returns to the LLI, and internal state and events (e.g., timers) >>=20 >> - the *implementation* of any of the above, e.g.: >> - Unix sockets API >> - interface to IPv4 >> - Differences that include Reno vs. Cubic..., MTU algs, etc. >>=20 >>> However, features in >>> contrast should really only be the things that should be exposed. >>=20 >> IMO, implementation issues should be fully out of scope. I disagree that implementation- (and indeed, deployment-) level concerns = are out of scope here. It's implementation level concerns which have = made it necessary to do something like TAPS in the first place. In a = world without middlebox impairment you don't need any path condition = measurement or negotiation at all, and "transport flexibility" would = simply be a matter of sticking libraries on top of TCP and/or SCTP = options. > It=92s not about implementation issues but it=92s not always = absolutely clear which level of detail must be exposed to the app. Is it = enough to only have an interface where you can choose to use congestion = control or not, or do you need to choose between delay-based and = lost-based congestion control, or foreground and background congestion = control, or one specify algorithm, or just specify one specify detail of = the algorithm e.g. don=92t increase fast than one packet per RTT=85? There's a second issue here, as well, and it's kind of hiding behind the = current structure of the document and the terminology. Right now, which transport protocol to use is either an explicit choice = of the application developer (by selecting an API / library and set of = configuration parameters which always map to a single wire protocol) or = an implicit one (e.g. by selecting a library or higher-layer protocol on = which to develop the application which only supports a single transport = protocol). These protocols have positive properties (which we've called components) = and negative properties (that is, use of this protocol excludes some = other thing you might want to have). Stupid example: fully reliable = single-streaming implies head-of-line blocking. Here the positive and = negative properties are intrinsically linked. Less stupid example: = assume you want reliable transport of messages but don't care at all = about the order in which they arrive (e.g. because you're doing bulk = object synchronization as with NORM). In this case reliability would be = a positive property of TCP, and head-of-line blocking is a negative = property, the positive counterpart of which (stream orientation) you = don't even want. In this case, it is the choice of components pulled = together into a single protocol at protocol design time which sets up = the conflict. I'm not quite sure how to capture this, or indeed whether this document = is where it should be captured, but it is very important for any = approach to TAPS which will use off-the-shelf protocols. Cheers, Brian > So the approach for the current document is to summarize what=92s = already there. We had some discussions about the level of detail of this = document, and I believe we currently have a good compromise where we = give some implementation details but also try to not make this document > unnecessary long. >=20 >>=20 >>> The >>> list in section 4 currently copies everything from above and we need = to >>> have the discuss now what should stay there and what not. >>=20 >> Frankly, RFC 793 specified exactly what is needed here (it may need = to >> be augmented with options and later extensions), but that needs to be = a >> *starting point* for these discussions. >>=20 >> And the current doc doesn't come close to what's in 793. >>=20 >> If we're not starting there, there's little point in starting IMO. >=20 > 793 is the starting point. However this doc is not only on TCP. If you = think that there important points missing, please propose new text or = changes to the current text! >=20 > Mirja >=20 >=20 >>=20 >> Joe >>=20 >>=20 >>> Mirja >>>=20 >>>=20 >>>> Am 27.05.2015 um 00:36 schrieb Joe Touch : >>>>=20 >>>> Hi, Brian (et al.), >>>>=20 >>>> On 5/26/2015 6:25 AM, Brian Trammell wrote: >>>> ... >>>>> (3) frontmatter in Section 4 normalizing and categorizing the >>>>> transport protocol components; please review this and suggest = necessary >>>>> or useful changes for using this as background for selecting taps = features. >>>>=20 >>>> I like the definitions but IMO the protocol descriptions don't = follow >>>> the definitions. >>>>=20 >>>> I.e., I agree that a transport protocol service (TPS) is a feature = or >>>> capability made available to the app, and that a transport protocol >>>> component (TPC) is an implementation of such a feature. >>>>=20 >>>> I realize I sound like a broken record, but the descriptions of the >>>> protocols herein still does not match the definition of TPS or TPC. >>>>=20 >>>> E.g., for TCP, none of the following is exposed to the user: >>>> - segmentation >>>> - flow control >>>> - congestion control >>>> - error detection >>>> At best, the effects of the above are exposed to the user in very >>>> indirect fashion, certainly not as a "service" that can be used. >>>>=20 >>>> In addition, TCP provides all of the following services (the latter = two >>>> depending on being supported), which are not listed: >>>> - PUSH >>>> - URG >>>> - authentication (via TCP-AO or legacy TCP MD5) >>>> - control over user timeout (UTO option) >>>>=20 >>>> This continues to be a pervasive issue in this doc, i.e., not just = for >>>> this protocol. >>>>=20 >>>> Joe >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail=_645A5A27-8265-48F4-920E-15B12DE5E974 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVZtsoAAoJENt3nsOmbNJcx4MH/0IQLn6Ahzc3imeVuyS4mann 76/CzjfIrMCqQQ/9JOQ4VggQzXemO+iD183WVk/NPw3gmYGLOnoYV1MOPrbtZn7e qVeaVulc8EJoezpQTc+foOs560W0kW2Ndcpk2hT2ik22Vp0HkP3uVWvtjR1Xnsn6 mm2TcgF4Z+Y1PIRxysCxokAcZFE7vAPmX74QGgxrQwi7rOM5uj8mAMw3wkfbBfwZ HJNAyaeAGSEtkk7N1DWcq0ggPEQCy3CHih3DRvjhYS8l9Yj076jaDz5aj+CQvB8h lUI3CuqqlgkobuYToh91qQm+wlmZnPeWNjX4wHEfbgjFP96+c3cBvgdWpCesEtI= =m1Z6 -----END PGP SIGNATURE----- --Apple-Mail=_645A5A27-8265-48F4-920E-15B12DE5E974-- From nobody Thu May 28 07:18:53 2015 Return-Path: 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 2DBAA1ACDA7 for ; Thu, 28 May 2015 07:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 S7B271WbYJMw for ; Thu, 28 May 2015 07:18:51 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D85C1ACDA4 for ; Thu, 28 May 2015 07:18:34 -0700 (PDT) Received: by iepj10 with SMTP id j10so39153399iep.3 for ; Thu, 28 May 2015 07:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:content-type; bh=Z0w5kqVaDwh2M5sH80nYSjgqeCTZu21LafvBs0LmlOA=; b=Nwj/+BPnAbDJ3pXZLIcojeUqU70bDYWRFjOTBNJywUORoEcSKuSBNo+r+/3BHSiJaY HThaBacnX+PBFxhw7Y/PPU5f4BbbjhxjJaOWJ20+VQ/drH3WC0hmkT0/Ab6t62zbw60c MfUcSIbCMykJdzXughJ3zwJgV1yw5ZciOPzB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=Z0w5kqVaDwh2M5sH80nYSjgqeCTZu21LafvBs0LmlOA=; b=MOpLnJQJEMTT116bTkRCOliLIs1hwmXMxW4n1ehYIByDd8z42mBuNUpPYGegoQ2UzQ Ha1EE7SGhlfbGjsNtP2TzME3jCexlmMnXzupwTiKjqky2pyFBx8AGTjJIPbka8QS9/eD K8Lk0tqDx0hsqMbXPWHPrbuBiR39+UDdJ4BHDdPZGvGnxFp5dp+XYMJ5DiNWNm5HXFJ3 BcF9sxzUkizNQmVGcWOiM/MQR9v0uFvu5YwUAn1r1zQdLQXmYUEtguoZMNJECCydxmo+ g5+lJvqG3fkVzT3B9ZEQdWJxS5GY/JxNTxLdlnML3roBdDW1tQlPdyKHFRgX1N5b80iP awog== X-Gm-Message-State: ALoCoQkKZTr8PLBeUtmjs0M2wpGuZfzJClN72717MImfFJ83n6/GEuBEugXL5JIhRj3yR6tX0HQv093eKRkeDB8GZhxeZMOYrzl2bQaHDH7RyBH7VzrXwZY= X-Received: by 10.43.173.70 with SMTP id ob6mr9663037icc.45.1432822714024; Thu, 28 May 2015 07:18:34 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGXD5TRZ3p+aVuvQXnkRLbp1XVlBAI3qthZnfLEl0A= Date: Thu, 28 May 2015 16:18:33 +0200 Message-ID: <0bb5f9fc50b8f764b7c14407b3efa3c9@mail.gmail.com> To: Brian Trammell , taps WG Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 14:18:53 -0000 HI, I gave this comment also to version 03, but I will then repeat it here again :-): I do think that it is overkill to say that TCP implements the following Transport Protocol Components: o ordered delivery for each byte stream o stream-oriented delivery in a single stream Given that one TCP connection is able to serve one and only one byte stream, I think that it would suffice to give one of these statements. Preferably the latter one. BR, Karen >-----Original Message----- >From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Brian Trammell >Sent: Tuesday, May 26, 2015 3:26 PM >To: taps WG >Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt > >Greetings, all, > >We've submitted revision -04 of taps-transports, which includes: > >(1) a new section on HTTP as a pseudotransport over TCP (thanks, Dragana >Damjanovic!) > >(2) a new section on NORM (thanks, Brian Adamson!) > >(3) frontmatter in Section 4 normalizing and categorizing the transport >protocol components; please review this and suggest necessary or useful >changes for using this as background for selecting taps features. > >Next up is completing the outstanding sections on transports and transport- >like things, of which we have four: > >3.2 MP-TCP >3.7 RTP >3.9 TLS/DTLS pseudotransport >3.11 WebSockets > >We hope to get an -05 with text for these out in the next couple of weeks, >and will follow up with contributors for each of these sections shortly. > >Thanks, cheers, > >Brian (for the editors of taps-transports) > >> On 26 May 2015, at 14:41, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> This draft is a work item of the Transport Services Working Group of the >IETF. >> >> Title : Services provided by IETF transport protocols and congestion >control mechanisms >> Authors : Godred Fairhurst >> Brian Trammell >> Mirja Kuehlewind >> Filename : draft-ietf-taps-transports-04.txt >> Pages : 35 >> Date : 2015-05-26 >> >> Abstract: >> This document describes services provided by existing IETF protocols >> and congestion control mechanisms. It is designed to help >> application and network stack programmers and to inform the work of >> the IETF TAPS Working Group. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-taps-transports-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps From nobody Thu May 28 10:35:49 2015 Return-Path: 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 A86281B2C60 for ; Thu, 28 May 2015 10:35:47 -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 ltXsmrcJPABr for ; Thu, 28 May 2015 10:35:46 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325F41B2C58 for ; Thu, 28 May 2015 10:35:46 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4SHZ7cE027849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 May 2015 10:35:07 -0700 (PDT) Message-ID: <556751CA.5030403@isi.edu> Date: Thu, 28 May 2015 10:35:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Mirja_K=FChlewind?= References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> In-Reply-To: <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t4SHZ7cE027849 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 17:35:47 -0000 On 5/28/2015 1:49 AM, Mirja Kühlewind wrote: > Hi Joe, > > see below... > > >> Am 27.05.2015 um 19:20 schrieb Joe Touch : >> >> >> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote: >>> Hi Joe, >>> >>> I agree. This is a working document and we are still in the phase of >>> collecting data while the next step is to discuss which things that are >>> currently listed must/should be listed or not and also which of the >>> things must/should be exposed to the app. >> >> To be clear, can you clarify the focus?: >> >> - what IS/IS NOT (i.e., current requirements) >> >> - what WILL BE/WILL NOT BE (i.e., future goals) >> >> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >> necessary to "collect data" and then decide later what is exposed or not. > > It’s about IS/IS NOT. However, currently there is very little (explicitly) exposed to the app. That's contradictory. What IS/IS NOT exposed as per the specs is easy to determine. Anything not exposed is either not part of a spec or an incomplete implementation. Other stuff - like congestion control alg - is absolutely NOT part of any current TCP spec to expose to the API. > So the question is actually what should be exposed from the > transport service components that are currently implemented in the then different > existing transport protocols. That's WILL BE, and a completely different issue IMO. If we don't clearly document the current requirements, it's very difficult to move forward with deciding how to extend that API. >>> However, I think we are on the write track for the TSC because these >>> are thing that are implemented independent of the question if these >>> things should be exposed to the app or not. >> >> There seems to be ample confusion about: >> >> - upper layer interface (abstract "API"): services to the user >> >> - lower layer interface: services needed from the next protocol layer >> >> - the protocol itself (as an abstract specification: i.e., the finite >> state machine rules that relate commands and responses to the ULI, calls >> and returns to the LLI, and internal state and events (e.g., timers) >> >> - the *implementation* of any of the above, e.g.: >> - Unix sockets API >> - interface to IPv4 >> - Differences that include Reno vs. Cubic..., MTU algs, etc. >> >>> However, features in >>> contrast should really only be the things that should be exposed. >> >> IMO, implementation issues should be fully out of scope. > > It’s not about implementation issues but it’s not always absolutely > clear which level of detail must be exposed to the app. It's absolutely clear in RFC 793 at least. > Is it enough to > only have an interface where you can choose to use congestion control or > not, That's not part of any current spec, so you're back to "tomorrowland" thinking. > or do you need to choose between delay-based and lost-based > congestion control, or foreground and background congestion control, or > one specify algorithm, or just specify one specify detail of the > algorithm e.g. don’t increase fast than one packet per RTT…? Potentially useful, but that's diving very deep into HOW TCP operates, rather than user-level issues. This is revisiting the old QOS debate: do you open the entire set of QOS parameters to the user, or merely provide the user with a set of user-visible goals and allow the protocol to decide how best to support them? In QOS, this ended up picking a very few types of service classes. The same goal might be useful here. But, again, that's a goal for the future. It's difficult to get there if there's no clear indication of the current APIs. > So the approach for the current document is to summarize what’s > already there. The doc needs to differentiate between "already required per specification" and "available in some implementations". The former sets the baseline. The latter is fodder for discussion of how to standardize API extensions. > We had some discussions about the level of detail of this > document, and I believe we currently have a good compromise where we > give some implementation details but also try to not make this document > unnecessary long. IMO, the problem is that there's no clear distinction between what's currently required vs. available in some instances. >>> The >>> list in section 4 currently copies everything from above and we need to >>> have the discuss now what should stay there and what not. >> >> Frankly, RFC 793 specified exactly what is needed here (it may need to >> be augmented with options and later extensions), but that needs to be a >> *starting point* for these discussions. >> >> And the current doc doesn't come close to what's in 793. >> >> If we're not starting there, there's little point in starting IMO. > > 793 is the starting point. However this doc is not only on TCP. I noted that I was listing the issues with 793 as an example. There are similar issues with the other transports. > If > you think that there important points missing, please propose new text or > changes to the current text! I did 6 months and 3 versions ago: http://www.ietf.org/mail-archive/web/taps/current/msg00402.html I'll check back in another 6 and see if they're fixed then. Joe From nobody Thu May 28 11:05:20 2015 Return-Path: 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 2B6B21A87D0 for ; Thu, 28 May 2015 11:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNlfSeWPgPuZ for ; Thu, 28 May 2015 11:05:17 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0F41A87B3 for ; Thu, 28 May 2015 11:05:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 16912D9303; Thu, 28 May 2015 20:05:15 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a7W6IquaEjGM; Thu, 28 May 2015 20:05:14 +0200 (MEST) Received: from [10.59.2.148] (212-186-228-237.static.inode.at [212.186.228.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AAD60D9302; Thu, 28 May 2015 20:05:14 +0200 (MEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?windows-1252?Q?Mirja_K=FChlewind?= In-Reply-To: <556751CA.5030403@isi.edu> Date: Thu, 28 May 2015 20:05:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 18:05:20 -0000 Hi Joe, here is where the confusion comes from: this doc is not about APIs, it=92s= about transport services, or to say it even more concrete, transport = services components and features. We do have a section on interfaces for = each protocol but that just an add-on which might or might not be useful = to have in this document, but the core of the document is to describe = the components that are currently implemented independent of the current = provided (app-layer) interface and then add some discuss of which of = these components are useful to expose to the app as transport services = feature (and which level of detail/degree of decision freedom for each = feature). I know there have been many tries to do this. And I personally think we = will not be able to get this right. However, I know that we can do = better than what we have right now because that=92s clearly broken. Mirja > Am 28.05.2015 um 19:35 schrieb Joe Touch : >=20 >=20 >=20 > On 5/28/2015 1:49 AM, Mirja K=FChlewind wrote: >> Hi Joe, >>=20 >> see below... >>=20 >>=20 >>> Am 27.05.2015 um 19:20 schrieb Joe Touch : >>>=20 >>>=20 >>> On 5/27/2015 6:02 AM, Mirja K=FChlewind wrote: >>>> Hi Joe, >>>>=20 >>>> I agree. This is a working document and we are still in the phase = of >>>> collecting data while the next step is to discuss which things that = are >>>> currently listed must/should be listed or not and also which of the >>>> things must/should be exposed to the app. >>>=20 >>> To be clear, can you clarify the focus?: >>>=20 >>> - what IS/IS NOT (i.e., current requirements) >>>=20 >>> - what WILL BE/WILL NOT BE (i.e., future goals) >>>=20 >>> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >>> necessary to "collect data" and then decide later what is exposed or = not. >>=20 >> It=92s about IS/IS NOT. However, currently there is very little = (explicitly) exposed to the app. >=20 > That's contradictory. >=20 > What IS/IS NOT exposed as per the specs is easy to determine. >=20 > Anything not exposed is either not part of a spec or an incomplete > implementation. Other stuff - like congestion control alg - is > absolutely NOT part of any current TCP spec to expose to the API. >=20 >> So the question is actually what should be exposed from the >> transport service components that are currently implemented in the = then different >> existing transport protocols. >=20 > That's WILL BE, and a completely different issue IMO. If we don't > clearly document the current requirements, it's very difficult to move > forward with deciding how to extend that API. >=20 >>>> However, I think we are on the write track for the TSC because = these >>>> are thing that are implemented independent of the question if these >>>> things should be exposed to the app or not. >>>=20 >>> There seems to be ample confusion about: >>>=20 >>> - upper layer interface (abstract "API"): services to the user >>>=20 >>> - lower layer interface: services needed from the next protocol = layer >>>=20 >>> - the protocol itself (as an abstract specification: i.e., the = finite >>> state machine rules that relate commands and responses to the ULI, = calls >>> and returns to the LLI, and internal state and events (e.g., timers) >>>=20 >>> - the *implementation* of any of the above, e.g.: >>> - Unix sockets API >>> - interface to IPv4 >>> - Differences that include Reno vs. Cubic..., MTU algs, etc. >>>=20 >>>> However, features in >>>> contrast should really only be the things that should be exposed. >>>=20 >>> IMO, implementation issues should be fully out of scope. >>=20 >> It=92s not about implementation issues but it=92s not always = absolutely >> clear which level of detail must be exposed to the app. >=20 > It's absolutely clear in RFC 793 at least. >=20 >> Is it enough to >> only have an interface where you can choose to use congestion control = or >> not, >=20 > That's not part of any current spec, so you're back to "tomorrowland" > thinking. >=20 >> or do you need to choose between delay-based and lost-based >> congestion control, or foreground and background congestion control, = or >> one specify algorithm, or just specify one specify detail of the >> algorithm e.g. don=92t increase fast than one packet per RTT=85? >=20 > Potentially useful, but that's diving very deep into HOW TCP operates, > rather than user-level issues. >=20 > This is revisiting the old QOS debate: do you open the entire set of = QOS > parameters to the user, or merely provide the user with a set of > user-visible goals and allow the protocol to decide how best to = support > them? In QOS, this ended up picking a very few types of service = classes. > The same goal might be useful here. >=20 > But, again, that's a goal for the future. It's difficult to get there = if > there's no clear indication of the current APIs. >=20 >> So the approach for the current document is to summarize what=92s >> already there. >=20 > The doc needs to differentiate between "already required per > specification" and "available in some implementations". The former = sets > the baseline. The latter is fodder for discussion of how to = standardize > API extensions. >=20 >> We had some discussions about the level of detail of this >> document, and I believe we currently have a good compromise where we >> give some implementation details but also try to not make this = document >> unnecessary long. >=20 > IMO, the problem is that there's no clear distinction between what's > currently required vs. available in some instances. >=20 >>>> The >>>> list in section 4 currently copies everything from above and we = need to >>>> have the discuss now what should stay there and what not. >>>=20 >>> Frankly, RFC 793 specified exactly what is needed here (it may need = to >>> be augmented with options and later extensions), but that needs to = be a >>> *starting point* for these discussions. >>>=20 >>> And the current doc doesn't come close to what's in 793. >>>=20 >>> If we're not starting there, there's little point in starting IMO. >>=20 >> 793 is the starting point. However this doc is not only on TCP. >=20 > I noted that I was listing the issues with 793 as an example. There = are > similar issues with the other transports. >=20 >> If >> you think that there important points missing, please propose new = text or >> changes to the current text! >=20 > I did 6 months and 3 versions ago: > http://www.ietf.org/mail-archive/web/taps/current/msg00402.html >=20 > I'll check back in another 6 and see if they're fixed then. >=20 > Joe From nobody Thu May 28 11:19:07 2015 Return-Path: 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 12EDC1B2CB1 for ; Thu, 28 May 2015 11:19:06 -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 2ILUoWUvrjzx for ; Thu, 28 May 2015 11:19:05 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196B81B2CBF for ; Thu, 28 May 2015 11:18:59 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t4SIIQbX004569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 28 May 2015 11:18:27 -0700 (PDT) Message-ID: <55675BF2.3000409@isi.edu> Date: Thu, 28 May 2015 11:18:26 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Mirja_K=FChlewind?= References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> In-Reply-To: <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t4SIIQbX004569 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 18:19:06 -0000 On 5/28/2015 11:05 AM, Mirja Kühlewind wrote: > Hi Joe, > > here is where the confusion comes from: this doc is not about APIs, > it’s about transport services, or to say it even more concrete, > transport services components and features. Such services are either inherent to the transport (e.g., in-order, reliable delivery) or exposed as a control to the user (by the API). I.e., APIs are necessary but not sufficient to describe transport services. > We do have a section on > interfaces for each protocol but that just an add-on which might or > might not be useful to have in this document, but the core of the > document is to describe the components that are currently implemented > independent of the current provided (app-layer) interface and then add > some discuss of which of these components are useful to expose to the > app as transport services feature (and which level of detail/degree of > decision freedom for each feature). But then isn't it critical to also know what's already exposed, e.g., in the existing API? Joe From nobody Thu May 28 12:38:34 2015 Return-Path: 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 AF64B1A8709 for ; Thu, 28 May 2015 12:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 17KgC9z4n9R6 for ; Thu, 28 May 2015 12:38:31 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 94E171A8821 for ; Thu, 28 May 2015 12:38:31 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Yy3dN-0007UU-1y; Thu, 28 May 2015 21:38:29 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Yy3dM-0002ho-O5; Thu, 28 May 2015 21:38:29 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> Date: Thu, 28 May 2015 21:38:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 9 sum msgs/h 3 total rcpts 29482 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: 84A2AD1DBC4469918BC8A3CD6CED0188D57D1D09 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1093 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] API richness X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 19:38:33 -0000 > On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI, >=20 > As an example of presently relied on API richness, then the following > parameters of TCP/SCTP are parameters that today typically are tuned = by > signaling applications on a per connection/association basis or an a = per > signaling application basis. Here multiple signaling applications may = share > the same TCP/SCTP transport layer instance (SW block) but may = configure > their usage of the protocol (of their TCP connection/SCTP assoc > differently). > In terms of Taps terminology I think this corresponds to a shared " > Transport Service Instance". >=20 > I may note that the parameters even typically are exposed at O&M level = as > configurable by the Operators, > here even possibly on an association/connection basis. >=20 > For TCP: >=20 > RTO_MIN, RTO_MAX, MAXRT, SND BUF, RCV BUF, Delay_ack, No_delay, TCP = keep > alive settings, >=20 > For SCTP: >=20 > RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, No_delay, = HBI, > Association.Max.Retrans, Path.Max.Retrans, >=20 > There are other parameters as well that are tuned on a per TCP > connection/SCTP association basis, but this is in more special cases. > For example TCP (and even SCTP) ABC slow start parameter L, TCP time = wait > period. >=20 > The above parameters relates only to the core TCP and SCTP functions = relied > on by signaling applications. > Speaking additional features, e.g., ECN, special SCTP features = management > opens up for more of course. This strikes me as out of scope of TAPS: why discuss what (some) = applications today typically tune? > The CC algorithm today is not tuned - default is used - in the future = this > should be different, but I think that there is general agreement that = such > should > indeed be tuned at the TAPS API. Then I think I'm in the "don't agree" camp... Cheers, Michael From nobody Thu May 28 12:38:45 2015 Return-Path: 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 6CBF91A8838 for ; Thu, 28 May 2015 12:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 HLAD4x7wGB8L for ; Thu, 28 May 2015 12:38:36 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 8E6B41A8837 for ; Thu, 28 May 2015 12:38:36 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Yy3dG-0007UG-T0; Thu, 28 May 2015 21:38:22 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Yy3dG-0002ho-BW; Thu, 28 May 2015 21:38:22 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <55675BF2.3000409@isi.edu> Date: Thu, 28 May 2015 21:33:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 29479 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: 20E6DCB44C7D791A0B03C4C76B361A649AB0C41D X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1092 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , =?windows-1252?Q?Mirja_K=FChlewind?= , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Thu, 28 May 2015 19:38:40 -0000 > On 28. mai 2015, at 20.18, Joe Touch wrote: >=20 >=20 >=20 > On 5/28/2015 11:05 AM, Mirja K=FChlewind wrote: >> Hi Joe, >>=20 >> here is where the confusion comes from: this doc is not about APIs, >> it=92s about transport services, or to say it even more concrete, >> transport services components and features. >=20 > Such services are either inherent to the transport (e.g., in-order, > reliable delivery) or exposed as a control to the user (by the API). >=20 > I.e., APIs are necessary but not sufficient to describe transport = services. Agreed. Things that are in the APIs are what the document calls = "transport service features", whereas what you here call "inherent = services" is what the document calls "transport protocol components". I think it's a bit unfortunate that the API descriptions look very = different in style from the list of components. Maybe a line could be = drawn between: "transport service features" (components that are exposed to the = application) ... and here come all the things found in today's (not tomorrow's!) = APIs, as defined by the specs alone, not implementations and "transport protocol components" ... which is all the rest. I'm = thinking of just a way of splitting the component lists, just to say = "the following ones are exposed in the API today". >> We do have a section on >> interfaces for each protocol but that just an add-on which might or >> might not be useful to have in this document, but the core of the >> document is to describe the components that are currently implemented >> independent of the current provided (app-layer) interface and then = add >> some discuss of which of these components are useful to expose to the >> app as transport services feature (and which level of detail/degree = of >> decision freedom for each feature). >=20 > But then isn't it critical to also know what's already exposed, e.g., = in > the existing API? I think so - and the document tries to say that, by describing APIs. = Doing it like I propose above could add clarity. Cheers, Michael From nobody Thu May 28 23:56:53 2015 Return-Path: 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 430F51A0439 for ; Thu, 28 May 2015 23:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 hgZrtXpfWiT2 for ; Thu, 28 May 2015 23:56:49 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70E481A0423 for ; Thu, 28 May 2015 23:56:48 -0700 (PDT) Received: by iepj10 with SMTP id j10so55788320iep.3 for ; Thu, 28 May 2015 23:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=qSEIKbVdJxnxRBqUG3NpmS0zFRKUieJdhFu94wR/GmQ=; b=RSzdS7wcE6sTR/9dkRIsZuCkMrkUVr0MrvfbXvYrx5DKHnimVsQTWkylC2yR8+FaKp zDw5RMP/4mqnsMRkOevkOcx9GlquTy4RMQJUls/RFcq6Hv3MkDTAO9XvyuegvHg/aXN7 PPAEnTKompHCzxpzc+NKdRJ+RAjkUpkTdjPzY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=qSEIKbVdJxnxRBqUG3NpmS0zFRKUieJdhFu94wR/GmQ=; b=OiA0Fj+yWKQSRN7NswOuJKLht5d6LWtyMSMAGAhLfu4OKF47Slobe/cEj5zd/oI2K5 +D+YwVvJDYOOJDzhjqILLPI+OOvuPaojDlsZm1m7kUUBZJ1BY9btDJ9PgMWDR66TzviA Ib1HlPfj0agmHjUIEvQ5yEgNcoAmAytywPiwsNeOJYVcaC2dTRSvjrRRiWmqHmGSX5Ny x8AS5K9YjGL7QENiip3ERiIpkWwhW07326gNBlAjGuHiTAZlbI+SGqqpit2lT5fknOIb JSERJt2shw/nBDnAxgaYZDkeNSdZxGz5MVnqe95c3Y0sLskfFcgtOu+hjaNtQAwckHxi eXsQ== X-Gm-Message-State: ALoCoQmPbLf8MTbFrDL5/wJ8f7WMdqWr+jLr+N+l0xmfrY6AK0dJexOD6OBQ0k8/DH3TdcfCNd3HZy0Ls/5s13BSJn0GziX0iAiZ952Jp9mNPvAh53+HJbo= X-Received: by 10.43.173.70 with SMTP id ob6mr13514928icc.45.1432882607671; Thu, 28 May 2015 23:56:47 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxvXTQC9NkjLJ1kyLp7nJD5m5UzwL3zpVNnbh70vA= Date: Fri, 29 May 2015 08:56:46 +0200 Message-ID: To: Michael Welzl Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] API richness X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 06:56:51 -0000 HI Michael, Yes this api richness _may_ be out of scope of Taps. I am writing this as information as discussed at the taps wg meeting. If the Taps api is going to be useful I think that it is relevant to put it in context of the needs of applications - Don't you think so ? I am not saying that the taps api would need to address the present tuning needs described below, but I think that it is relevant to understands the present tuning needs, and to understand how taps fits into this. With CC tuning, I meant control which CC algorithm to choose. BR, Karen >-----Original Message----- >From: Michael Welzl [mailto:michawe@ifi.uio.no] >Sent: Thursday, May 28, 2015 9:39 PM >To: Karen Elisabeth Egede Nielsen >Cc: Aaron Falk; taps@ietf.org >Subject: Re: [Taps] API richness > > >> On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen > wrote: >> >> HI, >> >> As an example of presently relied on API richness, then the following >> parameters of TCP/SCTP are parameters that today typically are tuned >> by signaling applications on a per connection/association basis or an >> a per signaling application basis. Here multiple signaling >> applications may share the same TCP/SCTP transport layer instance (SW >> block) but may configure their usage of the protocol (of their TCP >> connection/SCTP assoc differently). >> In terms of Taps terminology I think this corresponds to a shared " >> Transport Service Instance". >> >> I may note that the parameters even typically are exposed at O&M level >> as configurable by the Operators, here even possibly on an >> association/connection basis. >> >> For TCP: >> >> RTO_MIN, RTO_MAX, MAXRT, SND BUF, RCV BUF, Delay_ack, No_delay, >TCP >> keep alive settings, >> >> For SCTP: >> >> RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, >No_delay, >> HBI, Association.Max.Retrans, Path.Max.Retrans, >> >> There are other parameters as well that are tuned on a per TCP >> connection/SCTP association basis, but this is in more special cases. >> For example TCP (and even SCTP) ABC slow start parameter L, TCP time >> wait period. >> >> The above parameters relates only to the core TCP and SCTP functions >> relied on by signaling applications. >> Speaking additional features, e.g., ECN, special SCTP features >> management opens up for more of course. > >This strikes me as out of scope of TAPS: why discuss what (some) applications >today typically tune? > > >> The CC algorithm today is not tuned - default is used - in the future >> this should be different, but I think that there is general agreement >> that such should indeed be tuned at the TAPS API. > >Then I think I'm in the "don't agree" camp... > >Cheers, >Michael From nobody Fri May 29 01:05:29 2015 Return-Path: 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 E7E0B1B2A92 for ; Fri, 29 May 2015 01:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.607 X-Spam-Level: X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001, 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 8AP2gewRAsyV for ; Fri, 29 May 2015 01:05:27 -0700 (PDT) Received: from crl-mxout1.it.nicta.com.au (crl-mxout1.it.nicta.com.au [IPv6:2402:1800:0:8001::25:8001]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB571B2A93 for ; Fri, 29 May 2015 01:05:27 -0700 (PDT) Received: from atp-exchmbx2.it.nicta.com.au ([221.199.216.124] helo=atp-exchmbx1.in.nicta.com.au) by crl-mxout1.it.nicta.com.au with esmtp (Exim 4.80) (envelope-from ) id 1YyFI7-0001Ae-1J; Fri, 29 May 2015 18:05:19 +1000 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx2.in.nicta.com.au (221.199.216.124) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 May 2015 18:05:16 +1000 Received: from blasturvion (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 29 May 2015 18:05:15 +1000 Received: by blasturvion (sSMTP sendmail emulation); Fri, 29 May 2015 18:05:15 +1000 Date: Fri, 29 May 2015 18:05:15 +1000 From: Olivier Mehani To: Michael Welzl Message-ID: <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NgG1H2o5aFKkgPy/" Content-Disposition: inline In-Reply-To: <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> X-Accept-Language: fr, en, es OpenPGP: id=4435CF6A7C8DDD9BE2DEF5F9F012A6E298C66655; preference=signencrypt; url=https://olivier.mehani.name/olivier.mehani.pgp.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-Product-Ver: SMEX-11.0.0.1251-8.000.1202-21576.006 X-TM-AS-Result: No--14.314000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Archived-At: Cc: Brian Trammell , taps WG , Mirja =?iso-8859-15?Q?K=FChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 08:05:29 -0000 --NgG1H2o5aFKkgPy/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote: > >> here is where the confusion comes from: this doc is not about APIs, > >> it=E2=80=99s about transport services, or to say it even more concrete, > >> transport services components and features. > > Such services are either inherent to the transport (e.g., in-order, > > reliable delivery) or exposed as a control to the user (by the API). > > I.e., APIs are necessary but not sufficient to describe transport > > services. > Agreed. Things that are in the APIs are what the document calls > "transport service features", whereas what you here call "inherent > services" is what the document calls "transport protocol components". I am not sure I have the same understanding of what features are. More than what is exposed through the API (which indeed is very little in the majority of the cases), I think features is what the application implicitly expects when selecting a specific transport. I agree more about the components. The application however has no idea about the components. This is internal stuff within each protocol to provide the features (e.g., retransmission for reliability), or to be nice to the network (e.g., congestion control). I don't think the applications would care much for the latter (or maybe as a hindrance which limits how much of the capacity it can grab). At the moment, looking at the draft, I think that most =E2=80=9CTransport Protocol Components=E2=80=9D sections actually conflate features and compon= ents, and probably list more of the former than the latter. I don't think this is quite in line with the terminology: Transport Service Feature: : a specific end-to-end feature that a transport service provides to its clients. Examples include confidentiality, reliable delivery, ordered delivery, message-versus-stream orientation, etc. Transport Protocol Component: : an implementation of a transport service feature within a protocol. For example for TCP, I would say that the following are features (that the = application wants) - reliable delivery - ordered delivery for each byte stream - stream-oriented delivery in a single stream - unicast - data bundling (Nagle's algorithm) - port multiplexing while these are components (that the application doesn't see) - connection setup with feature negotiation and application-to-port mapping - error detection (checksum) - segmentation - flow control - congestion control > "transport service features" (components that are exposed to the > application) ... and here come all the things found in today's (not > tomorrow's!) APIs, as defined by the specs alone, not implementations > and "transport protocol components" ... which is all the rest. I'm > thinking of just a way of splitting the component lists, just to say > "the following ones are exposed in the API today". I think this makes sense. That said, beyond just the specs, I think it would be useful to consider what current implementations provide too, as this may offer a slightly different set of features which is, nonetheless, what developers of real applications are dealing with. --=20 Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. --NgG1H2o5aFKkgPy/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJVaB27XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5MzA1NjQ3NTk5QUQ1MUVBNTkxREJDRkRF OTU2NkI5RDA5NTdEMkQzAAoJEOlWa50JV9LTFO4H/187aKdVqamg0hM/olZ0DAtj uWfTyDrNsSgop7oSvmTQPiyUQBTEjMPuMmydT0fL8DIDHcLUTYDkYHA2l3zZty5N XSUKBJq32dLyRHWaW59tGDCPxKwAGaAAAc21YSNDo6GHZOMqE70fuiMOeN2RmoVH ldBD2pP2PHXEKYTLK+xE55ffsWZQcwV6eyg/HFC6COe0JZeq7p2LLN/EJjXhe04g r2L+MPMa93Y6WrZAtjAcFC733nquLHJY1qQGHL9MQ67YhtFRi0aTKnV+XcTvSHGU KFaIblreCcMJXp6zW/oQd+ZQ7pq2jPgI0YZyePRqMnUPyu4e6J31lTwpL117SdM= =9Eob -----END PGP SIGNATURE----- --NgG1H2o5aFKkgPy/-- From nobody Fri May 29 01:12:58 2015 Return-Path: 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 AAF6F1B2A8F for ; Fri, 29 May 2015 01:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th5RuWgsytxs for ; Fri, 29 May 2015 01:12:47 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EAE1B2A89 for ; Fri, 29 May 2015 01:12:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 94B5DD9303; Fri, 29 May 2015 10:12:45 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id B41u12w5zjyZ; Fri, 29 May 2015 10:12:45 +0200 (MEST) Received: from [192.168.130.36] (chello084113020103.2.12.vie.surfer.at [84.113.20.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 20245D9302; Fri, 29 May 2015 10:12:45 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 29 May 2015 10:12:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] API richness X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 08:12:55 -0000 Hi Karen, instead of discussing what applications currently configure, I would = rather like to know why they configure it; what the goal they try to = reach and what=E2=80=99s the problem they try to handle with that. The = reason why I=E2=80=99m saying this, is because the current configuration = possibilities are often very limited and something even on the wrong = level. To figure out how to do this better, we need to understand what = the application really wants. Regarding congestion control, that=E2=80=99 a good example. In most = implementation you can configure the algorithm used in TCP. However, = usually people do not change this configuration because they don=E2=80=99t= understand what the benefits are that a certain algorithm (with a = random name) provides. Therefore actually choose the algorithm seems to = be on the wrong level. The interface should rather configure what = service a certain congestion control algorithm provides e.g. foreground = vs. background congestion control. (Not saying that this is the right = thing to do; just an example what you could do; we need to figure out = what=E2=80=99s the right thing to do by discussing application need). Mirja > Am 29.05.2015 um 08:56 schrieb Karen Elisabeth Egede Nielsen = : >=20 > HI Michael, >=20 > Yes this api richness _may_ be out of scope of Taps. > I am writing this as information as discussed at the taps wg meeting. >=20 > If the Taps api is going to be useful I think that it is relevant to = put > it in context of > the needs of applications - >=20 > Don't you think so ? >=20 > I am not saying that the taps api would need to address the present = tuning > needs > described below, but I think that it is relevant to understands the > present tuning needs, > and to understand how taps fits into this. >=20 > With CC tuning, I meant control which CC algorithm to choose. >=20 > BR, Karen >=20 >> -----Original Message----- >> From: Michael Welzl [mailto:michawe@ifi.uio.no] >> Sent: Thursday, May 28, 2015 9:39 PM >> To: Karen Elisabeth Egede Nielsen >> Cc: Aaron Falk; taps@ietf.org >> Subject: Re: [Taps] API richness >>=20 >>=20 >>> On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen >> wrote: >>>=20 >>> HI, >>>=20 >>> As an example of presently relied on API richness, then the = following >>> parameters of TCP/SCTP are parameters that today typically are tuned >>> by signaling applications on a per connection/association basis or = an >>> a per signaling application basis. Here multiple signaling >>> applications may share the same TCP/SCTP transport layer instance = (SW >>> block) but may configure their usage of the protocol (of their TCP >>> connection/SCTP assoc differently). >>> In terms of Taps terminology I think this corresponds to a shared " >>> Transport Service Instance". >>>=20 >>> I may note that the parameters even typically are exposed at O&M = level >>> as configurable by the Operators, here even possibly on an >>> association/connection basis. >>>=20 >>> For TCP: >>>=20 >>> RTO_MIN, RTO_MAX, MAXRT, SND BUF, RCV BUF, Delay_ack, No_delay, >> TCP >>> keep alive settings, >>>=20 >>> For SCTP: >>>=20 >>> RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, >> No_delay, >>> HBI, Association.Max.Retrans, Path.Max.Retrans, >>>=20 >>> There are other parameters as well that are tuned on a per TCP >>> connection/SCTP association basis, but this is in more special = cases. >>> For example TCP (and even SCTP) ABC slow start parameter L, TCP time >>> wait period. >>>=20 >>> The above parameters relates only to the core TCP and SCTP functions >>> relied on by signaling applications. >>> Speaking additional features, e.g., ECN, special SCTP features >>> management opens up for more of course. >>=20 >> This strikes me as out of scope of TAPS: why discuss what (some) > applications >> today typically tune? >>=20 >>=20 >>> The CC algorithm today is not tuned - default is used - in the = future >>> this should be different, but I think that there is general = agreement >>> that such should indeed be tuned at the TAPS API. >>=20 >> Then I think I'm in the "don't agree" camp... >>=20 >> Cheers, >> Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri May 29 01:27:50 2015 Return-Path: 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 E7D771A8701 for ; Fri, 29 May 2015 01:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 2iRL4E-6zpns for ; Fri, 29 May 2015 01:27:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F92D1A86F0 for ; Fri, 29 May 2015 01:27:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 17324D9305; Fri, 29 May 2015 10:27:45 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HLq1WVwQxjPk; Fri, 29 May 2015 10:27:44 +0200 (MEST) Received: from [192.168.130.36] (chello084113020103.2.12.vie.surfer.at [84.113.20.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 81A4AD9302; Fri, 29 May 2015 10:27:44 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> Date: Fri, 29 May 2015 10:27:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> To: Olivier Mehani X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , taps WG , Michael Welzl , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 08:27:49 -0000 Hi Oliver, I mostly agree with your understand, only minor points below. > Am 29.05.2015 um 10:05 schrieb Olivier Mehani = : >=20 > Hi all, >=20 > On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote: >>>> here is where the confusion comes from: this doc is not about APIs, >>>> it=E2=80=99s about transport services, or to say it even more = concrete, >>>> transport services components and features. >>> Such services are either inherent to the transport (e.g., in-order, >>> reliable delivery) or exposed as a control to the user (by the API). >>> I.e., APIs are necessary but not sufficient to describe transport >>> services. >> Agreed. Things that are in the APIs are what the document calls >> "transport service features", whereas what you here call "inherent >> services" is what the document calls "transport protocol components". >=20 > I am not sure I have the same understanding of what features are. More > than what is exposed through the API (which indeed is very little in = the > majority of the cases), I think features is what the application > implicitly expects when selecting a specific transport. Yes and no. So what you describe is the current state. A transport = service is a set of transport services features and today you can select = those features only implicitly by selection the transport protocol = itself. However, I think that it is worth to provide an interface to configure = each feature explicitly. Not completely sure yet that it is true. But = for me that=E2=80=99s one of the goals of this working group to figure = out if this statement is true. >=20 > I agree more about the components. The application however has no idea > about the components. This is internal stuff within each protocol to > provide the features (e.g., retransmission for reliability), or to be > nice to the network (e.g., congestion control). I don't think the > applications would care much for the latter (or maybe as a hindrance > which limits how much of the capacity it can grab). >=20 > At the moment, looking at the draft, I think that most =E2=80=9CTranspor= t > Protocol Components=E2=80=9D sections actually conflate features and = components, > and probably list more of the former than the latter. I don't think = this > is quite in line with the terminology: >=20 > Transport Service Feature: : a specific end-to-end feature that > a transport service provides to its clients. Examples include > confidentiality, reliable delivery, ordered delivery, > message-versus-stream orientation, etc. >=20 > Transport Protocol Component: : an implementation of a transport > service feature within a protocol. >=20 > For example for TCP, I would say that the following are features (that = the application wants) > - reliable delivery > - ordered delivery for each byte stream > - stream-oriented delivery in a single stream > - unicast > - data bundling (Nagle's algorithm) > - port multiplexing > while these are components (that the application doesn't see) > - connection setup with feature negotiation and application-to-port = mapping > - error detection (checksum) > - segmentation > - flow control > - congestion control I also see this very slightly different. Features and components are for = my understanding nothing exclusive. Each feature also has a = corresponding component (but not the other way around). However, while = the feature is =E2=80=9Areliable delivery=E2=80=98 (because that all the = app cares about), the component might be more specific like "reliable = delivery using accumulated ACKs and retransmissions=E2=80=99 as TCP = does. The more important point is, that the current lists in the doc need = work! Maybe some of the point you=E2=80=99ve listed above as features = must be phrased more detailed to describe/list the actually component = and then we need to decide which components actually also provide a = feature (that should be exposed) and on which level this correlates to a = feature. So the split you proposed above is a good starting point for = this. >=20 >> "transport service features" (components that are exposed to the >> application) ... and here come all the things found in today's (not >> tomorrow's!) APIs, as defined by the specs alone, not implementations >> and "transport protocol components" ... which is all the rest. I'm >> thinking of just a way of splitting the component lists, just to say >> "the following ones are exposed in the API today". >=20 > I think this makes sense. That said, beyond just the specs, I think it > would be useful to consider what current implementations provide too, = as > this may offer a slightly different set of features which is, > nonetheless, what developers of real applications are dealing with. You mean it term of APIs or component? Collecting information of = components are are currently implemented/used is the purpose of this = doc. Collecting information about API/config interfaces of what is = implemented/used today is also useful but a rat-hole=E2=80=A6 therefore = we try cover this aspect briefly in this doc but do not aim for = completeness here. Mirja >=20 > --=20 > Olivier Mehani > PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 > Confidentiality cannot be guaranteed on emails sent or received = unencrypted. From nobody Fri May 29 02:25:53 2015 Return-Path: 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 05EE51A8A91 for ; Fri, 29 May 2015 02:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] 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 g6ecC5aX3vc3 for ; Fri, 29 May 2015 02:25:50 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74CF91A9023 for ; Fri, 29 May 2015 02:25:49 -0700 (PDT) Received: by iepj10 with SMTP id j10so58082866iep.3 for ; Fri, 29 May 2015 02:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=tdNNO9kjk3+O2zlnN3IGg5gcd36Zc4mHj4kQXG62OOA=; b=rgxuU+9oygLGg283cL1dIu/ZFcX84vHRiWuJQEycA6c6Z74iOuA9s9XxwHoE+Tq9Pc HG1Ey4StdghnhkyszD25NDOqvdS46M+rbaoh1rt9AedFR/lqzSuPsoDRLH0hE1ylaCBw Z+rrSCmFi1YN/H57Rf/9OIRrEH14fvye6UcLQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=tdNNO9kjk3+O2zlnN3IGg5gcd36Zc4mHj4kQXG62OOA=; b=gVWezed3sAxTQNzfNRFavI2O/ZExrNSI4VdFwOpCBWg7h1e5ihx4i47B8sB13IlIPf 4LEcgf4YTZm4ZYnxVaN1paU/p5oXIkJFzHC2R44gm80uZXSG5KgtI2Yvm5gGe6VKE/2C UYJPBiXvH5jyAc794yQetpGRa0L/T9SuFY2X4RVGj7y5bN7mHKFOY5j9cAnC3aeAA3eV YiboOVA9gz70y2yavWbCSEdlzIN8KYp7wb07CU5cAORDtUxW78dLZ6jL04HUXwyR4jK7 Du5tNHKGqNAI/R90AlAbZFcMJpD9TC/utHBF3Sunb8byBuYIKaD3QtLQTGNjQVaPli9U 44lA== X-Gm-Message-State: ALoCoQnyuw6ZRaAXHI4W8BeHf1n0ijJrFSPlP68/ZYaSyBZqhcJzigtn11kXOEE2rPQRGhgCuMWixUamkjb3xE8SBPyCzd9gHsl2XTJEvEjvsVafBuZzrOA= X-Received: by 10.43.139.6 with SMTP id iu6mr42608icc.32.1432891548510; Fri, 29 May 2015 02:25:48 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxvXTQC9NkjLJ1kyLp7nJD5m5UzwL3zpVNAe0QfoUCstWHcJ2TpzRg Date: Fri, 29 May 2015 11:25:47 +0200 Message-ID: <993e7d103c6c8afeec31f7ef4b5e16f1@mail.gmail.com> To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] API richness X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 09:25:53 -0000 HI Mirja, >-----Original Message----- >From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >Sent: Friday, May 29, 2015 10:13 AM >To: Karen Elisabeth Egede Nielsen >Cc: Michael Welzl; taps WG >Subject: Re: [Taps] API richness > >Hi Karen, > >instead of discussing what applications currently configure, I would rathe= r >like >to know why they configure it; what the goal they try to reach and what=E2= =80=99s >the >problem they try to handle with that. The reason why I=E2=80=99m saying th= is, is >because the current configuration possibilities are often very limited and >something even on the wrong level. To figure out how to do this better, we >need to understand what the application really wants. > [Karen ] Yes I couldn't agree more. I will also concur that some of the present tuning is done to overcome some deficiencies in the protocol algorithms, but generally the below reflect needs of the applications to have the transport layer service stay within certain latency limits and to bail out from using the particular transport service layer (connection) if these limits are not withheld. I agree than one should extrapolate to the right generic features, to do that one should extrapolate from the existing concrete examples. >Regarding congestion control, that=E2=80=99 a good example. In most implem= entation >you can configure the algorithm used in TCP. However, usually people do no= t >change this configuration because they don=E2=80=99t understand what the b= enefits >are that a certain algorithm (with a random name) provides. Therefore >actually choose the algorithm seems to be on the wrong level. The interfac= e >should rather configure what service a certain congestion control algorith= m >provides e.g. foreground vs. background congestion control. (Not saying >that >this is the right thing to do; just an example what you could do; we need >to >figure out what=E2=80=99s the right thing to do by discussing application = need). > [Karen ] Agree. BR, Karen >Mirja > > >> Am 29.05.2015 um 08:56 schrieb Karen Elisabeth Egede Nielsen >: >> >> HI Michael, >> >> Yes this api richness _may_ be out of scope of Taps. >> I am writing this as information as discussed at the taps wg meeting. >> >> If the Taps api is going to be useful I think that it is relevant to >> put it in context of the needs of applications - >> >> Don't you think so ? >> >> I am not saying that the taps api would need to address the present >> tuning needs described below, but I think that it is relevant to >> understands the present tuning needs, and to understand how taps fits >> into this. >> >> With CC tuning, I meant control which CC algorithm to choose. >> >> BR, Karen >> >>> -----Original Message----- >>> From: Michael Welzl [mailto:michawe@ifi.uio.no] >>> Sent: Thursday, May 28, 2015 9:39 PM >>> To: Karen Elisabeth Egede Nielsen >>> Cc: Aaron Falk; taps@ietf.org >>> Subject: Re: [Taps] API richness >>> >>> >>>> On 27. mai 2015, at 08.22, Karen Elisabeth Egede Nielsen >>> wrote: >>>> >>>> HI, >>>> >>>> As an example of presently relied on API richness, then the >>>> following parameters of TCP/SCTP are parameters that today typically >>>> are tuned by signaling applications on a per connection/association >>>> basis or an a per signaling application basis. Here multiple >>>> signaling applications may share the same TCP/SCTP transport layer >>>> instance (SW >>>> block) but may configure their usage of the protocol (of their TCP >>>> connection/SCTP assoc differently). >>>> In terms of Taps terminology I think this corresponds to a shared " >>>> Transport Service Instance". >>>> >>>> I may note that the parameters even typically are exposed at O&M >>>> level as configurable by the Operators, here even possibly on an >>>> association/connection basis. >>>> >>>> For TCP: >>>> >>>> RTO_MIN, RTO_MAX, MAXRT, SND BUF, RCV BUF, Delay_ack, No_delay, >>> TCP >>>> keep alive settings, >>>> >>>> For SCTP: >>>> >>>> RTO_MIN, RTO_MAX, RTO_INITIAL, SND BUF, RCV BUF, Delay_ack, >>> No_delay, >>>> HBI, Association.Max.Retrans, Path.Max.Retrans, >>>> >>>> There are other parameters as well that are tuned on a per TCP >>>> connection/SCTP association basis, but this is in more special cases. >>>> For example TCP (and even SCTP) ABC slow start parameter L, TCP time >>>> wait period. >>>> >>>> The above parameters relates only to the core TCP and SCTP functions >>>> relied on by signaling applications. >>>> Speaking additional features, e.g., ECN, special SCTP features >>>> management opens up for more of course. >>> >>> This strikes me as out of scope of TAPS: why discuss what (some) >> applications >>> today typically tune? >>> >>> >>>> The CC algorithm today is not tuned - default is used - in the >>>> future this should be different, but I think that there is general >>>> agreement that such should indeed be tuned at the TAPS API. >>> >>> Then I think I'm in the "don't agree" camp... >>> >>> Cheers, >>> Michael >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps From nobody Fri May 29 02:31:22 2015 Return-Path: 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 BFE491B2AAB for ; Fri, 29 May 2015 02:31:20 -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 cKtEf0-gqp9K for ; Fri, 29 May 2015 02:31:18 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 375B51B2AAC for ; Fri, 29 May 2015 02:31:18 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YyGd4-00038C-Jj; Fri, 29 May 2015 11:31:02 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YyGd3-0001Ti-Vi; Fri, 29 May 2015 11:31:02 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> Date: Fri, 29 May 2015 11:30:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 11 sum msgs/h 3 total rcpts 29514 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6FF1C2469F2ED12BC5FE4F4C4F15A4ED04AF4654 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7183 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , taps WG , Joe Touch , Olivier Mehani Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 09:31:20 -0000 > On 29 May 2015, at 10:27, Mirja K=C3=BChlewind = wrote: >=20 > Hi Oliver, >=20 > I mostly agree with your understand, only minor points below. >=20 >> Am 29.05.2015 um 10:05 schrieb Olivier Mehani = : >>=20 >> Hi all, >>=20 >> On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote: >>>>> here is where the confusion comes from: this doc is not about = APIs, >>>>> it=E2=80=99s about transport services, or to say it even more = concrete, >>>>> transport services components and features. >>>> Such services are either inherent to the transport (e.g., in-order, >>>> reliable delivery) or exposed as a control to the user (by the = API). >>>> I.e., APIs are necessary but not sufficient to describe transport >>>> services. >>> Agreed. Things that are in the APIs are what the document calls >>> "transport service features", whereas what you here call "inherent >>> services" is what the document calls "transport protocol = components". >>=20 >> I am not sure I have the same understanding of what features are. = More >> than what is exposed through the API (which indeed is very little in = the >> majority of the cases), I think features is what the application >> implicitly expects when selecting a specific transport. >=20 > Yes and no. So what you describe is the current state. A transport = service is a set of transport services features and today you can select = those features only implicitly by selection the transport protocol = itself. >=20 > However, I think that it is worth to provide an interface to configure = each feature explicitly. Not completely sure yet that it is true. But = for me that=E2=80=99s one of the goals of this working group to figure = out if this statement is true. >=20 >>=20 >> I agree more about the components. The application however has no = idea >> about the components. This is internal stuff within each protocol to >> provide the features (e.g., retransmission for reliability), or to be >> nice to the network (e.g., congestion control). I don't think the >> applications would care much for the latter (or maybe as a hindrance >> which limits how much of the capacity it can grab). >>=20 >> At the moment, looking at the draft, I think that most =E2=80=9CTranspo= rt >> Protocol Components=E2=80=9D sections actually conflate features and = components, >> and probably list more of the former than the latter. I don't think = this >> is quite in line with the terminology: >>=20 >> Transport Service Feature: : a specific end-to-end feature that >> a transport service provides to its clients. Examples include >> confidentiality, reliable delivery, ordered delivery, >> message-versus-stream orientation, etc. >>=20 >> Transport Protocol Component: : an implementation of a transport >> service feature within a protocol. >>=20 >> For example for TCP, I would say that the following are features = (that the application wants) >> - reliable delivery >> - ordered delivery for each byte stream >> - stream-oriented delivery in a single stream >> - unicast >> - data bundling (Nagle's algorithm) >> - port multiplexing >> while these are components (that the application doesn't see) >> - connection setup with feature negotiation and application-to-port = mapping >> - error detection (checksum) >> - segmentation >> - flow control >> - congestion control >=20 > I also see this very slightly different. Features and components are = for my understanding nothing exclusive. Each feature also has a = corresponding component (but not the other way around). However, while = the feature is =E2=80=9Areliable delivery=E2=80=98 (because that all the = app cares about), the component might be more specific like "reliable = delivery using accumulated ACKs and retransmissions=E2=80=99 as TCP = does. >=20 > The more important point is, that the current lists in the doc need = work! Maybe some of the point you=E2=80=99ve listed above as features = must be phrased more detailed to describe/list the actually component = and then we need to decide which components actually also provide a = feature (that should be exposed) and on which level this correlates to a = feature. So the split you proposed above is a good starting point for = this. >=20 >=20 >>=20 >>> "transport service features" (components that are exposed to the >>> application) ... and here come all the things found in today's (not >>> tomorrow's!) APIs, as defined by the specs alone, not = implementations >>> and "transport protocol components" ... which is all the rest. I'm >>> thinking of just a way of splitting the component lists, just to say >>> "the following ones are exposed in the API today". >>=20 >> I think this makes sense. That said, beyond just the specs, I think = it >> would be useful to consider what current implementations provide too, = as >> this may offer a slightly different set of features which is, >> nonetheless, what developers of real applications are dealing with. >=20 > You mean it term of APIs or component? Collecting information of = components are are currently implemented/used is the purpose of this = doc. Collecting information about API/config interfaces of what is = implemented/used today is also useful but a rat-hole=E2=80=A6 therefore = we try cover this aspect briefly in this doc but do not aim for = completeness here. I just want to give a +1 on the rat-hole. IF we care about what = protocols currently offer to apps via their API, we should only worry = about what the specs say. (which also has its issues because I'm not = sure all specs do say enough) Cheers, Michael From nobody Fri May 29 02:37:20 2015 Return-Path: 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 A7A181B2AB6 for ; Fri, 29 May 2015 02:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ZL-kKrQPeeRr for ; Fri, 29 May 2015 02:37:17 -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 EF3D21B2AB0 for ; Fri, 29 May 2015 02:37:14 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YyGj2-0003qS-Dd; Fri, 29 May 2015 11:37:12 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1YyGj1-0004ak-QT; Fri, 29 May 2015 11:37:12 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <993e7d103c6c8afeec31f7ef4b5e16f1@mail.gmail.com> Date: Fri, 29 May 2015 11:37:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6262D681-79E5-4945-AF0B-05081B17C5A0@ifi.uio.no> References: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> <993e7d103c6c8afeec31f7ef4b5e16f1@mail.gmail.com> To: Karen Elisabeth Egede Nielsen X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 14 sum msgs/h 4 total rcpts 29517 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A457851874FC268FA363056A3BAD7B402FBF2AB4 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 7184 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , taps WG Subject: Re: [Taps] API richness X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 09:37:19 -0000 > On 29 May 2015, at 11:25, Karen Elisabeth Egede Nielsen = wrote: >=20 > HI Mirja, >=20 >=20 >> -----Original Message----- >> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >> Sent: Friday, May 29, 2015 10:13 AM >> To: Karen Elisabeth Egede Nielsen >> Cc: Michael Welzl; taps WG >> Subject: Re: [Taps] API richness >>=20 >> Hi Karen, >>=20 >> instead of discussing what applications currently configure, I would = rather >> like >> to know why they configure it; what the goal they try to reach and = what=E2=80=99s >> the >> problem they try to handle with that. The reason why I=E2=80=99m = saying this, is >> because the current configuration possibilities are often very = limited and >> something even on the wrong level. To figure out how to do this = better, we >> need to understand what the application really wants. >>=20 > [Karen ] Yes I couldn't agree more. > I will also concur that some of the present tuning is done to overcome = some > deficiencies in the protocol algorithms, but generally the below = reflect > needs of > the applications to have the transport layer service stay within = certain > latency limits and to > bail out from using the particular transport service layer = (connection) if > these limits are not withheld. >=20 > I agree than one should extrapolate to the right generic features, > to do that one should extrapolate from the existing concrete examples. Okay, it seems we're all on the same page. My heavy reaction to the = email before (and sorry Karen, I had forgotten why you sent it! Indeed = that was agreed upon at the last meeting) was because I'm afraid of the = logical conclusion: "this is what applications currently configure in current protocols" =3D> = "this is what a TAPS API would need to provide". Rather, I think it would be better to focus on *why* applications = currently configure the things they do, such that we can then provide = something reasonable and meaningful to them. Then again, even that is something we could spend much time on, and = possibly in vain: I believe that applications that are configuring all = these things nowadays probably wouldn't be "customers" of TAPS anyway. TAPS generally targets programmers of applications who are willing to = give up some control, for the possible benefits that come with = abstraction. This will always only be a subset of applications. Cheers, Michael From nobody Fri May 29 03:23:04 2015 Return-Path: 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 55E391A87C6 for ; Fri, 29 May 2015 03:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.021 X-Spam-Level: X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 wQ7Zarf_r8n2 for ; Fri, 29 May 2015 03:23:01 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613B61B2AC2 for ; Fri, 29 May 2015 03:23:01 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so10673728igb.0 for ; Fri, 29 May 2015 03:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=1wYH08ENxmCv7n1A62CediaxW8T42vTYBg0dqVAvIZg=; b=EJy2C1AcVCh9pNs8KiFDzsi2xUypoFDNxQ1OUdv+2uSvstZWSq0uk3U65VMKg0Mmre VUCpeNkFT1ky5TZYhFhvHOuNyQ6nds8YunWn2R9MHgwYdfcVJFnTmJsBh93+1aPLSXCl RQVT7zXQJkqY8DT3+enwEVzXjdXBPs9OjEUUc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=1wYH08ENxmCv7n1A62CediaxW8T42vTYBg0dqVAvIZg=; b=cF7VoseK/KPIk+BwVhjcQfT3Yszlwl5+C4yI7JdP+k91VI6LEyEPDe2vJQbGbpXGUZ H8rHKCmbzQ24VLke5lshIKOZwrZK5vXfxTnip8vEAnj+kP+/MSbKa/Ce33ViNHFEMwN2 PiPgAQzQoS91NJ0i1lGCGD/EyILXgX7KqSctITSH1aShkj1rY4vZIOkf25aTxK7v4dmO xhmmX5tOUs5A1lOWkwmWc8I2RF/z6MkkxA8NgAz4NFBFhdRno+mn1PhcQOi7GB4ctO7H VtnmSCs9GTPxlGiKxLJ/emiG3BEvF9kTsyaYJ8eWTz4M0Ijkg14k0slNiIwoWColJcag Cpqg== X-Gm-Message-State: ALoCoQllRVM42ohNf6+/+rRKPihulEOsBwIslsgy8vxF0bY8XIkbxPLUV1Dh1PwI6v5q57666WrnZ1Xk81TnyqoULB49LydeZZP0L+wgj+mFQ/MV6SyUd64= X-Received: by 10.50.79.196 with SMTP id l4mr3015797igx.48.1432894980844; Fri, 29 May 2015 03:23:00 -0700 (PDT) From: Karen Elisabeth Egede Nielsen References: <36fa975fcd988f7267c9be6ac1adc00e@mail.gmail.com> <993e7d103c6c8afeec31f7ef4b5e16f1@mail.gmail.com> <6262D681-79E5-4945-AF0B-05081B17C5A0@ifi.uio.no> In-Reply-To: <6262D681-79E5-4945-AF0B-05081B17C5A0@ifi.uio.no> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxvXTQC9NkjLJ1kyLp7nJD5m5UzwL3zpVNAe0QfoUCstWHcALwI3+NAeoP6FydbOQrMA== Date: Fri, 29 May 2015 12:22:59 +0200 Message-ID: <6f555af52259d0396f10183d120e82cf@mail.gmail.com> To: Michael Welzl Content-Type: text/plain; charset=UTF-8 X-DomainID: tieto.com Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , taps WG Subject: Re: [Taps] API richness X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 10:23:02 -0000 Hi Michael, > >Okay, it seems we're all on the same page. My heavy reaction to the email >before (and sorry Karen, I had forgotten why you sent it! Indeed that was >agreed upon at the last meeting) was because I'm afraid of the logical >conclusion: >"this is what applications currently configure in current protocols" => >"this is >what a TAPS API would need to provide". [Karen ] No problem - the clarification was important :-). Yes I think so (one the same page). And I did not intend to make the above corollary. The purpose of the posting was to provide information on presently drawn on transport service API granularity by a set of applications (Real-time signaling applications). I believe such information is relevant to put the abstraction of Taps into context. Regardless of where the line of abstraction ends up being drawn. > >Rather, I think it would be better to focus on *why* applications currently >configure the things they do, such that we can then provide something >reasonable and meaningful to them. >Then again, even that is something we could spend much time on, and >possibly in vain: I believe that applications that are configuring all >these things >nowadays probably wouldn't be "customers" of TAPS anyway. >TAPS generally targets programmers of applications who are willing to give >up >some control, for the possible benefits that come with abstraction. This >will >always only be a subset of applications. > [Karen ] Yes - the difficult job is to strike the right balance. >Cheers, >Michael From nobody Fri May 29 10:41:35 2015 Return-Path: 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 76E7C1B2ACF for ; Fri, 29 May 2015 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 YOPZ-WqBL1YA for ; Fri, 29 May 2015 10:41:33 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855291A03A2 for ; Fri, 29 May 2015 10:33:10 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t4THWhao028700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 29 May 2015 10:32:43 -0700 (PDT) Message-ID: <5568A2B9.2040206@isi.edu> Date: Fri, 29 May 2015 10:32:41 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , taps WG , Olivier Mehani Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Fri, 29 May 2015 17:41:34 -0000 First, I think this discussion would benefit from a clarification of what "API" means, or at least to stop using that term in isolation. There are three distinct concepts: A- abstract protocol "upper layer interface" e.g., OPEN, CLOSE, ABORT, as per RFC 793 B- programmer API e.g., Linux C/C++ TCP socket interface C- instance of a programmer API e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface IMO, this document MUST discuss A, and can be address potential extensions to A based on examining variants of B and C. There are also the protocol features, which are the properties of the protocol that: - can be explicitly configured and monitored these are *exactly* A, B, and/or C above - can be implicitly detected some are based on the definition of the protocol, such as reliable, byte sequence delivery some are an artifact of the implementation, such as specific delays due to burst losses However, *none* of this is a rat-hole IF TAPS is intended to explain the service interface to the user. IMO, B and C above should be secondary considerations after A is clearly documented, but this draft is a long way from that. Joe From nobody Sat May 30 05:25:05 2015 Return-Path: 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 67FB61A0123 for ; Sat, 30 May 2015 05:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 RDaMbsoGzfTE for ; Sat, 30 May 2015 05:25:01 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 428841A0102 for ; Sat, 30 May 2015 05:25:01 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Yyfok-0006a9-Hn; Sat, 30 May 2015 14:24:46 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Yyfoj-0006vR-Va; Sat, 30 May 2015 14:24:46 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <5568A2B9.2040206@isi.edu> Date: Sat, 30 May 2015 14:24:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 14 sum msgs/h 5 total rcpts 29560 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: 8ED2ABDA1F37A3438F4C7D561BE7BDC3167772C0 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 1103 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , taps WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Olivier Mehani Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Sat, 30 May 2015 12:25:03 -0000 > On 29. mai 2015, at 19.32, Joe Touch wrote: >=20 > First, I think this discussion would benefit from a clarification of > what "API" means, or at least to stop using that term in isolation. >=20 > There are three distinct concepts: >=20 > A- abstract protocol "upper layer interface"=09 > e.g., OPEN, CLOSE, ABORT, as per RFC 793 >=20 > B- programmer API > e.g., Linux C/C++ TCP socket interface >=20 > C- instance of a programmer API > e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface >=20 > IMO, this document MUST discuss A, and can be address potential > extensions to A based on examining variants of B and C. >=20 > There are also the protocol features, which are the properties of the > protocol that: > - can be explicitly configured and monitored > these are *exactly* A, B, and/or C above >=20 > - can be implicitly detected > some are based on the definition of the protocol, > such as reliable, byte sequence delivery >=20 > some are an artifact of the implementation, > such as specific delays due to burst losses >=20 > However, *none* of this is a rat-hole IF TAPS is intended to explain = the > service interface to the user. IMO, B and C above should be secondary > considerations after A is clearly documented, but this draft is a long > way from that. I agree: A should be there, and it should probably the primary focus, as = starting with a list of A would add a lot of clarity to the document and = the discussion of it. Some text on protocol internals, explaing what a protocol does even = though these things may not be exposed to an application, can be = valuable even if only to know which protocol to choose. So I'm not = suggesting removing everything but I'd agree that the focus of the = document should shift towards a list of A. Cheers, Michael From nobody Sat May 30 05:31:30 2015 Return-Path: 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 254B01A0193 for ; Sat, 30 May 2015 05:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 M4AwHkhbMX6R for ; Sat, 30 May 2015 05:31:26 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 B333E1A01AA for ; Sat, 30 May 2015 05:31:25 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Yyfv9-0006qZ-Lg; Sat, 30 May 2015 14:31:23 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Yyfv8-0006se-TW; Sat, 30 May 2015 14:31:23 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <489673F6-2C7D-4C7F-8383-DBFC26895C1D@trammell.ch> Date: Sat, 30 May 2015 14:31:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8347A027-320F-40A9-B3F2-AF63072341A0@ifi.uio.no> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <489673F6-2C7D-4C7F-8383-DBFC26895C1D@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 15 msgs/h 5 sum rcpts/h 18 sum msgs/h 6 total rcpts 29564 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: 15D3C912604E7021C3A0C3509814A198729C99D5 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1104 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Joe Touch , =?windows-1252?Q?Mirja_K=FChlewind?= , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Sat, 30 May 2015 12:31:28 -0000 > On 28. mai 2015, at 11.08, Brian Trammell wrote: >=20 > hi Mirja, Joe, >=20 > two more points inline... >=20 >> On 28 May 2015, at 10:49, Mirja K=FChlewind = wrote: >>=20 >> Hi Joe, >>=20 >> see below... >>=20 >>=20 >>> Am 27.05.2015 um 19:20 schrieb Joe Touch : >>>=20 >>>=20 >>> On 5/27/2015 6:02 AM, Mirja K=FChlewind wrote: >>>> Hi Joe, >>>>=20 >>>> I agree. This is a working document and we are still in the phase = of >>>> collecting data while the next step is to discuss which things that = are >>>> currently listed must/should be listed or not and also which of the >>>> things must/should be exposed to the app. >>>=20 >>> To be clear, can you clarify the focus?: >>>=20 >>> - what IS/IS NOT (i.e., current requirements) >>>=20 >>> - what WILL BE/WILL NOT BE (i.e., future goals) >>>=20 >>> AFAICT, this is about IS/IS NOT. With that in mind, it should not be >>> necessary to "collect data" and then decide later what is exposed or = not. >>=20 >> It=92s about IS/IS NOT. However, currently there is very little = (explicitly) exposed to the app. >>=20 >> So the question is actually what should be exposed from the transport = service components that are currently implemented in the then different = existing transport protocols. >>=20 >>>> However, I think we are on the write track for the TSC because = these >>>> are thing that are implemented independent of the question if these >>>> things should be exposed to the app or not. >>>=20 >>> There seems to be ample confusion about: >>>=20 >>> - upper layer interface (abstract "API"): services to the user >>>=20 >>> - lower layer interface: services needed from the next protocol = layer >>>=20 >>> - the protocol itself (as an abstract specification: i.e., the = finite >>> state machine rules that relate commands and responses to the ULI, = calls >>> and returns to the LLI, and internal state and events (e.g., timers) >>>=20 >>> - the *implementation* of any of the above, e.g.: >>> - Unix sockets API >>> - interface to IPv4 >>> - Differences that include Reno vs. Cubic..., MTU algs, etc. >>>=20 >>>> However, features in >>>> contrast should really only be the things that should be exposed. >>>=20 >>> IMO, implementation issues should be fully out of scope. >=20 > I disagree that implementation- (and indeed, deployment-) level = concerns are out of scope here. It's implementation level concerns which = have made it necessary to do something like TAPS in the first place. In = a world without middlebox impairment you don't need any path condition = measurement or negotiation at all, and "transport flexibility" would = simply be a matter of sticking libraries on top of TCP and/or SCTP = options. This sounds like you were talking cross purposes. My interpretation here = is that Joe is saying (as in his other email) that "concept A" in his = other email: http://www.ietf.org/mail-archive/web/taps/current/msg00490.html should be in scope of the discussion, but B and C should not. I agree = with that and your answer doesn't say you don't. How to implement / deploy something are concerns that should be in scope = of TAPS (they clearly are as per item 3 in its charter), but not = necessarily in scope of this first document. >> It=92s not about implementation issues but it=92s not always = absolutely clear which level of detail must be exposed to the app. Is it = enough to only have an interface where you can choose to use congestion = control or not, or do you need to choose between delay-based and = lost-based congestion control, or foreground and background congestion = control, or one specify algorithm, or just specify one specify detail of = the algorithm e.g. don=92t increase fast than one packet per RTT=85? >=20 > There's a second issue here, as well, and it's kind of hiding behind = the current structure of the document and the terminology. >=20 > Right now, which transport protocol to use is either an explicit = choice of the application developer (by selecting an API / library and = set of configuration parameters which always map to a single wire = protocol) or an implicit one (e.g. by selecting a library or = higher-layer protocol on which to develop the application which only = supports a single transport protocol). >=20 > These protocols have positive properties (which we've called = components) and negative properties (that is, use of this protocol = excludes some other thing you might want to have). Stupid example: fully = reliable single-streaming implies head-of-line blocking. Here the = positive and negative properties are intrinsically linked. Less stupid = example: assume you want reliable transport of messages but don't care = at all about the order in which they arrive (e.g. because you're doing = bulk object synchronization as with NORM). In this case reliability = would be a positive property of TCP, and head-of-line blocking is a = negative property, the positive counterpart of which (stream = orientation) you don't even want. In this case, it is the choice of = components pulled together into a single protocol at protocol design = time which sets up the conflict. >=20 > I'm not quite sure how to capture this, or indeed whether this = document is where it should be captured, but it is very important for = any approach to TAPS which will use off-the-shelf protocols. I do believe, based on our own prior work, that you'll find surprisingly = few such conflicts. I agree that documenting them will be important, but = it seems obvious to me that this should be done as a second step, after = creating a list of what all the protocols offer to applications. = Probably in the same document, but let's first get that list right. Cheers, Michael From nobody Sun May 31 17:18:08 2015 Return-Path: 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 414721ACEFD for ; Sun, 31 May 2015 17:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.393 X-Spam-Level: ** X-Spam-Status: No, score=2.393 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, 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 XG-LYYlSZ4_s for ; Sun, 31 May 2015 17:18:05 -0700 (PDT) Received: from crl-mxout1.it.nicta.com.au (crl-mxout1.it.nicta.com.au [IPv6:2402:1800:0:8001::25:8001]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FED61A88E4 for ; Sun, 31 May 2015 17:18:05 -0700 (PDT) Received: from atp-exchmbx2.it.nicta.com.au ([221.199.216.124] helo=atp-exchmbx1.in.nicta.com.au) by crl-mxout1.it.nicta.com.au with esmtp (Exim 4.80) (envelope-from ) id 1YzDQS-0004vd-Tv; Mon, 01 Jun 2015 10:17:56 +1000 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx2.in.nicta.com.au (221.199.216.124) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Jun 2015 10:17:54 +1000 Received: from blasturvion (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Jun 2015 10:17:53 +1000 Received: by blasturvion (sSMTP sendmail emulation); Mon, 01 Jun 2015 10:17:53 +1000 Date: Mon, 1 Jun 2015 10:17:53 +1000 From: Olivier Mehani To: Mirja =?iso-8859-15?Q?K=FChlewind?= Message-ID: <20150601001753.GF31213@blasturvion.dynhost.nicta.com.au> References: <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/QKKmeG/X/bPShih" Content-Disposition: inline In-Reply-To: <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> X-Accept-Language: fr, en, es OpenPGP: id=4435CF6A7C8DDD9BE2DEF5F9F012A6E298C66655; preference=signencrypt; url=https://olivier.mehani.name/olivier.mehani.pgp.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-TM-AS-Product-Ver: SMEX-11.0.0.1251-8.000.1202-21582.003 X-TM-AS-Result: No--25.104600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Archived-At: Cc: Brian Trammell , taps WG , Michael Welzl , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org 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: Mon, 01 Jun 2015 00:18:07 -0000 --/QKKmeG/X/bPShih Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey Mirja, On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja K=C3=BChlewind wrote: > > I am not sure I have the same understanding of what features are. > > More than what is exposed through the API (which indeed is very > > little in the majority of the cases), I think features is what the > > application implicitly expects when selecting a specific transport. > Yes and no. So what you describe is the current state. A transport > service is a set of transport services features and today you can > select those features only implicitly by selection the transport > protocol itself. > However, I think that it is worth to provide an interface to configure > each feature explicitly. Not completely sure yet that it is true. But > for me that=E2=80=99s one of the goals of this working group to figure ou= t if > this statement is true. Yes, that's how I understand it too. Nonetheless, we need to start with what we have: groups of features that we need to identify and separate. > > At the moment, looking at the draft, I think that most =E2=80=9CTranspo= rt > > Protocol Components=E2=80=9D sections actually conflate features and co= mponents, > > and probably list more of the former than the latter. I don't think this > > is quite in line with the terminology: [...] > >=20 > > For example for TCP, I would say that the following are features (that = the application wants) > > - reliable delivery > > - ordered delivery for each byte stream > > - stream-oriented delivery in a single stream > > - unicast > > - data bundling (Nagle's algorithm) > > - port multiplexing > > while these are components (that the application doesn't see) > > - connection setup with feature negotiation and application-to-port map= ping > > - error detection (checksum) > > - segmentation > > - flow control > > - congestion control > I also see this very slightly different. Features and components are > for my understanding nothing exclusive. Each feature also has a > corresponding component (but not the other way around). However, while > the feature is =E2=80=9Areliable delivery=E2=80=98 (because that all the = app cares > about), the component might be more specific like "reliable delivery > using accumulated ACKs and retransmissions=E2=80=99 as TCP does. Yes, I completely agree. But I think the difference you higlight is important: each feature has one (or more, I'd say) corresponding components, while components might not necessarily result in an application-visible feature.=20 > The more important point is, that the current lists in the doc need > work! Maybe some of the point you=E2=80=99ve listed above as features mus= t be > phrased more detailed to describe/list the actually component and then > we need to decide which components actually also provide a feature > (that should be exposed) and on which level this correlates to a > feature. So the split you proposed above is a good starting point for > this. I'm glad to read it (: > >> "transport service features" (components that are exposed to the > >> application) ... and here come all the things found in today's (not > >> tomorrow's!) APIs, as defined by the specs alone, not > >> implementations and "transport protocol components" ... which is > >> all the rest. I'm thinking of just a way of splitting the component > >> lists, just to say "the following ones are exposed in the API > >> today". > > I think this makes sense. That said, beyond just the specs, I think > > it would be useful to consider what current implementations provide > > too, as this may offer a slightly different set of features which > > is, nonetheless, what developers of real applications are dealing > > with. > You mean it term of APIs or component? Collecting information of > components are are currently implemented/used is the purpose of this > doc. Collecting information about API/config interfaces of what is > implemented/used today is also useful but a rat-hole=E2=80=A6 therefore w= e try > cover this aspect briefly in this doc but do not aim for completeness > here. Yes, this is likely for a later document. However, I think we should make sure that some transport API have not implemented some non-standardised behaviours that a non-negligible number of applications use. I am not sure it's the case, but if it is so, we probably want to take that onboard at some point too. --=20 Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. --/QKKmeG/X/bPShih Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJVa6SwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5MzA1NjQ3NTk5QUQ1MUVBNTkxREJDRkRF OTU2NkI5RDA5NTdEMkQzAAoJEOlWa50JV9LTDxsH/ib+Vta6i6KNB46Kxziv/gQu yd3IA2pGdwYN1vJ+uVBQEOFUMkEavcy/aj9XEBgSvTJzGGjKXAT1XD0IO8VnXcOz pm7ZQxFpN7eQ2ca0ZmcK+nKQ1zy7EB9kMXAkL3Z0iVYHmhN76lVzuCKU7Y1kf23V Aa8YI79766c1N1mZr3Lo2UrHi3sFM/cHCYiVtGJhhWU2RXJqWoByVEOTY8drvkWB WUCXsm0P+d+LOwG/bR1BxZDec3Hq9kKMrHFV0mLu/+4Z44dFywMEf192stiNCjne CqJpNOSkCDCSJfKSKo5UUxceOlkgpeH+OCfD5NGWUVZJSzjwmxQlz4kXLqLwcgs= =CdH6 -----END PGP SIGNATURE----- --/QKKmeG/X/bPShih--