From nobody Tue Dec 2 14:46:01 2014 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 572DD1A6F2A for ; Tue, 2 Dec 2014 14:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 N9Q8JcmGsRvb for ; Tue, 2 Dec 2014 14:45:49 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1AE1A1EFD for ; Tue, 2 Dec 2014 14:45:49 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id le20so6220027vcb.40 for ; Tue, 02 Dec 2014 14:45:48 -0800 (PST) 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; bh=tfvhoF+uMLhlUsIjBuumT5kdrnNmZsE5+/z8IYocKHc=; b=cMex7okHatnntw5MdHeffijsmDrR2dnHzz0FWCnSqw09Rw6mQn7H+qPTuNOdnOr5ir GNky9amVBJ9l6Fg9rw2VCaI1buMZTe/Hq+hwNwHZ698k1tsQKc4nxXHkTK2xi2Ojni5Q RRWLSea/E+VE1GqMp+hD4gEk5vzJLwxzQ6oRmG8DmYNolqsK3/W/JcuGePbV8HxkLzcF TDwqTyBxA+AvPjGkpUiJcpW1sI5T1DTtcZ9A1uiPqiLCgoeQ3ZC9mQ7HDEF0b82KztfI /Mv2CdefI6wywposXvIRWeKyCTuGo58tHXBFsPuNgpFqaRcadesLQJDIVHfE1FNygwc1 JE7w== MIME-Version: 1.0 X-Received: by 10.221.34.193 with SMTP id st1mr1043093vcb.77.1417560348459; Tue, 02 Dec 2014 14:45:48 -0800 (PST) Received: by 10.52.28.174 with HTTP; Tue, 2 Dec 2014 14:45:48 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Dec 2014 17:45:48 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a113644940487890509437d66 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/dAaj1xxKTwAcOfQ1165QzY7-MWg Subject: Re: [Taps] draft minutes from IETF-91 meeting 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, 02 Dec 2014 22:46:00 -0000 --001a113644940487890509437d66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've seen no comments. It would be Really Nice if at least one person could read the minutes before I submit them for the proceedings. --aaron On Sat, Nov 22, 2014 at 4:31 PM, Aaron Falk wrote: > If you spoke up in the Honolulu meeting, please review the minutes to > confirm we captured your point. Thanks to Stuart Cheshire & Michael Welz= l > for their detailed notes. > > Thanks, > > --aaron > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > Transport Services (TAPS) > 1300-1500 HST Tuesday Afternoon Session I > Notes taken by Stuart Cheshire & Michael Welzl > > AGENDA > =3D=3D=3D=3D=3D=3D=3D > 0. Agenda bashing > 1. Charter Overview (Falk) - 10 min > 2. Terminology Review (K=C3=BChlewind) - 30 min > 3. Discussion of draft-fairhurst-taps-transports-00 (K=C3=BChle= wind) > - 20 min > 4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg document= ? > - 10 min > > Action items marked with ** > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > 13:05 Administrivia > > > Aaron Falk: Who was at the TAPS BoF in Toronto? (Most people raised thei= r > hands.) > > Aaron Falk: And who is on the mailing list? (About the same.) > > Aaron Falk: In today=E2=80=99s meeting we=E2=80=99ll be having a discussi= on of > terminology, and then a discussion of the working group=E2=80=99s first d= raft. We > will be looking for volunteers. The current draft is an independent > submission from two volunteers: Gorry Fairhurst and Brian Trammell, neith= er > of whom could be here. We=E2=80=99ll be asking whether the people in the = room want > to adopt this as a Working Group document. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > 13:08 Charter Overview (Falk) =E2=80=93 10 min > > Aaron Falk: The TAPS effort is focussing on the same area as the IAB Stac= k > Evolution work, which is that there have been 20 years of transport area > improvements that are largely undeployed because (i) the new transports a= re > not supported in most operating systems, and (ii) the new transports may > not work end-to-end on today=E2=80=99s Internet. As a result, application > developers often build their own protocol on top of UDP, and sometimes th= at > do that badly. The goal of this group is to enable application developers > to get better performance and better behavior than they can get from TCP = or > UDP. > > The first task of the working group is to define what these behaviors are > that application developers want to get. We call these =E2=80=9Ctransport > services=E2=80=9D. Some examples are: Reliable delivery, in-order deliver= y, > confidentiality, latency. It=E2=80=99s a way for applications to express = what they > want from the transport layer, and to ask for combinations that aren=E2= =80=99t > currently available from TCP and UDP. The transport layer then sees what= =E2=80=99s > available and provides the best that it can, which might be HTTP over TCP= . > To do this we=E2=80=99re first going to examine existing IETF technologie= s to see > what behaviors they provide, to collect an initial set of behaviors that = we > think might be useful. We=E2=80=99re going to focus on communication bet= ween two > endpoints, at least initially. That=E2=80=99s the first document, to sub= mit to the > IESG next June. > > Then there will be a second document which is a prioritization to select = a > subset of those services, and guidance how you might obtain those service= s > using existing mechanisms. We will submit this to the IESG next December. > > The third document describes how to do discovery of whether these things > work, how to do fallback, how to combine the protocols and make them > available. We will submit this to the IESG in 2016. > > We=E2=80=99re not going to do signaling-based QoS. We=E2=80=99re not goin= g to talk about > new encapsulations and tunneling. We=E2=80=99re not going to define, modi= fy, or > extend transport protocols. We=E2=80=99re not going to define a language-= specific > API. We=E2=80=99re not going to do a detailed analysis of security, but = we will > document the security properties of existing protocols. The emphasis of > this work is not security. > > Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow > data-with-SYN, out-of-order delivery) > > Aaron Falk: Yes > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > 13:15 Terminology Review (K=C3=BChlewind) =E2=80=93 30 min > > > (Mirja K=C3=BChlewind gave presentation of proposed terminology) > > Dave Thaler: Why not use term =E2=80=9Cfacility=E2=80=9D instead of =E2= =80=9Cservice component=E2=80=9D? > The term =E2=80=9Cservice component=E2=80=9D usually means a piece of cod= e. > > Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80=9Cpart=E2=80=9D.= That=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9Cunit=E2=80=9D. > > Michael Welzl: I like this a lot. > > Brian Trammell: I=E2=80=99m okay with this suggestion. > > Kevin Fall: Standards Track RFC 2126 defines the term =E2=80=9Ctransport = services=E2=80=9D > as referred to by ISO. Don=E2=80=99t redefine terms that were already def= ined by an > International Standard. > > Mirja K=C3=BChlewind: Our definition is just a little more specific. > > > Kevin Fall: Reliability is not a binary property. UDPLite has partial > reliability. > > Mirja K=C3=BChlewind: We discussed earlier whether we need a concept smal= ler > than a =E2=80=9Cservice component=E2=80=9D for different types of reliabi= lity. We call this > an =E2=80=9Caspect=E2=80=9D. > > Kevin Fall: That term has been reserved as well. > > Joe Hildebrand: Just pick Swiss German words instead, and we=E2=80=99ll a= ll learn > them. This way we have words that don=E2=80=99t have existing meanings in= existing > networking standards. > > Dave Thaler: And then we could try using non-US characters in RFCs. > > Mirja K=C3=BChlewind: I don=E2=80=99t care what we call it. We just have = to agree on > some terminology. Are those six descriptions the right concepts? > > Ignacio Solis: Is =E2=80=9Creliability=E2=80=9D an example of a =E2=80=9C= service component=E2=80=9D? > > Mirja K=C3=BChlewind: Right. A transport service today provides you with = a > whole package of service components, not all of which you may want. It al= so > may not include a service component that you do want. > > Ignacio Solis: We=E2=80=99re being bound by old thinking. > > Kevin Fall: You asked what is missing here. Is it connection-oriented? Is > there connection establishment, notification? Is there flow control? None > of that is mentioned. > > Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice components=E2= =80=9D; a specific > instantiation would be a =E2=80=9Cprotocol feature=E2=80=9D. > > Aaron Falk: The first two terms are things that applications ask for. The > other terms are how you provide those things. > > Brian Trammell: Kevin is describing =E2=80=9Caspects=E2=80=9D. A =E2=80= =9Cfeature=E2=80=9D is a thing that > a protocol does on purpose, an =E2=80=9Caspect=E2=80=9D is something that= it does, whether > on purpose or not. > > Gorry Fairhurst: =E2=80=9CFeature=E2=80=9D is okay. > > Ken Calvert: I would call state establishment =E2=80=9Cmechanism=E2=80=9D= I don=E2=80=99t know if > this will ever converge. Don=E2=80=99t conflate wire encoding with logica= l > implementation. =E2=80=9CMechanism=E2=80=9D is wire encoding + function. = Why are you not > saying =E2=80=9Cfunction=E2=80=9D? > > Mirja K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D and = =E2=80=9Cfunction=E2=80=9D are too > abstract. What you described is still a =E2=80=9Cfeature=E2=80=9D. > > Ken Calvert: I suggest not using =E2=80=9Creliability=E2=80=9D as an exam= ple because there > are too many different kinds of reliability. > > Mirja K=C3=BChlewind: Do you think we need a term for concepts with small= er > granularity than =E2=80=9Ccomponent=E2=80=9D? > > Ken Calvert: For that concept, use a Swiss German word. > > Mirja K=C3=BChlewind: Do we need one more term? > > Ken Calvert: Maybe. > > Andrew McGregor: The decomposition into pieces looks good, but I think > =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D should be swapp= ed. > > Mirja K=C3=BChlewind: I got this feedback already. > > Jana Iyengar: Well, you just got this feedback again. I agree with Andrew= . > We should switch =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80= =9D. A software =E2=80=9Ccomponent=E2=80=9D > implements a =E2=80=9Cfeature=E2=80=9D. > > Mirja K=C3=BChlewind: Switching the terms would help? > > (A bunch of =E2=80=9Cyes=E2=80=9D comments from the room.) > > Aaron Falk: That=E2=80=99s consensus. Move on. > > Edward Lopez: We should talk about segregating transport services from > applications. Applications become independent of transport services. We > should start thinking about the rise of transport service gateways. If yo= ur > application uses UDP and my application uses TCP then something=E2=80=99s= got to > traverse. Is a gateway part of a potential terminology? > > Mirja K=C3=BChlewind: I think that=E2=80=99s out of scope. That would be = a meddlebox. > > Aaron Falk: The use case we=E2=80=99re focussed on is two applications on= two > endpoints. You=E2=80=99re using =E2=80=9Capplication=E2=80=9D in a way th= at=E2=80=99s confusing me. > > Edward Lopez: If we=E2=80=99re talking about transport services and poten= tial > independence from applications, then when a common application is using > different transport services, what=E2=80=99s going to interchange? What= =E2=80=99s going to > aid that conversation? That=E2=80=99s what=E2=80=99s not discussed here. > > Aaron Falk: We have pushed that off. The third effort of the working grou= p > to talk about an experiment with end-to-end compatibility. > > Edward Lopez: Then we=E2=80=99d need transport service negotiation. Separ= ation of > application from transport services leads me to think there=E2=80=99s a t= erm > missing. > > Mirja K=C3=BChlewind: What we want is not that the application is request= ing > TCP. What we want is that the application is requesting a certain service > composition, and then the layer below can make the decision to use TCP. > > Ronald in 't Velt: I have not heard the term =E2=80=9Celement=E2=80=9D ye= t. I agree with > Kevin Fall. Let=E2=80=99s see what=E2=80=99s already there. I have a pape= r copy of ISO 8072 > somewhere. I couldn=E2=80=99t find it. > > Mirja K=C3=BChlewind: I=E2=80=99m sure every term has already been used s= omewhere. > > Jana Iyengar: We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CThi= ng 2=E2=80=9D, =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing > 4=E2=80=9D. Seriously, how would I think about TCP over IPv6 over SSL ove= r IPv4? > > Mirja K=C3=BChlewind: That=E2=80=99s an instance. If you request that ser= vice > composition you get that stack. > > Aaron Falk: Jana, what is the application asking for? > > Pete Resnick: The whole idea of how discovery takes place where both > transports talk to each other and say this is the way we=E2=80=99re going= to > communicate for this particular instance is independent right now and we= =E2=80=99ll > have to figure that out, but it=E2=80=99s not something an application ca= res about. > We need to talk about feature discovery & negotiation. To address Ken=E2= =80=99s > comment, reliability and ordering should absolutely be separate component= s. > > Stuart Cheshire: I want to follow up to Jana=E2=80=99s point. The choice = about > what features to use is not decided only by the application. The choice o= f > TCP vs UDP is decided by the application, but the choice of Ethernet vs > Wi-Fi (with or without VPN) is decided by the user. Similarly, the choice > of VPN or not may be decided by the corporate administrator, not the > application, or the user. > > Aaron: The application needs to express hints about what it wants. You sa= y > there are other hints. Do we need to add something to our taxonomy that > allows that information to get in? > > Stuart: I don=E2=80=99t think it extends this taxonomy, it might be an or= thogonal > dimension. User has an input, administrator has an input, application has > an input. VPN is a classic example: application itself expresses no > interest in security but the user does. > > Andrew McGregor: You can imagine that the API is that the application ask= s > for a set of components, and the OS decides how to do that. > > Ignacio Solis: We are PARC are building something that doesn=E2=80=99t us= e > sockets. We have our own terminology. We call the transport layer the > =E2=80=9Cframework=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with =E2= =80=9Ccomponents=E2=80=9D following the design of > composable stacks. The management component is missing here, especially i= f > we are considering how this relates to middleboxes. > > Mirja K=C3=BChlewind: It would be nice if you could provide some referenc= es to > this work on the list. > > Ignacio Solis: We have quite a number of things we=E2=80=99d be happy to = share. > > Mirja K=C3=BChlewind: You give the application a whole view of what=E2=80= =99s available > at the transport layer. This work is to have an abstraction so the > application doesn=E2=80=99t need to know the details. > > Ignacio Solis: We completely agree. The API hides the details of stack > assembly from the application. But the application needs to be able to pi= ck > the entry component. The application needs to be able to pick the API it= =E2=80=99s > going to use. > > Dave Thaler: I agree with Stuart=E2=80=99s points. I see a relationship b= etween > this and the MIF working group. The MIF working group is doing similar > things here concerning multiple provisioning domains. The application can > express a set of preferences and get back information about what was > chosen. When you think about the choice of saying which L3 protocol, the= y > say =E2=80=9CI=E2=80=99d like to go across a secure interface=E2=80=9D an= d MIF does the interface > selection logic. > > Aaron Falk: Are we re-using any MIF terms or concepts? > > Dave Thaler: I=E2=80=99m not aware of any any terminology collisions. Pos= sibly we > may be using different terms for the same things. The MIF work is > complementary. > > Aaron Falk: Who in the room is active in the MIF working group? > > (Dave Thaler plus one other.) > > Aaron Falk: This whole conversation reminds me of DTN. > > Kevin Fall: With DTN we had to develop a pub/sub-style API. We also came > to the conclusion that a third party needs an API to establish a policy o= n > those bindings. In sockets there=E2=80=99s PF_* and AF_* to express some = of these > desires. But the application can also specify the precise protocols using > IP_PROTO_*. It=E2=80=99s useful to take this choice that used to be wired= in code > and expose it though an API to an agent. The unit of expressing things is > URIs. > > Brian Trammell: So this problem has always been trying to match the crapp= y > interface above the transport to the crappy interface below. The > terminology (and taps charter for that matter) assume the lower interface > can be ignored. Although that might be impossible from a terminology > standpoint. I think we probably don't want to define a term for the > controller... but we might want to have a way to describe the things that > the controller knows about the lower-interface transport aspects and path > aspects. > > Mirja K=C3=BChlewind: The goal for right now is to set up an initial > terminology for us to use. > > Szilveszter: Don=E2=80=99t we have to define how to choose a protocol? Is= it in > TAPS scope to say how we compose a transport? Isn=E2=80=99t it just an in= terface > towards a transport? > > Aaron Falk: That is a question about the working group=E2=80=99s scope. T= he second > document is to pick a subset of all the things an application could ask > for. Right now we=E2=80=99re trying to figure out what those behaviors ar= e. > > Toerless Eckert: Not all of the components here are things that we would > traditionally call =E2=80=9Ctransport=E2=80=9D. Some of the components ar= e in INT area. > E.g. what about name resolution? > > Mirja K=C3=BChlewind: I believe name resolution is not a component. It=E2= =80=99s a > service. This is just a first step. We can still change the terms. > > Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to be > using the same APIs as applications. > > Mirja K=C3=BChlewind: Let=E2=80=99s do the first step first. > > Andrew McGregor: Yes, but diagnostic tools require the ability to specify > an exact stack in order to be able to generate the right sort of packet. > > Aaron Falk: That=E2=80=99s pretty clearly out of scope for the group. The= goal > here is to make things easier for application developers. > > Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an application? > > Mirja K=C3=BChlewind: This should be hidden from the application. > > Andrew McGregor: The =E2=80=9Cping=E2=80=9D program is an application? > > Aaron Falk: No, it=E2=80=99s a utility, which is why it=E2=80=99s out of = scope. > > Michael Welzl: I remember from the BoF there was consensus that we should > have some kind of determinism to flag to provide repeatability for testin= g. > > Jana Iyengar: What Andrew is suggesting would be good. We need better > tools. Without deterministic unique composition, how can you have > interoperability? > > Mirja K=C3=BChlewind: For interoperability we come up with a new shim lay= er. > This is what we want to hide from the application. > > Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot of > layer violations. This working group has =E2=80=9Ctransport=E2=80=9D in t= he name. Ping uses > ICMP. ICMP is not in the transport layer. To Jana=E2=80=99s point, there= =E2=80=99s going to > have to be some sort of rendezvous/discovery. Once an application request= s > a certain set of components, how the system establishes talking to the > other side is just something for the lower layers to implement. > > Joe Hildebrand: Let=E2=80=99s agree what the components are before we deb= ate how > they=E2=80=99re negotiated. > > Andrew McGregor: Ping was a bad example. There=E2=80=99s a python library= called > =E2=80=9Cscapy=E2=80=9D that lets you specify a bunch of properties and l= eave the rest > unspecified and it will try and make it work. From incomplete information > it fills in the gaps to make something sensible. This is a practical > example of something that=E2=80=99s already out there. > > Brian Trammell: The factoring of this terminology, if not the words, > support _everything_ we're talking about here. you can ask for a componen= t, > you can ask for a composition, you can ask for a protocol instance. What = it > doesn't support describing yet is getting info up from the lower layer. > > Kevin Fall: Identification of the endpoint gives me some concern. TCP has > concepts like ports. Semantics are associated with that. The style of > naming is relevant. > > Mirja K=C3=BChlewind: You could have a component =E2=80=9CI want to trans= mit web > traffic=E2=80=9D and then naturally the first thing the transport protoco= l would do > is open a connection on port 80. If that doesn=E2=80=99t work it could do= something > else. > > Kevin Fall: That=E2=80=99s high level example compared to components like > =E2=80=9Creliability=E2=80=9D. > > Mirja K=C3=BChlewind: This is not for sure. This is the next step. We hav= e to > find out what=E2=80=99s out there and how we name these things. > > Kevin Fall: If these high level examples are what you=E2=80=99re talking = about > then high level frameworks well above the sockets layer are relevant. > > Mirja K=C3=BChlewind: I just don=E2=80=99t know. > > Mirja K=C3=BChlewind: My conclusions from discussion: We=E2=80=99ll swit= ch the terms > =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. This is a good= starting point. We can have more > discussions and change things if necessary. We need a term like =E2=80=9C= aspect=E2=80=9D > which is even a lower granularity than =E2=80=9Ccomponent=E2=80=9D. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > 14:07 Discussion of draft-fairhurst-taps-transports-00 > > > Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja K=C3=BChle= wind. > > Goal is to survey existing transport protocols and extract the common > components they have, and the ways they implement those. > > Slide 4: Relationship between transport protocols and service component > > Joe Hildebrand: There are other IETF areas who should be included (like > RAI) that are not in the transport area but offer transport-like > facilities. For example websocket. > > Mirja K=C3=BChlewind: As long as they are IETF protocols they are in scop= e. > > Dave Thaler: I strongly agree with Joe. Now we=E2=80=99re talking about > architecture, how protocols map to services. I want to go back to what > Stuart said about the multiple parties making the various requests. For > example, it is not (usually) the application deciding that the link-layer > should be Ethernet. We need to avoid the case where the applications at > each end request the same service components but get different protocols > and therefore have not interoperability. What that means is that the > mapping from service components to protocol stacks needs to be > deterministic on both ends. > > Mirja K=C3=BChlewind: There should be some kind of shim layer that does s= ome > kind of negotiation to make sure they can communicate. > > Dave Thaler: Okay, but the draft does not say that. > > Michael Welzl: This table may look like it proposes a mapping, but it=E2= =80=99s > just listing the protocols that currently exist. > > Jana Iyengar: Are we explicitly excluding non-IETF protocols? > > Aaron Falk: Yes, for this work item. We might expand the scope later. > > Kevin Fall: In this matrix UDP is defined as unicast, which surprises me > considering that all multicast work uses UDP. How does multicast fit into > this? > > Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast > RESTful verbs. CoAP also has congestion control, so it=E2=80=99s a transp= ort > protocol. > > Mirja K=C3=BChlewind: Right now we want to cover all the obvious transpor= t > protocols. If people want to contribute text for others, we can add those= . > > Aaron Falk: Andrew, is this an area you have expertise in? > > Andrew McGregor: Some. > > ** Aaron Falk: Andrew McGregor will identify a contributor to describe > CoAP (maybe himself). > > Brian (or Robert?) Adamson, NRL: We should solicit additions via the > mailing list. > > Aaron Falk: Please send text. > > Joe Hildebrand: You asked the question: Is this a viable structure? My > answer is: I think so. But we should start with a detailed analysis of > something like TCP to make sure we understand how that fits the model. > > Aaron Falk: I=E2=80=99d suggest exploring two examples so that we have tw= o data > points. Michael already volunteered to do SCTP. > > Slide 5: Who can contribute? > > Dave Thaler: I=E2=80=99m thinking of a type of protocol that=E2=80=99s mi= ssing from the > list, and that=E2=80=99s things like TLS. Applications ask for stuff. Pro= tocols > provide stuff. Applications ask for stuff like confidentiality, integrity= , > etc. Protocols like TLS and IPSEC provide confidentiality, integrity, etc= . > > Mirja K=C3=BChlewind: Please contribute text. > > Dave Thaler: We think in terms of layers, but security is not a layer. > It=E2=80=99s on the side, affecting everything. We need to include the th= ings on > the side too. > > Brian Trammell: Security is definitely an aspect > > Gorry Fairhurst: +1 > > Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComponent=E2= =80=9D? > > Gorry Fairhurst: What we want is a plan to make one of these sections > concrete from someone with expertise in the protocol. > > Mirja K=C3=BChlewind: Yes. > > Brian Trammell: We're asking the structure question here. > > Andrew McGregor: The structure is ugly but I can=E2=80=99t see how it cou= ld be > better. We have to consider how you name the other endpoint. DNS name? UR= L? > Something else? Should that identity be proved in some manner? How? TLS > certificates? HIP identity hash match. > > Mirja K=C3=BChlewind: I don=E2=80=99t need to specify how identity is pro= ved. > > Andrew McGregor: You might if you only have credentials in a particular > form. > > Mirja K=C3=BChlewind: This restricts what the transport protocol can choo= se. > > Joe Hildebrand: Let=E2=80=99s not debate API details until we have the pr= inciples > adequately characterized. Let=E2=80=99s know what the building blocks are= first. > > Aaron Falk: I agree that we should flesh out a couple of sections and use > that as a basis for refining the rest of the document. Who will volunteer > to take on one of these sections? > > ** Kevin Fall: Open mouth, insert work. I will do UDP. > > Mirja K=C3=BChlewind: Are there no MPTCP people here? > > Aaron Falk: What about basic TCP? > > ** Mirja K=C3=BChlewind: I will do basic TCP, but it would be good to hav= e > other people too. > > Varun Singh: Is RTP excluded? > > Mirja K=C3=BChlewind: Will you do that? > > ** Varun Singh: I=E2=80=99ll contribute text for RTP. > > Varun Singh: Is this document on GitHub? > > Mirja K=C3=BChlewind: Gorry Fairhurst and Brian Trammell can decide that. > > Brian Trammell: I can move to markdown over GitHub, no problem. > > Kevin Fall: Are the lessons we learn here going to reflected in the > previous document? > > Mirja K=C3=BChlewind: This document just lists what=E2=80=99s there. > > Kevin Fall: If we discover that idempotency is an important concept, how > does that get added to the document? > > Joe Hildebrand: Finding those is the point of this exercise. > > Aaron Falk: We=E2=80=99ll give you a cookie. > > Varun Singh: It seems like we=E2=80=99re going to replicate a lot of text= from > existing RFCs. > > Aaron Falk: The goal is to take an existing protocol and identify what > services it is offering to the application. That=E2=80=99s what we want t= o get in > this document. > > Mirja K=C3=BChlewind: What you as an expert for some protocol should do i= s > describe the protocol as completely as possible. > > Dave Thaler: What are you looking for in each section? Service components= ? > Protocol features? Both? > > Aaron Falk: I want the protocol components, but the way you get there is > to analyze the protocol features. > > Mirja K=C3=BChlewind: Please provide text. > > ** Dave Thaler: I volunteer to help with getting the matrix right, of > features vs. things that are protocols, e.g. inherent vs. optional is > another key thing for features. I=E2=80=99ve done such work in the past. = It=E2=80=99s > useful to know which things are inherent features, and which things are > optional features. For example, with TCP you can have keepalives or not. > > Mirja K=C3=BChlewind: The first step is to describe the protocols. > > ** Dave Thaler: I=E2=80=99m volunteering to help with the matrix more tha= n the > specific text, but I may be able to do some of that too. > > Jana Iyengar: Let=E2=80=99s not end up with a giant matrix and checkboxes= for > various features. That=E2=80=99s not useful. > > Mirja K=C3=BChlewind: There may be cases where two components do not work > together. > > ** Karen Nielsen: I will provide SCTP text. > > Karen Nielsen: Protocol features like ACK or NACK are not specific to TCP= . > SCTP also has ACKs. You can=E2=80=99t say that protocol features are spec= ific to > one protocol. > > Mirja K=C3=BChlewind: Protocol features are specific to one protocol. > > Karen Nielsen: So SCTP ACK is different to TCP ACK. > > ** P=C3=A5l-Erik Martinsen: I will provide text for STUN > > Charles Eckel: It will be helpful to combine everything into one table. > > Mirja K=C3=BChlewind: Having a single matrix would be really nice for the > document. But the first step is to describe the protocols and extract th= e > components they provide. > > Kenneth Calvert: Is one of the goals here to come out with an ontology of > transport service components? > > Aaron Falk: We are trying to confine the scope to IETF protocols. A > complete ontology would not necessarily be useful. > > Kenneth Calvert: For this draft, before you plunge into the matrix, it > would be useful to define the existing components. > > Mirja K=C3=BChlewind: This is the end goal of the document. > > Brian (or Robert?) Adamson, NRL: Is there a template for a list of the > aspects we care about? > > Mirja K=C3=BChlewind: This is just an initial attempt. > > Brian Trammell: To Kenneth, =E2=80=9Cyes=E2=80=9D (but I am allergic to t= he word ontology.) > > Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2=80=99s the entire= point of > this working group. > > Michael Ramalho: This is a very hard problem when I think about how some > of these protocols were evolved to meet very special needs. Suppose I hav= e > this application that doesn=E2=80=99t want head-of-line-blocking, and may= be I don=E2=80=99t > want to retransmit once or twice, and let=E2=80=99s suppose I have someth= ing > expressive enough to convey this to the transport layer, and it can=E2=80= =99t > deliver this without using multiple TCP connections, and maybe I would ha= ve > preferred DTLS. How do you express that to this layer? > > Mirja K=C3=BChlewind: The document is focussed on the simple cases first. > > Pete Resnick: It would be a terrible failure if, in such situations, the > transport layer would ask the application what to do. The app doesn=E2=80= =99t care > and doesn=E2=80=99t know. That I can pull this off with 3 TCP connections= is not > something the app cares about. You either give the app what it asks for o= r > fail. > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 > > ** 14:43 Aaron Falk called for adopting draft-fairhurst-taps-transports-0= 0 > as WG document. > Folks who read the draft: maybe 10 + > Significant hum in support > None against > > -- END > --001a113644940487890509437d66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've seen no comments.=C2=A0 It would be Really Nice i= f at least one person could read the minutes before I submit them for the p= roceedings. =C2=A0

--aaron

On Sat, Nov 22, 2014 at 4:31 PM, Aa= ron Falk <aaron.falk@gmail.com> wrote:
If you spoke up in the Honolulu meeting, p= lease review the minutes to confirm we captured your point.=C2=A0 Thanks to= Stuart Cheshire & Michael Welzl for their detailed notes.

Thanks,

--aaron

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Transport Services (TAPS)
13= 00-1500 HST Tuesday Afternoon Session I
Notes taken by Stuart Che= shire & Michael Welzl

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 AGENDA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D=3D= =3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0. Agenda bashing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Charter Overview (Falk) - 10 = min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2. Terminology Review (K= =C3=BChlewind) - 30 min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3. Dis= cussion of draft-fairhurst-taps-transports-00 (K=C3=BChlewind) - 20 min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4. Hum: Adopt draft-fairhurst-tap= s-transports-00 as wg document? - 10 min

Action it= ems marked with **

=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

=
13:05 Administrivia

Aaron Falk: Who was at the TAPS BoF in Toronto? =C2=A0(Most people= raised their hands.)

Aaron Falk: And who is on th= e mailing list? =C2=A0(About the same.)

Aaron Falk= : In today=E2=80=99s meeting we=E2=80=99ll be having a discussion of termin= ology, and then a discussion of the working group=E2=80=99s first draft. We= will be looking for volunteers. The current draft is an independent submis= sion from two volunteers: Gorry Fairhurst and Brian Trammell, neither of wh= om could be here. We=E2=80=99ll be asking whether the people in the room wa= nt to adopt this as a Working Group document.

=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94

13:08 Charter Overview (Falk) =E2=80= =93 10 min

Aaron Falk: The TAPS effort is focussin= g on the same area as the IAB Stack Evolution work, which is that there hav= e been 20 years of transport area improvements that are largely undeployed = because (i) the new transports are not supported in most operating systems,= and (ii) the new transports may not work end-to-end on today=E2=80=99s Int= ernet. As a result, application developers often build their own protocol o= n top of UDP, and sometimes that do that badly. The goal of this group is t= o enable application developers to get better performance and better behavi= or than they can get from TCP or UDP.

The first ta= sk of the working group is to define what these behaviors are that applicat= ion developers want to get. We call these =E2=80=9Ctransport services=E2=80= =9D. Some examples are: Reliable delivery, in-order delivery, confidentiali= ty, latency. It=E2=80=99s a way for applications to express what they want = from the transport layer, and to ask for combinations that aren=E2=80=99t c= urrently available from TCP and UDP. The transport layer then sees what=E2= =80=99s available and provides the best that it can, which might be HTTP ov= er TCP.=C2=A0 To do this we=E2=80=99re first going to examine existing IETF= technologies to see what behaviors they provide, to collect an initial set= of behaviors that we think might be useful.=C2=A0 We=E2=80=99re going to f= ocus on communication between two endpoints, at least initially.=C2=A0 That= =E2=80=99s the first document, to submit to the IESG next June.
<= br>
Then there will be a second document which is a prioritizatio= n to select a subset of those services, and guidance how you might obtain t= hose services using existing mechanisms. We will submit this to the IESG ne= xt December.

The third document describes how to d= o discovery of whether these things work, how to do fallback, how to combin= e the protocols and make them available. We will submit this to the IESG in= 2016.

We=E2=80=99re not going to do signaling-bas= ed QoS. We=E2=80=99re not going to talk about new encapsulations and tunnel= ing. We=E2=80=99re not going to define, modify, or extend transport protoco= ls. We=E2=80=99re not going to define a language-specific API.=C2=A0 We=E2= =80=99re not going to do a detailed analysis of security, but we will docum= ent the security properties of existing protocols. The emphasis of this wor= k is not security.

Kevin Fall: Are API changes in = scope? (e.g. changing sockets to allow data-with-SYN, out-of-order delivery= )

Aaron Falk: Yes

=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94

13:15 Terminology Review (K=C3=BChlewind= ) =E2=80=93 30 min

(Mi= rja K=C3=BChlewind gave presentation of proposed terminology)
Dave Thaler: Why not use term =E2=80=9Cfacility=E2=80=9D instea= d of =E2=80=9Cservice component=E2=80=9D? The term =E2=80=9Cservice compone= nt=E2=80=9D usually means a piece of code.

Stein G= jessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80=9Cpart=E2=80=9D. That=E2= =80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9Cunit=E2=80=9D.
=
Michael Welzl: I like this a lot.

B= rian Trammell: I=E2=80=99m okay with this suggestion.

<= div>Kevin Fall: Standards Track RFC 2126 defines the term =E2=80=9Ctranspor= t services=E2=80=9D as referred to by ISO. Don=E2=80=99t redefine terms tha= t were already defined by an International Standard.

Mirja K=C3=BChlewind: Our definition is just a little more specific.


Kevin Fall: Reliability is not a binar= y property. UDPLite has partial reliability.

Mirja= K=C3=BChlewind: We discussed earlier whether we need a concept smaller tha= n a =E2=80=9Cservice component=E2=80=9D for different types of reliability.= We call this an =E2=80=9Caspect=E2=80=9D.

Kevin F= all: That term has been reserved as well.

Joe Hild= ebrand: Just pick Swiss German words instead, and we=E2=80=99ll all learn t= hem. This way we have words that don=E2=80=99t have existing meanings in ex= isting networking standards.

Dave Thaler: And then= we could try using non-US characters in RFCs.

Mir= ja K=C3=BChlewind: I don=E2=80=99t care what we call it. We just have to ag= ree on some terminology. Are those six descriptions the right concepts?

Ignacio Solis: Is =E2=80=9Creliability=E2=80=9D an ex= ample of a =E2=80=9Cservice component=E2=80=9D?

Mi= rja K=C3=BChlewind: Right. A transport service today provides you with a wh= ole package of service components, not all of which you may want. It also m= ay not include a service component that you do want.

Ignacio Solis: We=E2=80=99re being bound by old thinking.

=
Kevin Fall: You asked what is missing here. Is it connection-ori= ented? Is there connection establishment, notification? Is there flow contr= ol? None of that is mentioned.

Mirja K=C3=BChlewin= d: These concepts are =E2=80=9Cservice components=E2=80=9D; a specific inst= antiation would be a =E2=80=9Cprotocol feature=E2=80=9D.

Aaron Falk: The first two terms are things that applications ask for= . The other terms are how you provide those things.

Brian Trammell: Kevin is describing =E2=80=9Caspects=E2=80=9D. A =E2=80= =9Cfeature=E2=80=9D is a thing that a protocol does on purpose, an =E2=80= =9Caspect=E2=80=9D is something that it does, whether on purpose or not.

Gorry Fairhurst: =E2=80=9CFeature=E2=80=9D is okay.<= /div>

Ken Calvert: I would call state establishment =E2= =80=9Cmechanism=E2=80=9D I don=E2=80=99t know if this will ever converge. D= on=E2=80=99t conflate wire encoding with logical implementation. =E2=80=9CM= echanism=E2=80=9D is wire encoding + function. Why are you not saying =E2= =80=9Cfunction=E2=80=9D?

Mirja K=C3=BChlewind: For= me, the terms =E2=80=9Cmechanism=E2=80=9D and =E2=80=9Cfunction=E2=80=9D a= re too abstract. What you described is still a =E2=80=9Cfeature=E2=80=9D.

Ken Calvert: I suggest not using =E2=80=9Creliabili= ty=E2=80=9D as an example because there are too many different kinds of rel= iability.

Mirja K=C3=BChlewind: Do you think we ne= ed a term for concepts with smaller granularity than =E2=80=9Ccomponent=E2= =80=9D?

Ken Calvert: For that concept, use a Swiss= German word.

Mirja K=C3=BChlewind: Do we need one= more term?

Ken Calvert: Maybe.

Andrew McGregor: The decomposition into pieces looks good, but I thi= nk =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D should be swap= ped.

Mirja K=C3=BChlewind: I got this feedback alr= eady.

Jana Iyengar: Well, you just got this feedba= ck again. I agree with Andrew. We should switch =E2=80=9Ccomponent=E2=80=9D= and =E2=80=9Cfeature=E2=80=9D. A software =E2=80=9Ccomponent=E2=80=9D impl= ements a =E2=80=9Cfeature=E2=80=9D.

Mirja K=C3=BCh= lewind: Switching the terms would help?

(A bunch o= f =E2=80=9Cyes=E2=80=9D comments from the room.)

A= aron Falk: That=E2=80=99s consensus. Move on.

Edwa= rd Lopez: We should talk about segregating transport services from applicat= ions. Applications become independent of transport services. We should star= t thinking about the rise of transport service gateways. If your applicatio= n uses UDP and my application uses TCP then something=E2=80=99s got to trav= erse. Is a gateway part of a potential terminology?

Mirja K=C3=BChlewind: I think that=E2=80=99s out of scope. That would be = a meddlebox.

Aaron Falk: The use case we=E2=80=99r= e focussed on is two applications on two endpoints. You=E2=80=99re using = =E2=80=9Capplication=E2=80=9D in a way that=E2=80=99s confusing me.

Edward Lopez: If we=E2=80=99re talking about transport se= rvices and potential independence from applications, then when a common app= lication is using different transport services, what=E2=80=99s going to int= erchange? What=E2=80=99s going to aid that conversation? That=E2=80=99s wha= t=E2=80=99s not discussed here.

Aaron Falk: We hav= e pushed that off. The third effort of the working group to talk about an e= xperiment with end-to-end compatibility.

Edward Lo= pez: Then we=E2=80=99d need transport service negotiation. Separation of ap= plication from transport services leads me to think there=E2=80=99s a term = missing.

Mirja K=C3=BChlewind: What we want is not= that the application is requesting TCP. What we want is that the applicati= on is requesting a certain service composition, and then the layer below ca= n make the decision to use TCP.

Ronald in 't V= elt: I have not heard the term =E2=80=9Celement=E2=80=9D yet. I agree with = Kevin Fall. Let=E2=80=99s see what=E2=80=99s already there. I have a paper = copy of ISO 8072 somewhere. I couldn=E2=80=99t find it.

Mirja K=C3=BChlewind: I=E2=80=99m sure every term has already been us= ed somewhere.

Jana Iyengar: We should call them = =E2=80=9CThing 1=E2=80=9D, =E2=80=9CThing 2=E2=80=9D, =E2=80=9CThing 3=E2= =80=9D, =E2=80=9CThing 4=E2=80=9D. Seriously, how would I think about TCP o= ver IPv6 over SSL over IPv4?

Mirja K=C3=BChlewind:= That=E2=80=99s an instance. If you request that service composition you ge= t that stack.

Aaron Falk: Jana, what is the applic= ation asking for?

Pete Resnick: The whole idea of = how discovery takes place where both transports talk to each other and say = this is the way we=E2=80=99re going to communicate for this particular inst= ance is independent right now and we=E2=80=99ll have to figure that out, bu= t it=E2=80=99s not something an application cares about. We need to talk ab= out feature discovery & negotiation. To address Ken=E2=80=99s comment, = reliability and ordering should absolutely be separate components.

Stuart Cheshire: I want to follow up to Jana=E2=80=99s poi= nt. The choice about what features to use is not decided only by the applic= ation. The choice of TCP vs UDP is decided by the application, but the choi= ce of Ethernet vs Wi-Fi (with or without VPN) is decided by the user. Simil= arly, the choice of VPN or not may be decided by the corporate administrato= r, not the application, or the user.

Aaron: The ap= plication needs to express hints about what it wants. You say there are oth= er hints. Do we need to add something to our taxonomy that allows that info= rmation to get in?

Stuart: I don=E2=80=99t think i= t extends this taxonomy, it might be an orthogonal dimension. User has an i= nput, administrator has an input, application has an input. VPN is a classi= c example: application itself expresses no interest in security but the use= r does.

Andrew McGregor: You can imagine that the = API is that the application asks for a set of components, and the OS decide= s how to do that.

Ignacio Solis: We are PARC are b= uilding something that doesn=E2=80=99t use sockets. We have our own termino= logy. We call the transport layer the =E2=80=9Cframework=E2=80=9D. We build= =E2=80=9Cstacks=E2=80=9D with =E2=80=9Ccomponents=E2=80=9D following the d= esign of composable stacks. The management component is missing here, espec= ially if we are considering how this relates to middleboxes. =C2=A0

Mirja K=C3=BChlewind: It would be nice if you could provi= de some references to this work on the list.

Ignac= io Solis: We have quite a number of things we=E2=80=99d be happy to share.<= /div>

Mirja K=C3=BChlewind: You give the application a w= hole view of what=E2=80=99s available at the transport layer. This work is = to have an abstraction so the application doesn=E2=80=99t need to know the = details.

Ignacio Solis: We completely agree. The A= PI hides the details of stack assembly from the application. But the applic= ation needs to be able to pick the entry component. The application needs t= o be able to pick the API it=E2=80=99s going to use.

Dave Thaler: I agree with Stuart=E2=80=99s points. I see a relationship = between this and the MIF working group. The MIF working group is doing simi= lar things here concerning multiple provisioning domains. The application c= an express a set of preferences and get back information about what was cho= sen.=C2=A0 When you think about the choice of saying which L3 protocol, the= y say =E2=80=9CI=E2=80=99d like to go across a secure interface=E2=80=9D an= d MIF does the interface selection logic.

Aaron Fa= lk: Are we re-using any MIF terms or concepts?

Dav= e Thaler: I=E2=80=99m not aware of any any terminology collisions. Possibly= we may be using different terms for the same things. The MIF work is compl= ementary.

Aaron Falk: Who in the room is active in= the MIF working group?

(Dave Thaler plus one othe= r.)

Aaron Falk: This whole conversation reminds me= of DTN.

Kevin Fall: With DTN we had to develop a = pub/sub-style API. We also came to the conclusion that a third party needs = an API to establish a policy on those bindings. In sockets there=E2=80=99s = PF_* and AF_* to express some of these desires. But the application can als= o specify the precise protocols using IP_PROTO_*. It=E2=80=99s useful to ta= ke this choice that used to be wired in code and expose it though an API to= an agent. The unit of expressing things is URIs.

= Brian Trammell: So this problem has always been trying to match the crappy = interface above the transport to the crappy interface below. The terminolog= y (and taps charter for that matter) assume the lower interface can be igno= red. =C2=A0 Although that might be impossible from a terminology standpoint= . =C2=A0 I think we probably don't want to define a term for the contro= ller... but we might want to have a way to describe the things that the con= troller knows about the lower-interface transport aspects and path aspects.=

Mirja K=C3=BChlewind: The goal for right now is t= o set up an initial terminology for us to use.

Szi= lveszter: Don=E2=80=99t we have to define how to choose a protocol? Is it i= n TAPS scope to say how we compose a transport? Isn=E2=80=99t it just an in= terface towards a transport?

Aaron Falk: That is a= question about the working group=E2=80=99s scope. The second document is t= o pick a subset of all the things an application could ask for. Right now w= e=E2=80=99re trying to figure out what those behaviors are.

<= /div>
Toerless Eckert: Not all of the components here are things that w= e would traditionally call =E2=80=9Ctransport=E2=80=9D. Some of the compone= nts are in INT area.=C2=A0 E.g. what about name resolution?

<= /div>
Mirja K=C3=BChlewind: I believe name resolution is not a componen= t. It=E2=80=99s a service. This is just a first step. We can still change t= he terms.

Andrew McGregor: We want diagnostic tool= s (ping, traceroute, etc.) to be using the same APIs as applications.
=

Mirja K=C3=BChlewind: Let=E2=80=99s do the first step f= irst.

Andrew McGregor: Yes, but diagnostic tools r= equire the ability to specify an exact stack in order to be able to generat= e the right sort of packet.

Aaron Falk: That=E2=80= =99s pretty clearly out of scope for the group. The goal here is to make th= ings easier for application developers.

Andrew McG= regor: Is =E2=80=9Cping=E2=80=9D an application?

M= irja K=C3=BChlewind: This should be hidden from the application.
=
Andrew McGregor: The =E2=80=9Cping=E2=80=9D program is an ap= plication?

Aaron Falk: No, it=E2=80=99s a utility,= which is why it=E2=80=99s out of scope.

Michael W= elzl: I remember from the BoF there was consensus that we should have some = kind of determinism to flag to provide repeatability for testing.

Jana Iyengar: What Andrew is suggesting would be good. We n= eed better tools. Without deterministic unique composition, how can you hav= e interoperability?

Mirja K=C3=BChlewind: For inte= roperability we come up with a new shim layer. This is what we want to hide= from the application.

Pete Resnick: Discussion of= ping, etc, implicitly assumes a whole lot of layer violations. This workin= g group has =E2=80=9Ctransport=E2=80=9D in the name. Ping uses ICMP. ICMP i= s not in the transport layer. To Jana=E2=80=99s point, there=E2=80=99s goin= g to have to be some sort of rendezvous/discovery. Once an application requ= ests a certain set of components, how the system establishes talking to the= other side is just something for the lower layers to implement.
=
Joe Hildebrand: Let=E2=80=99s agree what the components are = before we debate how they=E2=80=99re negotiated.

A= ndrew McGregor: Ping was a bad example. There=E2=80=99s a python library ca= lled =E2=80=9Cscapy=E2=80=9D that lets you specify a bunch of properties an= d leave the rest unspecified and it will try and make it work. From incompl= ete information it fills in the gaps to make something sensible. This is a = practical example of something that=E2=80=99s already out there.
=
Brian Trammell: The factoring of this terminology, if not th= e words, support _everything_ we're talking about here. you can ask for= a component, you can ask for a composition, you can ask for a protocol ins= tance. What it doesn't support describing yet is getting info up from t= he lower layer.

Kevin Fall: Identification of the = endpoint gives me some concern. TCP has concepts like ports. Semantics are = associated with that. The style of naming is relevant.

=
Mirja K=C3=BChlewind: You could have a component =E2=80=9CI want to tr= ansmit web traffic=E2=80=9D and then naturally the first thing the transpor= t protocol would do is open a connection on port 80. If that doesn=E2=80=99= t work it could do something else.

Kevin Fall: Tha= t=E2=80=99s high level example compared to components like =E2=80=9Creliabi= lity=E2=80=9D.

Mirja K=C3=BChlewind: This is not f= or sure. This is the next step. We have to find out what=E2=80=99s out ther= e and how we name these things.

Kevin Fall: If the= se high level examples are what you=E2=80=99re talking about then high leve= l frameworks well above the sockets layer are relevant.

Mirja K=C3=BChlewind: I just don=E2=80=99t know.

=
Mirja K=C3=BChlewind: My conclusions from discussion: =C2=A0We=E2=80= =99ll switch the terms =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2= =80=9D. This is a good starting point. We can have more discussions and cha= nge things if necessary. We need a term like =E2=80=9Caspect=E2=80=9D which= is even a lower granularity than =E2=80=9Ccomponent=E2=80=9D.
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94

14:07 Discussion of= draft-fairhurst-taps-transports-00=C2=A0
=

Authors Gorry Fairhurst and Brian Trammell. Presented b= y Mirja K=C3=BChlewind.

Goal is to survey existing= transport protocols and extract the common components they have, and the w= ays they implement those.

Slide 4: Relationship be= tween transport protocols and service component

Jo= e Hildebrand: There are other IETF areas who should be included (like RAI) = that are not in the transport area but offer transport-like facilities. For= example websocket.

Mirja K=C3=BChlewind: As long = as they are IETF protocols they are in scope.

Dave= Thaler: I strongly agree with Joe. Now we=E2=80=99re talking about archite= cture, how protocols map to services. I want to go back to what Stuart said= about the multiple parties making the various requests. For example, it is= not (usually) the application deciding that the link-layer should be Ether= net. We need to avoid the case where the applications at each end request t= he same service components but get different protocols and therefore have n= ot interoperability. What that means is that the mapping from service compo= nents to protocol stacks needs to be deterministic on both ends.
=
Mirja K=C3=BChlewind: There should be some kind of shim laye= r that does some kind of negotiation to make sure they can communicate.

Dave Thaler: Okay, but the draft does not say that.

Michael Welzl: This table may look like it proposes= a mapping, but it=E2=80=99s just listing the protocols that currently exis= t.

Jana Iyengar: Are we explicitly excluding non-I= ETF protocols?

Aaron Falk: Yes, for this work item= . We might expand the scope later.

Kevin Fall: In = this matrix UDP is defined as unicast, which surprises me considering that = all multicast work uses UDP. How does multicast fit into this?
Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has mul= ticast RESTful verbs. CoAP also has congestion control, so it=E2=80=99s a t= ransport protocol.

Mirja K=C3=BChlewind: Right now= we want to cover all the obvious transport protocols. If people want to co= ntribute text for others, we can add those.

Aaron = Falk: Andrew, is this an area you have expertise in?

Andrew McGregor: Some.

** Aaron Falk: Andrew Mc= Gregor will identify a contributor to describe CoAP (maybe himself).
<= div>
Brian (or Robert?) Adamson, NRL: We should solicit addit= ions via the mailing list.

Aaron Falk: Please send= text.

Joe Hildebrand: You asked the question: Is = this a viable structure? My answer is: I think so. But we should start with= a detailed analysis of something like TCP to make sure we understand how t= hat fits the model.

Aaron Falk: I=E2=80=99d sugges= t exploring two examples so that we have two data points. Michael already v= olunteered to do SCTP.

Slide 5: Who can contribute= ?

Dave Thaler: I=E2=80=99m thinking of a type of p= rotocol that=E2=80=99s missing from the list, and that=E2=80=99s things lik= e TLS. Applications ask for stuff. Protocols provide stuff. Applications as= k for stuff like confidentiality, integrity, etc. Protocols like TLS and IP= SEC provide confidentiality, integrity, etc.

Mirja= K=C3=BChlewind: Please contribute text.

Dave Thal= er: We think in terms of layers, but security is not a layer. It=E2=80=99s = on the side, affecting everything. We need to include the things on the sid= e too.

Brian Trammell: Security is definitely an a= spect

Gorry Fairhurst: +1

Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComponent=E2=80= =9D?

Gorry Fairhurst: What we want is a plan to ma= ke one of these sections concrete from someone with expertise in the protoc= ol.

Mirja K=C3=BChlewind: Yes.

Brian Trammell: We're asking the structure question here.

Andrew McGregor: The structure is ugly but I can=E2=80=99= t see how it could be better. We have to consider how you name the other en= dpoint. DNS name? URL? Something else? Should that identity be proved in so= me manner? How? TLS certificates? HIP identity hash match.

Mirja K=C3=BChlewind: I don=E2=80=99t need to specify how identity= is proved.

Andrew McGregor: You might if you only= have credentials in a particular form.

Mirja K=C3= =BChlewind: This restricts what the transport protocol can choose.

Joe Hildebrand: Let=E2=80=99s not debate API details until= we have the principles adequately characterized. Let=E2=80=99s know what t= he building blocks are first.

Aaron Falk: I agree = that we should flesh out a couple of sections and use that as a basis for r= efining the rest of the document. Who will volunteer to take on one of thes= e sections?

** Kevin Fall: Open mouth, insert work= . I will do UDP.

Mirja K=C3=BChlewind: Are there n= o MPTCP people here?

Aaron Falk: What about basic = TCP?

** Mirja K=C3=BChlewind: I will do basic TCP,= but it would be good to have other people too.

Va= run Singh: Is RTP excluded?

Mirja K=C3=BChlewind: = Will you do that?

** Varun Singh: I=E2=80=99ll con= tribute text for RTP.

Varun Singh: Is this documen= t on GitHub?

Mirja K=C3=BChlewind: Gorry Fairhurst= and Brian Trammell can decide that.

Brian Trammel= l: I can move to markdown over GitHub, no problem.

Kevin Fall: Are the lessons we learn here going to reflected in the previo= us document?

Mirja K=C3=BChlewind: This document j= ust lists what=E2=80=99s there.

Kevin Fall: If we = discover that idempotency is an important concept, how does that get added = to the document?

Joe Hildebrand: Finding those is = the point of this exercise.

Aaron Falk: We=E2=80= =99ll give you a cookie.

Varun Singh: It seems lik= e we=E2=80=99re going to replicate a lot of text from existing RFCs.
<= div>
Aaron Falk: The goal is to take an existing protocol and= identify what services it is offering to the application. That=E2=80=99s w= hat we want to get in this document.

Mirja K=C3=BC= hlewind: What you as an expert for some protocol should do is describe the = protocol as completely as possible.

Dave Thaler: W= hat are you looking for in each section? Service components? Protocol featu= res? Both?

Aaron Falk: I want the protocol compone= nts, but the way you get there is to analyze the protocol features.

Mirja K=C3=BChlewind: Please provide text.

=
** Dave Thaler: I volunteer to help with getting the matrix righ= t, of features vs. things that are protocols, e.g. inherent vs. optional is= another key thing for features. I=E2=80=99ve done such work in the past. I= t=E2=80=99s useful to know which things are inherent features, and which th= ings are optional features. For example, with TCP you can have keepalives o= r not.

Mirja K=C3=BChlewind: The first step is to = describe the protocols.

** Dave Thaler: I=E2=80=99= m volunteering to help with the matrix more than the specific text, but I m= ay be able to do some of that too.

Jana Iyengar: L= et=E2=80=99s not end up with a giant matrix and checkboxes for various feat= ures. That=E2=80=99s not useful.

Mirja K=C3=BChlew= ind: There may be cases where two components do not work together.

** Karen Nielsen: I will provide SCTP text.

=
Karen Nielsen: Protocol features like ACK or NACK are not specif= ic to TCP. SCTP also has ACKs. You can=E2=80=99t say that protocol features= are specific to one protocol.

Mirja K=C3=BChlewin= d: Protocol features are specific to one protocol.

Karen Nielsen: So SCTP ACK is different to TCP ACK.

** P=C3=A5l-Erik Martinsen: I will provide text for STUN

<= /div>
Charles Eckel: It will be helpful to combine everything into one = table.

Mirja K=C3=BChlewind: Having a single matri= x would be really nice for the document.=C2=A0 But the first step is to des= cribe the protocols and extract the components they provide.

=
Kenneth Calvert: Is one of the goals here to come out with an on= tology of transport service components?

Aaron Falk= : We are trying to confine the scope to IETF protocols. A complete ontology= would not necessarily be useful.

Kenneth Calvert:= For this draft, before you plunge into the matrix, it would be useful to d= efine the existing components.

Mirja K=C3=BChlewin= d: This is the end goal of the document.

Brian (or= Robert?) Adamson, NRL: Is there a template for a list of the aspects we ca= re about?

Mirja K=C3=BChlewind: This is just an in= itial attempt.

Brian Trammell: To Kenneth, =E2=80= =9Cyes=E2=80=9D (but I am allergic to the word ontology.)

Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2=80=99s the = entire point of this working group.

Michael Ramalh= o: This is a very hard problem when I think about how some of these protoco= ls were evolved to meet very special needs. Suppose I have this application= that doesn=E2=80=99t want head-of-line-blocking, and maybe I don=E2=80=99t= want to retransmit once or twice, and let=E2=80=99s suppose I have somethi= ng expressive enough to convey this to the transport layer, and it can=E2= =80=99t deliver this without using multiple TCP connections, and maybe I wo= uld have preferred DTLS. How do you express that to this layer?
<= br>
Mirja K=C3=BChlewind: The document is focussed on the simple = cases first.

Pete Resnick: It would be a terrible = failure if, in such situations, the transport layer would ask the applicati= on what to do. The app doesn=E2=80=99t care and doesn=E2=80=99t know. That = I can pull this off with 3 TCP connections is not something the app cares a= bout. You either give the app what it asks for or fail.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94

** 14:43 Aaron Falk called f= or adopting draft-fairhurst-taps-transports-00 as WG document.
Fo= lks who read the draft: maybe 10 +
Significant hum in support
None against

-- END

--001a113644940487890509437d66-- From nobody Tue Dec 2 15:31:33 2014 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 4D6161A1AFC for ; Tue, 2 Dec 2014 15:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 PTDLf495Fb_e for ; Tue, 2 Dec 2014 15:31:30 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1751A1BCA for ; Tue, 2 Dec 2014 15:31:29 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id hq11so6437780vcb.3 for ; Tue, 02 Dec 2014 15:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=y7SdXjid7SWJHIsPyhKUMBsbXRMhC+/AIDJYW7BJxbo=; b=pZ+k1miheV0MbTeK2HxCLfHCnUNaTIb0aPTBcIcZNoshKoycMOmHpiHbYv6p+E/ri+ +6DcKLYmzHQmqGSK26a49K9/2sCFBERhUVqNs639Gn6sJL8ST1sG/O+fQIK7J8TU6i6Z ebLyjLh0C0Qc5IraI81NQcXFTx6CQQqH3KsScJR/ojbImGLRGWn5mOLFRVVdUv9u6IBd /Mx13oBKkyHa+GLsQIqHWpQIovNx5Tmj5WS/4I6uRmhDaQh+bXyId549bmLmFI8CMzH6 rPNdzhX9gaxTEUN8Y1PpQwPZiMXGxhZEdg/hsnweT0rrDqxCYD8UOzbUD2JU4IjZ+4UL Cg3A== MIME-Version: 1.0 X-Received: by 10.220.195.132 with SMTP id ec4mr1304922vcb.16.1417563088967; Tue, 02 Dec 2014 15:31:28 -0800 (PST) Received: by 10.52.28.174 with HTTP; Tue, 2 Dec 2014 15:31:28 -0800 (PST) Date: Tue, 2 Dec 2014 18:31:28 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1ba985d5e100509442037 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Zj3-LzKIs9NunLg-36O1fJs9dEM Subject: [Taps] doc update 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, 02 Dec 2014 23:31:31 -0000 --001a11c1ba985d5e100509442037 Content-Type: text/plain; charset=UTF-8 Hi Folks- A quick update on doc 1. For folks who've agreed to author text, it would be useful to have some sample sections as a model. Brian tells me the plan is to get a -00 out with (1) updates from the meeting (primarily on terminology and structure) and (2) an example transport protocol section out the door before the end of the year. So, stay tuned! Cheers, --aaron --001a11c1ba985d5e100509442037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks-

A quick update on doc 1.=C2=A0 For folks who= 've agreed to author text, it would be useful to have some sample secti= ons as a model.=C2=A0 Brian tells me the plan is to get a -00 out with (1) = updates from the meeting (primarily on terminology and structure) and (2) a= n example transport protocol section out the door before the end of the yea= r.=C2=A0 So, stay tuned!

Cheers,

--aaron
--001a11c1ba985d5e100509442037-- From nobody Tue Dec 2 18:00:52 2014 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 BBECA1A8904 for ; Tue, 2 Dec 2014 18:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=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 F2xAy7ppdiUr for ; Tue, 2 Dec 2014 18:00:36 -0800 (PST) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA29E1A8907 for ; Tue, 2 Dec 2014 18:00:33 -0800 (PST) Received: by mail-vc0-f176.google.com with SMTP id hq12so6266661vcb.7 for ; Tue, 02 Dec 2014 18:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kjOfQpKONIz2uA6Oqz82zmKFqVh/lyzMhEOvxPLMcsE=; b=NZ/fNZye7tyfaZ7dFPYMhb0w4yBwnv4ogtzAa0wqcr2aivSdQLh6nJ3zB1oISjA0a0 slhTPMa0XLPvohY7hRFRu8QNHwCBPGm3AMUJ0KNrp/+OVNGbj0QwzA+9IBUeCC+E4SwS QiUlu9xxD9uSyh/bNBgakQIeASl/cuoit6zofStrcTg22ZncLuk7jgU7B1S3+/JfJJj+ lYbZiDwrRuH5Qo0CtLVa+wHoSaX+8UYb0N8y8MYeU5iXC8vKbzWlQR1122+onRGvbNW9 ZEZUNkrz/80tx4IKyRb1Zdk0O68apeyloHKUevTboMID+S0y2o9NVYplOk5dEDHq1rCS CVfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kjOfQpKONIz2uA6Oqz82zmKFqVh/lyzMhEOvxPLMcsE=; b=G/Sk2DMrNJUxxJv4oP3vQDFqSuLQ/k23FKoWJtD4DbGuUEvgvHRHxHOxLXMHTCd1xo ZT4rshlR9SOQWgS5PJ8Vv9YqbAlgG/wjU3uyH6zlQe7YseAdjBd7XH5KItvUS8UieZII 5tqmm0XtLlfSxY6wy+cfKyAgBbYDRawW4uNGtiXWUtPdmwcZQlUqBlPeUvRocESTc6td YSKjcyvXRBAlSorTdh7K0DKA5UX9yLVLvowmfZbym8O5u5VnM/NonvUiyxMHNi0tjLQh 23j8fQjbP6+q1au8/IvsB3zS7k95qkT56q2fPIX+IDdM/2NE/4IYaOfnJIPOnYQwW9jc PoXw== X-Gm-Message-State: ALoCoQmksf3TDbFp4xNNF657Xxrhfxw/2yai5FwlrV8D6a4t2doYxb035kj6VgDiwr0LIvoP95Rb MIME-Version: 1.0 X-Received: by 10.221.58.204 with SMTP id wl12mr1557169vcb.78.1417572032757; Tue, 02 Dec 2014 18:00:32 -0800 (PST) Received: by 10.52.163.174 with HTTP; Tue, 2 Dec 2014 18:00:32 -0800 (PST) In-Reply-To: References: Date: Tue, 2 Dec 2014 18:00:32 -0800 Message-ID: From: Jana Iyengar To: Aaron Falk Content-Type: multipart/alternative; boundary=001a113363a474dae9050946352a Archived-At: http://mailarchive.ietf.org/arch/msg/taps/3dmWV2BWHhKGRg704dQTjMnuU4g Cc: "taps@ietf.org" Subject: Re: [Taps] draft minutes from IETF-91 meeting 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, 03 Dec 2014 02:00:47 -0000 --001a113363a474dae9050946352a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aaron, I read through the comments and they're accurate AFAICT. On Tue, Dec 2, 2014 at 2:45 PM, Aaron Falk wrote: > I've seen no comments. It would be Really Nice if at least one person > could read the minutes before I submit them for the proceedings. > > --aaron > > On Sat, Nov 22, 2014 at 4:31 PM, Aaron Falk wrote: > >> If you spoke up in the Honolulu meeting, please review the minutes to >> confirm we captured your point. Thanks to Stuart Cheshire & Michael Wel= zl >> for their detailed notes. >> >> Thanks, >> >> --aaron >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> >> Transport Services (TAPS) >> 1300-1500 HST Tuesday Afternoon Session I >> Notes taken by Stuart Cheshire & Michael Welzl >> >> AGENDA >> =3D=3D=3D=3D=3D=3D=3D >> 0. Agenda bashing >> 1. Charter Overview (Falk) - 10 min >> 2. Terminology Review (K=C3=BChlewind) - 30 min >> 3. Discussion of draft-fairhurst-taps-transports-00 (K=C3=BChl= ewind) >> - 20 min >> 4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg >> document? - 10 min >> >> Action items marked with ** >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 >> >> 13:05 Administrivia >> >> >> Aaron Falk: Who was at the TAPS BoF in Toronto? (Most people raised >> their hands.) >> >> Aaron Falk: And who is on the mailing list? (About the same.) >> >> Aaron Falk: In today=E2=80=99s meeting we=E2=80=99ll be having a discuss= ion of >> terminology, and then a discussion of the working group=E2=80=99s first = draft. We >> will be looking for volunteers. The current draft is an independent >> submission from two volunteers: Gorry Fairhurst and Brian Trammell, neit= her >> of whom could be here. We=E2=80=99ll be asking whether the people in the= room want >> to adopt this as a Working Group document. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 >> >> 13:08 Charter Overview (Falk) =E2=80=93 10 min >> >> Aaron Falk: The TAPS effort is focussing on the same area as the IAB >> Stack Evolution work, which is that there have been 20 years of transpor= t >> area improvements that are largely undeployed because (i) the new >> transports are not supported in most operating systems, and (ii) the new >> transports may not work end-to-end on today=E2=80=99s Internet. As a res= ult, >> application developers often build their own protocol on top of UDP, and >> sometimes that do that badly. The goal of this group is to enable >> application developers to get better performance and better behavior tha= n >> they can get from TCP or UDP. >> >> The first task of the working group is to define what these behaviors ar= e >> that application developers want to get. We call these =E2=80=9Ctranspor= t >> services=E2=80=9D. Some examples are: Reliable delivery, in-order delive= ry, >> confidentiality, latency. It=E2=80=99s a way for applications to express= what they >> want from the transport layer, and to ask for combinations that aren=E2= =80=99t >> currently available from TCP and UDP. The transport layer then sees what= =E2=80=99s >> available and provides the best that it can, which might be HTTP over TC= P. >> To do this we=E2=80=99re first going to examine existing IETF technologi= es to see >> what behaviors they provide, to collect an initial set of behaviors that= we >> think might be useful. We=E2=80=99re going to focus on communication be= tween two >> endpoints, at least initially. That=E2=80=99s the first document, to su= bmit to the >> IESG next June. >> >> Then there will be a second document which is a prioritization to select >> a subset of those services, and guidance how you might obtain those >> services using existing mechanisms. We will submit this to the IESG next >> December. >> >> The third document describes how to do discovery of whether these things >> work, how to do fallback, how to combine the protocols and make them >> available. We will submit this to the IESG in 2016. >> >> We=E2=80=99re not going to do signaling-based QoS. We=E2=80=99re not goi= ng to talk about >> new encapsulations and tunneling. We=E2=80=99re not going to define, mod= ify, or >> extend transport protocols. We=E2=80=99re not going to define a language= -specific >> API. We=E2=80=99re not going to do a detailed analysis of security, but= we will >> document the security properties of existing protocols. The emphasis of >> this work is not security. >> >> Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow >> data-with-SYN, out-of-order delivery) >> >> Aaron Falk: Yes >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 >> >> 13:15 Terminology Review (K=C3=BChlewind) =E2=80=93 30 min >> >> >> (Mirja K=C3=BChlewind gave presentation of proposed terminology) >> >> Dave Thaler: Why not use term =E2=80=9Cfacility=E2=80=9D instead of =E2= =80=9Cservice component=E2=80=9D? >> The term =E2=80=9Cservice component=E2=80=9D usually means a piece of co= de. >> >> Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80=9Cpart=E2=80=9D= . That=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9Cunit=E2=80=9D. >> >> Michael Welzl: I like this a lot. >> >> Brian Trammell: I=E2=80=99m okay with this suggestion. >> >> Kevin Fall: Standards Track RFC 2126 defines the term =E2=80=9Ctransport >> services=E2=80=9D as referred to by ISO. Don=E2=80=99t redefine terms th= at were already >> defined by an International Standard. >> >> Mirja K=C3=BChlewind: Our definition is just a little more specific. >> >> >> Kevin Fall: Reliability is not a binary property. UDPLite has partial >> reliability. >> >> Mirja K=C3=BChlewind: We discussed earlier whether we need a concept sma= ller >> than a =E2=80=9Cservice component=E2=80=9D for different types of reliab= ility. We call this >> an =E2=80=9Caspect=E2=80=9D. >> >> Kevin Fall: That term has been reserved as well. >> >> Joe Hildebrand: Just pick Swiss German words instead, and we=E2=80=99ll = all learn >> them. This way we have words that don=E2=80=99t have existing meanings i= n existing >> networking standards. >> >> Dave Thaler: And then we could try using non-US characters in RFCs. >> >> Mirja K=C3=BChlewind: I don=E2=80=99t care what we call it. We just have= to agree on >> some terminology. Are those six descriptions the right concepts? >> >> Ignacio Solis: Is =E2=80=9Creliability=E2=80=9D an example of a =E2=80= =9Cservice component=E2=80=9D? >> >> Mirja K=C3=BChlewind: Right. A transport service today provides you with= a >> whole package of service components, not all of which you may want. It a= lso >> may not include a service component that you do want. >> >> Ignacio Solis: We=E2=80=99re being bound by old thinking. >> >> Kevin Fall: You asked what is missing here. Is it connection-oriented? I= s >> there connection establishment, notification? Is there flow control? Non= e >> of that is mentioned. >> >> Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice components=E2= =80=9D; a specific >> instantiation would be a =E2=80=9Cprotocol feature=E2=80=9D. >> >> Aaron Falk: The first two terms are things that applications ask for. Th= e >> other terms are how you provide those things. >> >> Brian Trammell: Kevin is describing =E2=80=9Caspects=E2=80=9D. A =E2=80= =9Cfeature=E2=80=9D is a thing >> that a protocol does on purpose, an =E2=80=9Caspect=E2=80=9D is somethin= g that it does, >> whether on purpose or not. >> >> Gorry Fairhurst: =E2=80=9CFeature=E2=80=9D is okay. >> >> Ken Calvert: I would call state establishment =E2=80=9Cmechanism=E2=80= =9D I don=E2=80=99t know if >> this will ever converge. Don=E2=80=99t conflate wire encoding with logic= al >> implementation. =E2=80=9CMechanism=E2=80=9D is wire encoding + function.= Why are you not >> saying =E2=80=9Cfunction=E2=80=9D? >> >> Mirja K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D and = =E2=80=9Cfunction=E2=80=9D are too >> abstract. What you described is still a =E2=80=9Cfeature=E2=80=9D. >> >> Ken Calvert: I suggest not using =E2=80=9Creliability=E2=80=9D as an exa= mple because >> there are too many different kinds of reliability. >> >> Mirja K=C3=BChlewind: Do you think we need a term for concepts with smal= ler >> granularity than =E2=80=9Ccomponent=E2=80=9D? >> >> Ken Calvert: For that concept, use a Swiss German word. >> >> Mirja K=C3=BChlewind: Do we need one more term? >> >> Ken Calvert: Maybe. >> >> Andrew McGregor: The decomposition into pieces looks good, but I think >> =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D should be swap= ped. >> >> Mirja K=C3=BChlewind: I got this feedback already. >> >> Jana Iyengar: Well, you just got this feedback again. I agree with >> Andrew. We should switch =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeatur= e=E2=80=9D. A software =E2=80=9Ccomponent=E2=80=9D >> implements a =E2=80=9Cfeature=E2=80=9D. >> >> Mirja K=C3=BChlewind: Switching the terms would help? >> >> (A bunch of =E2=80=9Cyes=E2=80=9D comments from the room.) >> >> Aaron Falk: That=E2=80=99s consensus. Move on. >> >> Edward Lopez: We should talk about segregating transport services from >> applications. Applications become independent of transport services. We >> should start thinking about the rise of transport service gateways. If y= our >> application uses UDP and my application uses TCP then something=E2=80=99= s got to >> traverse. Is a gateway part of a potential terminology? >> >> Mirja K=C3=BChlewind: I think that=E2=80=99s out of scope. That would be= a meddlebox. >> >> Aaron Falk: The use case we=E2=80=99re focussed on is two applications o= n two >> endpoints. You=E2=80=99re using =E2=80=9Capplication=E2=80=9D in a way t= hat=E2=80=99s confusing me. >> >> Edward Lopez: If we=E2=80=99re talking about transport services and pote= ntial >> independence from applications, then when a common application is using >> different transport services, what=E2=80=99s going to interchange? What= =E2=80=99s going to >> aid that conversation? That=E2=80=99s what=E2=80=99s not discussed here. >> >> Aaron Falk: We have pushed that off. The third effort of the working >> group to talk about an experiment with end-to-end compatibility. >> >> Edward Lopez: Then we=E2=80=99d need transport service negotiation. Sepa= ration of >> application from transport services leads me to think there=E2=80=99s a = term >> missing. >> >> Mirja K=C3=BChlewind: What we want is not that the application is reques= ting >> TCP. What we want is that the application is requesting a certain servic= e >> composition, and then the layer below can make the decision to use TCP. >> >> Ronald in 't Velt: I have not heard the term =E2=80=9Celement=E2=80=9D y= et. I agree with >> Kevin Fall. Let=E2=80=99s see what=E2=80=99s already there. I have a pap= er copy of ISO 8072 >> somewhere. I couldn=E2=80=99t find it. >> >> Mirja K=C3=BChlewind: I=E2=80=99m sure every term has already been used = somewhere. >> >> Jana Iyengar: We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CTh= ing 2=E2=80=9D, =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing >> 4=E2=80=9D. Seriously, how would I think about TCP over IPv6 over SSL ov= er IPv4? >> >> Mirja K=C3=BChlewind: That=E2=80=99s an instance. If you request that se= rvice >> composition you get that stack. >> >> Aaron Falk: Jana, what is the application asking for? >> >> Pete Resnick: The whole idea of how discovery takes place where both >> transports talk to each other and say this is the way we=E2=80=99re goin= g to >> communicate for this particular instance is independent right now and we= =E2=80=99ll >> have to figure that out, but it=E2=80=99s not something an application c= ares about. >> We need to talk about feature discovery & negotiation. To address Ken=E2= =80=99s >> comment, reliability and ordering should absolutely be separate componen= ts. >> >> Stuart Cheshire: I want to follow up to Jana=E2=80=99s point. The choice= about >> what features to use is not decided only by the application. The choice = of >> TCP vs UDP is decided by the application, but the choice of Ethernet vs >> Wi-Fi (with or without VPN) is decided by the user. Similarly, the choic= e >> of VPN or not may be decided by the corporate administrator, not the >> application, or the user. >> >> Aaron: The application needs to express hints about what it wants. You >> say there are other hints. Do we need to add something to our taxonomy t= hat >> allows that information to get in? >> >> Stuart: I don=E2=80=99t think it extends this taxonomy, it might be an o= rthogonal >> dimension. User has an input, administrator has an input, application ha= s >> an input. VPN is a classic example: application itself expresses no >> interest in security but the user does. >> >> Andrew McGregor: You can imagine that the API is that the application >> asks for a set of components, and the OS decides how to do that. >> >> Ignacio Solis: We are PARC are building something that doesn=E2=80=99t u= se >> sockets. We have our own terminology. We call the transport layer the >> =E2=80=9Cframework=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with =E2= =80=9Ccomponents=E2=80=9D following the design of >> composable stacks. The management component is missing here, especially = if >> we are considering how this relates to middleboxes. >> >> Mirja K=C3=BChlewind: It would be nice if you could provide some referen= ces to >> this work on the list. >> >> Ignacio Solis: We have quite a number of things we=E2=80=99d be happy to= share. >> >> Mirja K=C3=BChlewind: You give the application a whole view of what=E2= =80=99s >> available at the transport layer. This work is to have an abstraction so >> the application doesn=E2=80=99t need to know the details. >> >> Ignacio Solis: We completely agree. The API hides the details of stack >> assembly from the application. But the application needs to be able to p= ick >> the entry component. The application needs to be able to pick the API it= =E2=80=99s >> going to use. >> >> Dave Thaler: I agree with Stuart=E2=80=99s points. I see a relationship = between >> this and the MIF working group. The MIF working group is doing similar >> things here concerning multiple provisioning domains. The application ca= n >> express a set of preferences and get back information about what was >> chosen. When you think about the choice of saying which L3 protocol, th= ey >> say =E2=80=9CI=E2=80=99d like to go across a secure interface=E2=80=9D a= nd MIF does the interface >> selection logic. >> >> Aaron Falk: Are we re-using any MIF terms or concepts? >> >> Dave Thaler: I=E2=80=99m not aware of any any terminology collisions. Po= ssibly we >> may be using different terms for the same things. The MIF work is >> complementary. >> >> Aaron Falk: Who in the room is active in the MIF working group? >> >> (Dave Thaler plus one other.) >> >> Aaron Falk: This whole conversation reminds me of DTN. >> >> Kevin Fall: With DTN we had to develop a pub/sub-style API. We also came >> to the conclusion that a third party needs an API to establish a policy = on >> those bindings. In sockets there=E2=80=99s PF_* and AF_* to express some= of these >> desires. But the application can also specify the precise protocols usin= g >> IP_PROTO_*. It=E2=80=99s useful to take this choice that used to be wire= d in code >> and expose it though an API to an agent. The unit of expressing things i= s >> URIs. >> >> Brian Trammell: So this problem has always been trying to match the >> crappy interface above the transport to the crappy interface below. The >> terminology (and taps charter for that matter) assume the lower interfac= e >> can be ignored. Although that might be impossible from a terminology >> standpoint. I think we probably don't want to define a term for the >> controller... but we might want to have a way to describe the things tha= t >> the controller knows about the lower-interface transport aspects and pat= h >> aspects. >> >> Mirja K=C3=BChlewind: The goal for right now is to set up an initial >> terminology for us to use. >> >> Szilveszter: Don=E2=80=99t we have to define how to choose a protocol? I= s it in >> TAPS scope to say how we compose a transport? Isn=E2=80=99t it just an i= nterface >> towards a transport? >> >> Aaron Falk: That is a question about the working group=E2=80=99s scope. = The >> second document is to pick a subset of all the things an application cou= ld >> ask for. Right now we=E2=80=99re trying to figure out what those behavio= rs are. >> >> Toerless Eckert: Not all of the components here are things that we would >> traditionally call =E2=80=9Ctransport=E2=80=9D. Some of the components a= re in INT area. >> E.g. what about name resolution? >> >> Mirja K=C3=BChlewind: I believe name resolution is not a component. It= =E2=80=99s a >> service. This is just a first step. We can still change the terms. >> >> Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to be >> using the same APIs as applications. >> >> Mirja K=C3=BChlewind: Let=E2=80=99s do the first step first. >> >> Andrew McGregor: Yes, but diagnostic tools require the ability to specif= y >> an exact stack in order to be able to generate the right sort of packet. >> >> Aaron Falk: That=E2=80=99s pretty clearly out of scope for the group. Th= e goal >> here is to make things easier for application developers. >> >> Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an application? >> >> Mirja K=C3=BChlewind: This should be hidden from the application. >> >> Andrew McGregor: The =E2=80=9Cping=E2=80=9D program is an application? >> >> Aaron Falk: No, it=E2=80=99s a utility, which is why it=E2=80=99s out of= scope. >> >> Michael Welzl: I remember from the BoF there was consensus that we shoul= d >> have some kind of determinism to flag to provide repeatability for testi= ng. >> >> Jana Iyengar: What Andrew is suggesting would be good. We need better >> tools. Without deterministic unique composition, how can you have >> interoperability? >> >> Mirja K=C3=BChlewind: For interoperability we come up with a new shim la= yer. >> This is what we want to hide from the application. >> >> Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot of >> layer violations. This working group has =E2=80=9Ctransport=E2=80=9D in = the name. Ping uses >> ICMP. ICMP is not in the transport layer. To Jana=E2=80=99s point, there= =E2=80=99s going to >> have to be some sort of rendezvous/discovery. Once an application reques= ts >> a certain set of components, how the system establishes talking to the >> other side is just something for the lower layers to implement. >> >> Joe Hildebrand: Let=E2=80=99s agree what the components are before we de= bate how >> they=E2=80=99re negotiated. >> >> Andrew McGregor: Ping was a bad example. There=E2=80=99s a python librar= y called >> =E2=80=9Cscapy=E2=80=9D that lets you specify a bunch of properties and = leave the rest >> unspecified and it will try and make it work. From incomplete informatio= n >> it fills in the gaps to make something sensible. This is a practical >> example of something that=E2=80=99s already out there. >> >> Brian Trammell: The factoring of this terminology, if not the words, >> support _everything_ we're talking about here. you can ask for a compone= nt, >> you can ask for a composition, you can ask for a protocol instance. What= it >> doesn't support describing yet is getting info up from the lower layer. >> >> Kevin Fall: Identification of the endpoint gives me some concern. TCP ha= s >> concepts like ports. Semantics are associated with that. The style of >> naming is relevant. >> >> Mirja K=C3=BChlewind: You could have a component =E2=80=9CI want to tran= smit web >> traffic=E2=80=9D and then naturally the first thing the transport protoc= ol would do >> is open a connection on port 80. If that doesn=E2=80=99t work it could d= o something >> else. >> >> Kevin Fall: That=E2=80=99s high level example compared to components lik= e >> =E2=80=9Creliability=E2=80=9D. >> >> Mirja K=C3=BChlewind: This is not for sure. This is the next step. We ha= ve to >> find out what=E2=80=99s out there and how we name these things. >> >> Kevin Fall: If these high level examples are what you=E2=80=99re talking= about >> then high level frameworks well above the sockets layer are relevant. >> >> Mirja K=C3=BChlewind: I just don=E2=80=99t know. >> >> Mirja K=C3=BChlewind: My conclusions from discussion: We=E2=80=99ll swi= tch the terms >> =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. This is a goo= d starting point. We can have more >> discussions and change things if necessary. We need a term like =E2=80= =9Caspect=E2=80=9D >> which is even a lower granularity than =E2=80=9Ccomponent=E2=80=9D. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 >> >> 14:07 Discussion of draft-fairhurst-taps-transports-00 >> >> >> Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja K=C3=BChl= ewind. >> >> Goal is to survey existing transport protocols and extract the common >> components they have, and the ways they implement those. >> >> Slide 4: Relationship between transport protocols and service component >> >> Joe Hildebrand: There are other IETF areas who should be included (like >> RAI) that are not in the transport area but offer transport-like >> facilities. For example websocket. >> >> Mirja K=C3=BChlewind: As long as they are IETF protocols they are in sco= pe. >> >> Dave Thaler: I strongly agree with Joe. Now we=E2=80=99re talking about >> architecture, how protocols map to services. I want to go back to what >> Stuart said about the multiple parties making the various requests. For >> example, it is not (usually) the application deciding that the link-laye= r >> should be Ethernet. We need to avoid the case where the applications at >> each end request the same service components but get different protocols >> and therefore have not interoperability. What that means is that the >> mapping from service components to protocol stacks needs to be >> deterministic on both ends. >> >> Mirja K=C3=BChlewind: There should be some kind of shim layer that does = some >> kind of negotiation to make sure they can communicate. >> >> Dave Thaler: Okay, but the draft does not say that. >> >> Michael Welzl: This table may look like it proposes a mapping, but it=E2= =80=99s >> just listing the protocols that currently exist. >> >> Jana Iyengar: Are we explicitly excluding non-IETF protocols? >> >> Aaron Falk: Yes, for this work item. We might expand the scope later. >> >> Kevin Fall: In this matrix UDP is defined as unicast, which surprises me >> considering that all multicast work uses UDP. How does multicast fit int= o >> this? >> >> Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast >> RESTful verbs. CoAP also has congestion control, so it=E2=80=99s a trans= port >> protocol. >> >> Mirja K=C3=BChlewind: Right now we want to cover all the obvious transpo= rt >> protocols. If people want to contribute text for others, we can add thos= e. >> >> Aaron Falk: Andrew, is this an area you have expertise in? >> >> Andrew McGregor: Some. >> >> ** Aaron Falk: Andrew McGregor will identify a contributor to describe >> CoAP (maybe himself). >> >> Brian (or Robert?) Adamson, NRL: We should solicit additions via the >> mailing list. >> >> Aaron Falk: Please send text. >> >> Joe Hildebrand: You asked the question: Is this a viable structure? My >> answer is: I think so. But we should start with a detailed analysis of >> something like TCP to make sure we understand how that fits the model. >> >> Aaron Falk: I=E2=80=99d suggest exploring two examples so that we have t= wo data >> points. Michael already volunteered to do SCTP. >> >> Slide 5: Who can contribute? >> >> Dave Thaler: I=E2=80=99m thinking of a type of protocol that=E2=80=99s m= issing from the >> list, and that=E2=80=99s things like TLS. Applications ask for stuff. Pr= otocols >> provide stuff. Applications ask for stuff like confidentiality, integrit= y, >> etc. Protocols like TLS and IPSEC provide confidentiality, integrity, et= c. >> >> Mirja K=C3=BChlewind: Please contribute text. >> >> Dave Thaler: We think in terms of layers, but security is not a layer. >> It=E2=80=99s on the side, affecting everything. We need to include the t= hings on >> the side too. >> >> Brian Trammell: Security is definitely an aspect >> >> Gorry Fairhurst: +1 >> >> Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComponent=E2= =80=9D? >> >> Gorry Fairhurst: What we want is a plan to make one of these sections >> concrete from someone with expertise in the protocol. >> >> Mirja K=C3=BChlewind: Yes. >> >> Brian Trammell: We're asking the structure question here. >> >> Andrew McGregor: The structure is ugly but I can=E2=80=99t see how it co= uld be >> better. We have to consider how you name the other endpoint. DNS name? U= RL? >> Something else? Should that identity be proved in some manner? How? TLS >> certificates? HIP identity hash match. >> >> Mirja K=C3=BChlewind: I don=E2=80=99t need to specify how identity is pr= oved. >> >> Andrew McGregor: You might if you only have credentials in a particular >> form. >> >> Mirja K=C3=BChlewind: This restricts what the transport protocol can cho= ose. >> >> Joe Hildebrand: Let=E2=80=99s not debate API details until we have the p= rinciples >> adequately characterized. Let=E2=80=99s know what the building blocks ar= e first. >> >> Aaron Falk: I agree that we should flesh out a couple of sections and us= e >> that as a basis for refining the rest of the document. Who will voluntee= r >> to take on one of these sections? >> >> ** Kevin Fall: Open mouth, insert work. I will do UDP. >> >> Mirja K=C3=BChlewind: Are there no MPTCP people here? >> >> Aaron Falk: What about basic TCP? >> >> ** Mirja K=C3=BChlewind: I will do basic TCP, but it would be good to ha= ve >> other people too. >> >> Varun Singh: Is RTP excluded? >> >> Mirja K=C3=BChlewind: Will you do that? >> >> ** Varun Singh: I=E2=80=99ll contribute text for RTP. >> >> Varun Singh: Is this document on GitHub? >> >> Mirja K=C3=BChlewind: Gorry Fairhurst and Brian Trammell can decide that= . >> >> Brian Trammell: I can move to markdown over GitHub, no problem. >> >> Kevin Fall: Are the lessons we learn here going to reflected in the >> previous document? >> >> Mirja K=C3=BChlewind: This document just lists what=E2=80=99s there. >> >> Kevin Fall: If we discover that idempotency is an important concept, how >> does that get added to the document? >> >> Joe Hildebrand: Finding those is the point of this exercise. >> >> Aaron Falk: We=E2=80=99ll give you a cookie. >> >> Varun Singh: It seems like we=E2=80=99re going to replicate a lot of tex= t from >> existing RFCs. >> >> Aaron Falk: The goal is to take an existing protocol and identify what >> services it is offering to the application. That=E2=80=99s what we want = to get in >> this document. >> >> Mirja K=C3=BChlewind: What you as an expert for some protocol should do = is >> describe the protocol as completely as possible. >> >> Dave Thaler: What are you looking for in each section? Service >> components? Protocol features? Both? >> >> Aaron Falk: I want the protocol components, but the way you get there is >> to analyze the protocol features. >> >> Mirja K=C3=BChlewind: Please provide text. >> >> ** Dave Thaler: I volunteer to help with getting the matrix right, of >> features vs. things that are protocols, e.g. inherent vs. optional is >> another key thing for features. I=E2=80=99ve done such work in the past.= It=E2=80=99s >> useful to know which things are inherent features, and which things are >> optional features. For example, with TCP you can have keepalives or not. >> >> Mirja K=C3=BChlewind: The first step is to describe the protocols. >> >> ** Dave Thaler: I=E2=80=99m volunteering to help with the matrix more th= an the >> specific text, but I may be able to do some of that too. >> >> Jana Iyengar: Let=E2=80=99s not end up with a giant matrix and checkboxe= s for >> various features. That=E2=80=99s not useful. >> >> Mirja K=C3=BChlewind: There may be cases where two components do not wor= k >> together. >> >> ** Karen Nielsen: I will provide SCTP text. >> >> Karen Nielsen: Protocol features like ACK or NACK are not specific to >> TCP. SCTP also has ACKs. You can=E2=80=99t say that protocol features ar= e specific >> to one protocol. >> >> Mirja K=C3=BChlewind: Protocol features are specific to one protocol. >> >> Karen Nielsen: So SCTP ACK is different to TCP ACK. >> >> ** P=C3=A5l-Erik Martinsen: I will provide text for STUN >> >> Charles Eckel: It will be helpful to combine everything into one table. >> >> Mirja K=C3=BChlewind: Having a single matrix would be really nice for th= e >> document. But the first step is to describe the protocols and extract t= he >> components they provide. >> >> Kenneth Calvert: Is one of the goals here to come out with an ontology o= f >> transport service components? >> >> Aaron Falk: We are trying to confine the scope to IETF protocols. A >> complete ontology would not necessarily be useful. >> >> Kenneth Calvert: For this draft, before you plunge into the matrix, it >> would be useful to define the existing components. >> >> Mirja K=C3=BChlewind: This is the end goal of the document. >> >> Brian (or Robert?) Adamson, NRL: Is there a template for a list of the >> aspects we care about? >> >> Mirja K=C3=BChlewind: This is just an initial attempt. >> >> Brian Trammell: To Kenneth, =E2=80=9Cyes=E2=80=9D (but I am allergic to = the word >> ontology.) >> >> Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2=80=99s the entir= e point >> of this working group. >> >> Michael Ramalho: This is a very hard problem when I think about how some >> of these protocols were evolved to meet very special needs. Suppose I ha= ve >> this application that doesn=E2=80=99t want head-of-line-blocking, and ma= ybe I don=E2=80=99t >> want to retransmit once or twice, and let=E2=80=99s suppose I have somet= hing >> expressive enough to convey this to the transport layer, and it can=E2= =80=99t >> deliver this without using multiple TCP connections, and maybe I would h= ave >> preferred DTLS. How do you express that to this layer? >> >> Mirja K=C3=BChlewind: The document is focussed on the simple cases first= . >> >> Pete Resnick: It would be a terrible failure if, in such situations, the >> transport layer would ask the application what to do. The app doesn=E2= =80=99t care >> and doesn=E2=80=99t know. That I can pull this off with 3 TCP connection= s is not >> something the app cares about. You either give the app what it asks for = or >> fail. >> >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94 >> >> ** 14:43 Aaron Falk called for adopting >> draft-fairhurst-taps-transports-00 as WG document. >> Folks who read the draft: maybe 10 + >> Significant hum in support >> None against >> >> -- END >> > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > --001a113363a474dae9050946352a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Aaron,

I read through the comments and = they're accurate AFAICT.

On Tue, Dec 2, 2014 at 2:45 PM, Aaron Falk <aaro= n.falk@gmail.com> wrote:
I've seen no comments.=C2=A0 It would be Really Nice if = at least one person could read the minutes before I submit them for the pro= ceedings. =C2=A0

--aaron

On Sat, N= ov 22, 2014 at 4:31 PM, Aaron Falk <aaron.falk@gmail.com>= wrote:
If you spoke up = in the Honolulu meeting, please review the minutes to confirm we captured y= our point.=C2=A0 Thanks to Stuart Cheshire & Michael Welzl for their de= tailed notes.

Thanks,

--aaron

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Transport Serv= ices (TAPS)
1300-1500 HST Tuesday Afternoon Session I
N= otes taken by Stuart Cheshire & Michael Welzl

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 AGENDA
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 0. Agenda bashing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1. Ch= arter Overview (Falk) - 10 min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= 2. Terminology Review (K=C3=BChlewind) - 30 min
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 3. Discussion of draft-fairhurst-taps-transports-00 (K= =C3=BChlewind) - 20 min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4. Hum= : Adopt draft-fairhurst-taps-transports-00 as wg document? - 10 min

Action items marked with **

=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94

13:05 Administrivia

Aaron Falk: Who was at the TAPS BoF in = Toronto? =C2=A0(Most people raised their hands.)

A= aron Falk: And who is on the mailing list? =C2=A0(About the same.)

Aaron Falk: In today=E2=80=99s meeting we=E2=80=99ll be ha= ving a discussion of terminology, and then a discussion of the working grou= p=E2=80=99s first draft. We will be looking for volunteers. The current dra= ft is an independent submission from two volunteers: Gorry Fairhurst and Br= ian Trammell, neither of whom could be here. We=E2=80=99ll be asking whethe= r the people in the room want to adopt this as a Working Group document.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

13:08 Char= ter Overview (Falk) =E2=80=93 10 min

Aaron Falk: T= he TAPS effort is focussing on the same area as the IAB Stack Evolution wor= k, which is that there have been 20 years of transport area improvements th= at are largely undeployed because (i) the new transports are not supported = in most operating systems, and (ii) the new transports may not work end-to-= end on today=E2=80=99s Internet. As a result, application developers often = build their own protocol on top of UDP, and sometimes that do that badly. T= he goal of this group is to enable application developers to get better per= formance and better behavior than they can get from TCP or UDP.
<= br>
The first task of the working group is to define what these b= ehaviors are that application developers want to get. We call these =E2=80= =9Ctransport services=E2=80=9D. Some examples are: Reliable delivery, in-or= der delivery, confidentiality, latency. It=E2=80=99s a way for applications= to express what they want from the transport layer, and to ask for combina= tions that aren=E2=80=99t currently available from TCP and UDP. The transpo= rt layer then sees what=E2=80=99s available and provides the best that it c= an, which might be HTTP over TCP.=C2=A0 To do this we=E2=80=99re first goin= g to examine existing IETF technologies to see what behaviors they provide,= to collect an initial set of behaviors that we think might be useful.=C2= =A0 We=E2=80=99re going to focus on communication between two endpoints, at= least initially.=C2=A0 That=E2=80=99s the first document, to submit to the= IESG next June.

Then there will be a second docum= ent which is a prioritization to select a subset of those services, and gui= dance how you might obtain those services using existing mechanisms. We wil= l submit this to the IESG next December.

The third= document describes how to do discovery of whether these things work, how t= o do fallback, how to combine the protocols and make them available. We wil= l submit this to the IESG in 2016.

We=E2=80=99re n= ot going to do signaling-based QoS. We=E2=80=99re not going to talk about n= ew encapsulations and tunneling. We=E2=80=99re not going to define, modify,= or extend transport protocols. We=E2=80=99re not going to define a languag= e-specific API.=C2=A0 We=E2=80=99re not going to do a detailed analysis of = security, but we will document the security properties of existing protocol= s. The emphasis of this work is not security.

Kevi= n Fall: Are API changes in scope? (e.g. changing sockets to allow data-with= -SYN, out-of-order delivery)

Aaron Falk: Yes
=

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94

13:15 Termino= logy Review (K=C3=BChlewind) =E2=80=93 30 min
<http://www.ietf.org/proceedings/91/slides/slides-91-taps-1.pdf>

(Mirja K=C3=BChlewind gave presentation of proposed= terminology)

Dave Thaler: Why not use term =E2=80= =9Cfacility=E2=80=9D instead of =E2=80=9Cservice component=E2=80=9D? The te= rm =E2=80=9Cservice component=E2=80=9D usually means a piece of code.
=

Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2= =80=9Cpart=E2=80=9D. That=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80= =9Cunit=E2=80=9D.

Michael Welzl: I like this a lot= .

Brian Trammell: I=E2=80=99m okay with this sugge= stion.

Kevin Fall: Standards Track RFC 2126 define= s the term =E2=80=9Ctransport services=E2=80=9D as referred to by ISO. Don= =E2=80=99t redefine terms that were already defined by an International Sta= ndard.

Mirja K=C3=BChlewind: Our definition is jus= t a little more specific.


Kevin Fal= l: Reliability is not a binary property. UDPLite has partial reliability.

Mirja K=C3=BChlewind: We discussed earlier whether = we need a concept smaller than a =E2=80=9Cservice component=E2=80=9D for di= fferent types of reliability. We call this an =E2=80=9Caspect=E2=80=9D.

Kevin Fall: That term has been reserved as well.

Joe Hildebrand: Just pick Swiss German words instead, = and we=E2=80=99ll all learn them. This way we have words that don=E2=80=99t= have existing meanings in existing networking standards.

Dave Thaler: And then we could try using non-US characters in RFCs.=

Mirja K=C3=BChlewind: I don=E2=80=99t care what w= e call it. We just have to agree on some terminology. Are those six descrip= tions the right concepts?

Ignacio Solis: Is =E2=80= =9Creliability=E2=80=9D an example of a =E2=80=9Cservice component=E2=80=9D= ?

Mirja K=C3=BChlewind: Right. A transport service= today provides you with a whole package of service components, not all of = which you may want. It also may not include a service component that you do= want.

Ignacio Solis: We=E2=80=99re being bound by= old thinking.

Kevin Fall: You asked what is missi= ng here. Is it connection-oriented? Is there connection establishment, noti= fication? Is there flow control? None of that is mentioned.

<= /div>
Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice compone= nts=E2=80=9D; a specific instantiation would be a =E2=80=9Cprotocol feature= =E2=80=9D.

Aaron Falk: The first two terms are thi= ngs that applications ask for. The other terms are how you provide those th= ings.

Brian Trammell: Kevin is describing =E2=80= =9Caspects=E2=80=9D. A =E2=80=9Cfeature=E2=80=9D is a thing that a protocol= does on purpose, an =E2=80=9Caspect=E2=80=9D is something that it does, wh= ether on purpose or not.

Gorry Fairhurst: =E2=80= =9CFeature=E2=80=9D is okay.

Ken Calvert: I would = call state establishment =E2=80=9Cmechanism=E2=80=9D I don=E2=80=99t know i= f this will ever converge. Don=E2=80=99t conflate wire encoding with logica= l implementation. =E2=80=9CMechanism=E2=80=9D is wire encoding + function. = Why are you not saying =E2=80=9Cfunction=E2=80=9D?

Mirja K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D and = =E2=80=9Cfunction=E2=80=9D are too abstract. What you described is still a = =E2=80=9Cfeature=E2=80=9D.

Ken Calvert: I suggest = not using =E2=80=9Creliability=E2=80=9D as an example because there are too= many different kinds of reliability.

Mirja K=C3= =BChlewind: Do you think we need a term for concepts with smaller granulari= ty than =E2=80=9Ccomponent=E2=80=9D?

Ken Calvert: = For that concept, use a Swiss German word.

Mirja K= =C3=BChlewind: Do we need one more term?

Ken Calve= rt: Maybe.

Andrew McGregor: The decomposition into= pieces looks good, but I think =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfe= ature=E2=80=9D should be swapped.

Mirja K=C3=BChle= wind: I got this feedback already.

Jana Iyengar: W= ell, you just got this feedback again. I agree with Andrew. We should switc= h =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. A software =E2= =80=9Ccomponent=E2=80=9D implements a =E2=80=9Cfeature=E2=80=9D.
=
Mirja K=C3=BChlewind: Switching the terms would help?
<= div>
(A bunch of =E2=80=9Cyes=E2=80=9D comments from the room= .)

Aaron Falk: That=E2=80=99s consensus. Move on.<= /div>

Edward Lopez: We should talk about segregating tra= nsport services from applications. Applications become independent of trans= port services. We should start thinking about the rise of transport service= gateways. If your application uses UDP and my application uses TCP then so= mething=E2=80=99s got to traverse. Is a gateway part of a potential termino= logy?

Mirja K=C3=BChlewind: I think that=E2=80=99s= out of scope. That would be a meddlebox.

Aaron Fa= lk: The use case we=E2=80=99re focussed on is two applications on two endpo= ints. You=E2=80=99re using =E2=80=9Capplication=E2=80=9D in a way that=E2= =80=99s confusing me.

Edward Lopez: If we=E2=80=99= re talking about transport services and potential independence from applica= tions, then when a common application is using different transport services= , what=E2=80=99s going to interchange? What=E2=80=99s going to aid that con= versation? That=E2=80=99s what=E2=80=99s not discussed here.

=
Aaron Falk: We have pushed that off. The third effort of the wor= king group to talk about an experiment with end-to-end compatibility.
=

Edward Lopez: Then we=E2=80=99d need transport service = negotiation. Separation of application from transport services leads me to = think there=E2=80=99s a term missing.

Mirja K=C3= =BChlewind: What we want is not that the application is requesting TCP. Wha= t we want is that the application is requesting a certain service compositi= on, and then the layer below can make the decision to use TCP.
Ronald in 't Velt: I have not heard the term =E2=80=9Celem= ent=E2=80=9D yet. I agree with Kevin Fall. Let=E2=80=99s see what=E2=80=99s= already there. I have a paper copy of ISO 8072 somewhere. I couldn=E2=80= =99t find it.

Mirja K=C3=BChlewind: I=E2=80=99m su= re every term has already been used somewhere.

Jan= a Iyengar: We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CThing 2= =E2=80=9D, =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing 4=E2=80=9D. Seriously,= how would I think about TCP over IPv6 over SSL over IPv4?

Mirja K=C3=BChlewind: That=E2=80=99s an instance. If you request t= hat service composition you get that stack.

Aaron = Falk: Jana, what is the application asking for?

Pe= te Resnick: The whole idea of how discovery takes place where both transpor= ts talk to each other and say this is the way we=E2=80=99re going to commun= icate for this particular instance is independent right now and we=E2=80=99= ll have to figure that out, but it=E2=80=99s not something an application c= ares about. We need to talk about feature discovery & negotiation. To a= ddress Ken=E2=80=99s comment, reliability and ordering should absolutely be= separate components.

Stuart Cheshire: I want to f= ollow up to Jana=E2=80=99s point. The choice about what features to use is = not decided only by the application. The choice of TCP vs UDP is decided by= the application, but the choice of Ethernet vs Wi-Fi (with or without VPN)= is decided by the user. Similarly, the choice of VPN or not may be decided= by the corporate administrator, not the application, or the user.

Aaron: The application needs to express hints about what i= t wants. You say there are other hints. Do we need to add something to our = taxonomy that allows that information to get in?

S= tuart: I don=E2=80=99t think it extends this taxonomy, it might be an ortho= gonal dimension. User has an input, administrator has an input, application= has an input. VPN is a classic example: application itself expresses no in= terest in security but the user does.

Andrew McGre= gor: You can imagine that the API is that the application asks for a set of= components, and the OS decides how to do that.

Ig= nacio Solis: We are PARC are building something that doesn=E2=80=99t use so= ckets. We have our own terminology. We call the transport layer the =E2=80= =9Cframework=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with =E2=80=9Ccomp= onents=E2=80=9D following the design of composable stacks. The management c= omponent is missing here, especially if we are considering how this relates= to middleboxes. =C2=A0

Mirja K=C3=BChlewind: It w= ould be nice if you could provide some references to this work on the list.=

Ignacio Solis: We have quite a number of things w= e=E2=80=99d be happy to share.

Mirja K=C3=BChlewin= d: You give the application a whole view of what=E2=80=99s available at the= transport layer. This work is to have an abstraction so the application do= esn=E2=80=99t need to know the details.

Ignacio So= lis: We completely agree. The API hides the details of stack assembly from = the application. But the application needs to be able to pick the entry com= ponent. The application needs to be able to pick the API it=E2=80=99s going= to use.

Dave Thaler: I agree with Stuart=E2=80=99= s points. I see a relationship between this and the MIF working group. The = MIF working group is doing similar things here concerning multiple provisio= ning domains. The application can express a set of preferences and get back= information about what was chosen.=C2=A0 When you think about the choice o= f saying which L3 protocol, they say =E2=80=9CI=E2=80=99d like to go across= a secure interface=E2=80=9D and MIF does the interface selection logic.

Aaron Falk: Are we re-using any MIF terms or concept= s?

Dave Thaler: I=E2=80=99m not aware of any any t= erminology collisions. Possibly we may be using different terms for the sam= e things. The MIF work is complementary.

Aaron Fal= k: Who in the room is active in the MIF working group?

=
(Dave Thaler plus one other.)

Aaron Falk: Thi= s whole conversation reminds me of DTN.

Kevin Fall= : With DTN we had to develop a pub/sub-style API. We also came to the concl= usion that a third party needs an API to establish a policy on those bindin= gs. In sockets there=E2=80=99s PF_* and AF_* to express some of these desir= es. But the application can also specify the precise protocols using IP_PRO= TO_*. It=E2=80=99s useful to take this choice that used to be wired in code= and expose it though an API to an agent. The unit of expressing things is = URIs.

Brian Trammell: So this problem has always b= een trying to match the crappy interface above the transport to the crappy = interface below. The terminology (and taps charter for that matter) assume = the lower interface can be ignored. =C2=A0 Although that might be impossibl= e from a terminology standpoint. =C2=A0 I think we probably don't want = to define a term for the controller... but we might want to have a way to d= escribe the things that the controller knows about the lower-interface tran= sport aspects and path aspects.

Mirja K=C3=BChlewi= nd: The goal for right now is to set up an initial terminology for us to us= e.

Szilveszter: Don=E2=80=99t we have to define ho= w to choose a protocol? Is it in TAPS scope to say how we compose a transpo= rt? Isn=E2=80=99t it just an interface towards a transport?

<= /div>
Aaron Falk: That is a question about the working group=E2=80=99s = scope. The second document is to pick a subset of all the things an applica= tion could ask for. Right now we=E2=80=99re trying to figure out what those= behaviors are.

Toerless Eckert: Not all of the co= mponents here are things that we would traditionally call =E2=80=9Ctranspor= t=E2=80=9D. Some of the components are in INT area.=C2=A0 E.g. what about n= ame resolution?

Mirja K=C3=BChlewind: I believe na= me resolution is not a component. It=E2=80=99s a service. This is just a fi= rst step. We can still change the terms.

Andrew Mc= Gregor: We want diagnostic tools (ping, traceroute, etc.) to be using the s= ame APIs as applications.

Mirja K=C3=BChlewind: Le= t=E2=80=99s do the first step first.

Andrew McGreg= or: Yes, but diagnostic tools require the ability to specify an exact stack= in order to be able to generate the right sort of packet.

Aaron Falk: That=E2=80=99s pretty clearly out of scope for the gro= up. The goal here is to make things easier for application developers.

Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an applicat= ion?

Mirja K=C3=BChlewind: This should be hidden f= rom the application.

Andrew McGregor: The =E2=80= =9Cping=E2=80=9D program is an application?

Aaron = Falk: No, it=E2=80=99s a utility, which is why it=E2=80=99s out of scope.

Michael Welzl: I remember from the BoF there was co= nsensus that we should have some kind of determinism to flag to provide rep= eatability for testing.

Jana Iyengar: What Andrew = is suggesting would be good. We need better tools. Without deterministic un= ique composition, how can you have interoperability?

Mirja K=C3=BChlewind: For interoperability we come up with a new shim la= yer. This is what we want to hide from the application.

Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot= of layer violations. This working group has =E2=80=9Ctransport=E2=80=9D in= the name. Ping uses ICMP. ICMP is not in the transport layer. To Jana=E2= =80=99s point, there=E2=80=99s going to have to be some sort of rendezvous/= discovery. Once an application requests a certain set of components, how th= e system establishes talking to the other side is just something for the lo= wer layers to implement.

Joe Hildebrand: Let=E2=80= =99s agree what the components are before we debate how they=E2=80=99re neg= otiated.

Andrew McGregor: Ping was a bad example. = There=E2=80=99s a python library called =E2=80=9Cscapy=E2=80=9D that lets y= ou specify a bunch of properties and leave the rest unspecified and it will= try and make it work. From incomplete information it fills in the gaps to = make something sensible. This is a practical example of something that=E2= =80=99s already out there.

Brian Trammell: The fac= toring of this terminology, if not the words, support _everything_ we'r= e talking about here. you can ask for a component, you can ask for a compos= ition, you can ask for a protocol instance. What it doesn't support des= cribing yet is getting info up from the lower layer.

Kevin Fall: Identification of the endpoint gives me some concern. TCP ha= s concepts like ports. Semantics are associated with that. The style of nam= ing is relevant.

Mirja K=C3=BChlewind: You could h= ave a component =E2=80=9CI want to transmit web traffic=E2=80=9D and then n= aturally the first thing the transport protocol would do is open a connecti= on on port 80. If that doesn=E2=80=99t work it could do something else.

Kevin Fall: That=E2=80=99s high level example compare= d to components like =E2=80=9Creliability=E2=80=9D.

Mirja K=C3=BChlewind: This is not for sure. This is the next step. We hav= e to find out what=E2=80=99s out there and how we name these things.
<= div>
Kevin Fall: If these high level examples are what you=E2= =80=99re talking about then high level frameworks well above the sockets la= yer are relevant.

Mirja K=C3=BChlewind: I just don= =E2=80=99t know.

Mirja K=C3=BChlewind: My conclusi= ons from discussion: =C2=A0We=E2=80=99ll switch the terms =E2=80=9Ccomponen= t=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. This is a good starting point. We= can have more discussions and change things if necessary. We need a term l= ike =E2=80=9Caspect=E2=80=9D which is even a lower granularity than =E2=80= =9Ccomponent=E2=80=9D.

=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
<= br>
14:07 Discussion of draft-fairhurst-taps-transports-00=C2=A0<= /div>

Authors Gorry Fairhurs= t and Brian Trammell. Presented by Mirja K=C3=BChlewind.

Goal is to survey existing transport protocols and extract the commo= n components they have, and the ways they implement those.

Slide 4: Relationship between transport protocols and service comp= onent

Joe Hildebrand: There are other IETF areas w= ho should be included (like RAI) that are not in the transport area but off= er transport-like facilities. For example websocket.

Mirja K=C3=BChlewind: As long as they are IETF protocols they are in sco= pe.

Dave Thaler: I strongly agree with Joe. Now we= =E2=80=99re talking about architecture, how protocols map to services. I wa= nt to go back to what Stuart said about the multiple parties making the var= ious requests. For example, it is not (usually) the application deciding th= at the link-layer should be Ethernet. We need to avoid the case where the a= pplications at each end request the same service components but get differe= nt protocols and therefore have not interoperability. What that means is th= at the mapping from service components to protocol stacks needs to be deter= ministic on both ends.

Mirja K=C3=BChlewind: There= should be some kind of shim layer that does some kind of negotiation to ma= ke sure they can communicate.

Dave Thaler: Okay, b= ut the draft does not say that.

Michael Welzl: Thi= s table may look like it proposes a mapping, but it=E2=80=99s just listing = the protocols that currently exist.

Jana Iyengar: = Are we explicitly excluding non-IETF protocols?

Aa= ron Falk: Yes, for this work item. We might expand the scope later.

Kevin Fall: In this matrix UDP is defined as unicast, whi= ch surprises me considering that all multicast work uses UDP. How does mult= icast fit into this?

Andrew McGregor: Are CoAP, SP= DY, HTTP/2 included? CoAP has multicast RESTful verbs. CoAP also has conges= tion control, so it=E2=80=99s a transport protocol.

Mirja K=C3=BChlewind: Right now we want to cover all the obvious transpor= t protocols. If people want to contribute text for others, we can add those= .

Aaron Falk: Andrew, is this an area you have exp= ertise in?

Andrew McGregor: Some.

** Aaron Falk: Andrew McGregor will identify a contributor to desc= ribe CoAP (maybe himself).

Brian (or Robert?) Adam= son, NRL: We should solicit additions via the mailing list.

<= /div>
Aaron Falk: Please send text.

Joe Hildeb= rand: You asked the question: Is this a viable structure? My answer is: I t= hink so. But we should start with a detailed analysis of something like TCP= to make sure we understand how that fits the model.

Aaron Falk: I=E2=80=99d suggest exploring two examples so that we have t= wo data points. Michael already volunteered to do SCTP.

Slide 5: Who can contribute?

Dave Thaler: I= =E2=80=99m thinking of a type of protocol that=E2=80=99s missing from the l= ist, and that=E2=80=99s things like TLS. Applications ask for stuff. Protoc= ols provide stuff. Applications ask for stuff like confidentiality, integri= ty, etc. Protocols like TLS and IPSEC provide confidentiality, integrity, e= tc.

Mirja K=C3=BChlewind: Please contribute text.<= /div>

Dave Thaler: We think in terms of layers, but secu= rity is not a layer. It=E2=80=99s on the side, affecting everything. We nee= d to include the things on the side too.

Brian Tra= mmell: Security is definitely an aspect

Gorry Fair= hurst: +1

Mirja K=C3=BChlewind: =E2=80=9CAspect=E2= =80=9D or =E2=80=9CComponent=E2=80=9D?

Gorry Fairh= urst: What we want is a plan to make one of these sections concrete from so= meone with expertise in the protocol.

Mirja K=C3= =BChlewind: Yes.

Brian Trammell: We're asking = the structure question here.

Andrew McGregor: The = structure is ugly but I can=E2=80=99t see how it could be better. We have t= o consider how you name the other endpoint. DNS name? URL? Something else? = Should that identity be proved in some manner? How? TLS certificates? HIP i= dentity hash match.

Mirja K=C3=BChlewind: I don=E2= =80=99t need to specify how identity is proved.

An= drew McGregor: You might if you only have credentials in a particular form.=

Mirja K=C3=BChlewind: This restricts what the tra= nsport protocol can choose.

Joe Hildebrand: Let=E2= =80=99s not debate API details until we have the principles adequately char= acterized. Let=E2=80=99s know what the building blocks are first.

Aaron Falk: I agree that we should flesh out a couple of se= ctions and use that as a basis for refining the rest of the document. Who w= ill volunteer to take on one of these sections?

**= Kevin Fall: Open mouth, insert work. I will do UDP.

Mirja K=C3=BChlewind: Are there no MPTCP people here?

Aaron Falk: What about basic TCP?

** Mirja = K=C3=BChlewind: I will do basic TCP, but it would be good to have other peo= ple too.

Varun Singh: Is RTP excluded?
<= br>
Mirja K=C3=BChlewind: Will you do that?

<= div>** Varun Singh: I=E2=80=99ll contribute text for RTP.

Varun Singh: Is this document on GitHub?

M= irja K=C3=BChlewind: Gorry Fairhurst and Brian Trammell can decide that.

Brian Trammell: I can move to markdown over GitHub, = no problem.

Kevin Fall: Are the lessons we learn h= ere going to reflected in the previous document?

M= irja K=C3=BChlewind: This document just lists what=E2=80=99s there.

Kevin Fall: If we discover that idempotency is an importa= nt concept, how does that get added to the document?

Joe Hildebrand: Finding those is the point of this exercise.
<= br>
Aaron Falk: We=E2=80=99ll give you a cookie.

Varun Singh: It seems like we=E2=80=99re going to replicate a lot = of text from existing RFCs.

Aaron Falk: The goal i= s to take an existing protocol and identify what services it is offering to= the application. That=E2=80=99s what we want to get in this document.

Mirja K=C3=BChlewind: What you as an expert for some p= rotocol should do is describe the protocol as completely as possible.
=

Dave Thaler: What are you looking for in each section? = Service components? Protocol features? Both?

Aaron= Falk: I want the protocol components, but the way you get there is to anal= yze the protocol features.

Mirja K=C3=BChlewind: P= lease provide text.

** Dave Thaler: I volunteer to= help with getting the matrix right, of features vs. things that are protoc= ols, e.g. inherent vs. optional is another key thing for features. I=E2=80= =99ve done such work in the past. It=E2=80=99s useful to know which things = are inherent features, and which things are optional features. For example,= with TCP you can have keepalives or not.

Mirja K= =C3=BChlewind: The first step is to describe the protocols.

<= /div>
** Dave Thaler: I=E2=80=99m volunteering to help with the matrix = more than the specific text, but I may be able to do some of that too.

Jana Iyengar: Let=E2=80=99s not end up with a giant ma= trix and checkboxes for various features. That=E2=80=99s not useful.
<= div>
Mirja K=C3=BChlewind: There may be cases where two compo= nents do not work together.

** Karen Nielsen: I wi= ll provide SCTP text.

Karen Nielsen: Protocol feat= ures like ACK or NACK are not specific to TCP. SCTP also has ACKs. You can= =E2=80=99t say that protocol features are specific to one protocol.

Mirja K=C3=BChlewind: Protocol features are specific to o= ne protocol.

Karen Nielsen: So SCTP ACK is differe= nt to TCP ACK.

** P=C3=A5l-Erik Martinsen: I will = provide text for STUN

Charles Eckel: It will be he= lpful to combine everything into one table.

Mirja = K=C3=BChlewind: Having a single matrix would be really nice for the documen= t.=C2=A0 But the first step is to describe the protocols and extract the co= mponents they provide.

Kenneth Calvert: Is one of = the goals here to come out with an ontology of transport service components= ?

Aaron Falk: We are trying to confine the scope t= o IETF protocols. A complete ontology would not necessarily be useful.

Kenneth Calvert: For this draft, before you plunge int= o the matrix, it would be useful to define the existing components.

Mirja K=C3=BChlewind: This is the end goal of the documen= t.

Brian (or Robert?) Adamson, NRL: Is there a tem= plate for a list of the aspects we care about?

Mir= ja K=C3=BChlewind: This is just an initial attempt.

Brian Trammell: To Kenneth, =E2=80=9Cyes=E2=80=9D (but I am allergic to t= he word ontology.)

Gorry Fairhurst: To Brian (or R= obert?) Adamson: That=E2=80=99s the entire point of this working group.

Michael Ramalho: This is a very hard problem when I t= hink about how some of these protocols were evolved to meet very special ne= eds. Suppose I have this application that doesn=E2=80=99t want head-of-line= -blocking, and maybe I don=E2=80=99t want to retransmit once or twice, and = let=E2=80=99s suppose I have something expressive enough to convey this to = the transport layer, and it can=E2=80=99t deliver this without using multip= le TCP connections, and maybe I would have preferred DTLS. How do you expre= ss that to this layer?

Mirja K=C3=BChlewind: The d= ocument is focussed on the simple cases first.

Pet= e Resnick: It would be a terrible failure if, in such situations, the trans= port layer would ask the application what to do. The app doesn=E2=80=99t ca= re and doesn=E2=80=99t know. That I can pull this off with 3 TCP connection= s is not something the app cares about. You either give the app what it ask= s for or fail.

=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94

** 14:43 Aaron Falk called for adopting draft-fairhurst-taps-transp= orts-00 as WG document.
Folks who read the draft: maybe 10 +
Significant hum in support
None against

-- END


_______________________________________________
Taps mailing list
Taps@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/taps


--001a113363a474dae9050946352a-- From nobody Wed Dec 3 02:20:48 2014 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 718691A1A12 for ; Wed, 3 Dec 2014 02:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 z2Jtb1WdZ_jF for ; Wed, 3 Dec 2014 02:20:38 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 405B81A016A for ; Wed, 3 Dec 2014 02:20:37 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::108d] (unknown [IPv6:2001:67c:10ec:2a49:8000::108d]) by trammell.ch (Postfix) with ESMTPSA id 0890F1A0464; Wed, 3 Dec 2014 11:20:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: Date: Wed, 3 Dec 2014 11:20:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8F9B541C-4BD3-4CEA-A53D-564850C6A876@trammell.ch> References: To: Aaron Falk X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/toaMfOC-tUE_2oS1kcJjlBxVweI Cc: Jana Iyengar , "taps@ietf.org" Subject: Re: [Taps] draft minutes from IETF-91 meeting 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, 03 Dec 2014 10:20:44 -0000 hi Aaron all, The minutes capture the discussion well, to my recollection (though I = haven't reviewed against the audio). Cheers, Brian > On 03 Dec 2014, at 03:00, Jana Iyengar wrote: >=20 > Aaron, >=20 > I read through the comments and they're accurate AFAICT. >=20 > On Tue, Dec 2, 2014 at 2:45 PM, Aaron Falk = wrote: > I've seen no comments. It would be Really Nice if at least one person = could read the minutes before I submit them for the proceedings. =20 >=20 > --aaron >=20 > On Sat, Nov 22, 2014 at 4:31 PM, Aaron Falk = wrote: > If you spoke up in the Honolulu meeting, please review the minutes to = confirm we captured your point. Thanks to Stuart Cheshire & Michael = Welzl for their detailed notes. >=20 > Thanks, >=20 > --aaron >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > Transport Services (TAPS) > 1300-1500 HST Tuesday Afternoon Session I > Notes taken by Stuart Cheshire & Michael Welzl >=20 > AGENDA > =3D=3D=3D=3D=3D=3D=3D > 0. Agenda bashing > 1. Charter Overview (Falk) - 10 min > 2. Terminology Review (K=C3=BChlewind) - 30 min > 3. Discussion of draft-fairhurst-taps-transports-00 = (K=C3=BChlewind) - 20 min > 4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg = document? - 10 min >=20 > Action items marked with ** >=20 > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 >=20 > 13:05 Administrivia > >=20 > Aaron Falk: Who was at the TAPS BoF in Toronto? (Most people raised = their hands.) >=20 > Aaron Falk: And who is on the mailing list? (About the same.) >=20 > Aaron Falk: In today=E2=80=99s meeting we=E2=80=99ll be having a = discussion of terminology, and then a discussion of the working = group=E2=80=99s first draft. We will be looking for volunteers. The = current draft is an independent submission from two volunteers: Gorry = Fairhurst and Brian Trammell, neither of whom could be here. We=E2=80=99ll= be asking whether the people in the room want to adopt this as a = Working Group document. >=20 > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 >=20 > 13:08 Charter Overview (Falk) =E2=80=93 10 min >=20 > Aaron Falk: The TAPS effort is focussing on the same area as the IAB = Stack Evolution work, which is that there have been 20 years of = transport area improvements that are largely undeployed because (i) the = new transports are not supported in most operating systems, and (ii) the = new transports may not work end-to-end on today=E2=80=99s Internet. As a = result, application developers often build their own protocol on top of = UDP, and sometimes that do that badly. The goal of this group is to = enable application developers to get better performance and better = behavior than they can get from TCP or UDP. >=20 > The first task of the working group is to define what these behaviors = are that application developers want to get. We call these =E2=80=9Ctransp= ort services=E2=80=9D. Some examples are: Reliable delivery, in-order = delivery, confidentiality, latency. It=E2=80=99s a way for applications = to express what they want from the transport layer, and to ask for = combinations that aren=E2=80=99t currently available from TCP and UDP. = The transport layer then sees what=E2=80=99s available and provides the = best that it can, which might be HTTP over TCP. To do this we=E2=80=99re = first going to examine existing IETF technologies to see what behaviors = they provide, to collect an initial set of behaviors that we think might = be useful. We=E2=80=99re going to focus on communication between two = endpoints, at least initially. That=E2=80=99s the first document, to = submit to the IESG next June. >=20 > Then there will be a second document which is a prioritization to = select a subset of those services, and guidance how you might obtain = those services using existing mechanisms. We will submit this to the = IESG next December. >=20 > The third document describes how to do discovery of whether these = things work, how to do fallback, how to combine the protocols and make = them available. We will submit this to the IESG in 2016. >=20 > We=E2=80=99re not going to do signaling-based QoS. We=E2=80=99re not = going to talk about new encapsulations and tunneling. We=E2=80=99re not = going to define, modify, or extend transport protocols. We=E2=80=99re = not going to define a language-specific API. We=E2=80=99re not going to = do a detailed analysis of security, but we will document the security = properties of existing protocols. The emphasis of this work is not = security. >=20 > Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow = data-with-SYN, out-of-order delivery) >=20 > Aaron Falk: Yes >=20 > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 >=20 > 13:15 Terminology Review (K=C3=BChlewind) =E2=80=93 30 min > >=20 > (Mirja K=C3=BChlewind gave presentation of proposed terminology) >=20 > Dave Thaler: Why not use term =E2=80=9Cfacility=E2=80=9D instead of = =E2=80=9Cservice component=E2=80=9D? The term =E2=80=9Cservice = component=E2=80=9D usually means a piece of code. >=20 > Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80=9Cpart=E2=80=9D= . That=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9Cunit=E2=80=9D. >=20 > Michael Welzl: I like this a lot. >=20 > Brian Trammell: I=E2=80=99m okay with this suggestion. >=20 > Kevin Fall: Standards Track RFC 2126 defines the term =E2=80=9Ctransport= services=E2=80=9D as referred to by ISO. Don=E2=80=99t redefine terms = that were already defined by an International Standard. >=20 > Mirja K=C3=BChlewind: Our definition is just a little more specific. >=20 >=20 > Kevin Fall: Reliability is not a binary property. UDPLite has partial = reliability. >=20 > Mirja K=C3=BChlewind: We discussed earlier whether we need a concept = smaller than a =E2=80=9Cservice component=E2=80=9D for different types = of reliability. We call this an =E2=80=9Caspect=E2=80=9D. >=20 > Kevin Fall: That term has been reserved as well. >=20 > Joe Hildebrand: Just pick Swiss German words instead, and we=E2=80=99ll = all learn them. This way we have words that don=E2=80=99t have existing = meanings in existing networking standards. >=20 > Dave Thaler: And then we could try using non-US characters in RFCs. >=20 > Mirja K=C3=BChlewind: I don=E2=80=99t care what we call it. We just = have to agree on some terminology. Are those six descriptions the right = concepts? >=20 > Ignacio Solis: Is =E2=80=9Creliability=E2=80=9D an example of a = =E2=80=9Cservice component=E2=80=9D? >=20 > Mirja K=C3=BChlewind: Right. A transport service today provides you = with a whole package of service components, not all of which you may = want. It also may not include a service component that you do want. >=20 > Ignacio Solis: We=E2=80=99re being bound by old thinking. >=20 > Kevin Fall: You asked what is missing here. Is it connection-oriented? = Is there connection establishment, notification? Is there flow control? = None of that is mentioned. >=20 > Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice = components=E2=80=9D; a specific instantiation would be a =E2=80=9Cprotocol= feature=E2=80=9D. >=20 > Aaron Falk: The first two terms are things that applications ask for. = The other terms are how you provide those things. >=20 > Brian Trammell: Kevin is describing =E2=80=9Caspects=E2=80=9D. A = =E2=80=9Cfeature=E2=80=9D is a thing that a protocol does on purpose, an = =E2=80=9Caspect=E2=80=9D is something that it does, whether on purpose = or not. >=20 > Gorry Fairhurst: =E2=80=9CFeature=E2=80=9D is okay. >=20 > Ken Calvert: I would call state establishment =E2=80=9Cmechanism=E2=80=9D= I don=E2=80=99t know if this will ever converge. Don=E2=80=99t conflate = wire encoding with logical implementation. =E2=80=9CMechanism=E2=80=9D = is wire encoding + function. Why are you not saying =E2=80=9Cfunction=E2=80= =9D? >=20 > Mirja K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D = and =E2=80=9Cfunction=E2=80=9D are too abstract. What you described is = still a =E2=80=9Cfeature=E2=80=9D. >=20 > Ken Calvert: I suggest not using =E2=80=9Creliability=E2=80=9D as an = example because there are too many different kinds of reliability. >=20 > Mirja K=C3=BChlewind: Do you think we need a term for concepts with = smaller granularity than =E2=80=9Ccomponent=E2=80=9D? >=20 > Ken Calvert: For that concept, use a Swiss German word. >=20 > Mirja K=C3=BChlewind: Do we need one more term? >=20 > Ken Calvert: Maybe. >=20 > Andrew McGregor: The decomposition into pieces looks good, but I think = =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D should be = swapped. >=20 > Mirja K=C3=BChlewind: I got this feedback already. >=20 > Jana Iyengar: Well, you just got this feedback again. I agree with = Andrew. We should switch =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2= =80=9D. A software =E2=80=9Ccomponent=E2=80=9D implements a = =E2=80=9Cfeature=E2=80=9D. >=20 > Mirja K=C3=BChlewind: Switching the terms would help? >=20 > (A bunch of =E2=80=9Cyes=E2=80=9D comments from the room.) >=20 > Aaron Falk: That=E2=80=99s consensus. Move on. >=20 > Edward Lopez: We should talk about segregating transport services from = applications. Applications become independent of transport services. We = should start thinking about the rise of transport service gateways. If = your application uses UDP and my application uses TCP then something=E2=80= =99s got to traverse. Is a gateway part of a potential terminology? >=20 > Mirja K=C3=BChlewind: I think that=E2=80=99s out of scope. That would = be a meddlebox. >=20 > Aaron Falk: The use case we=E2=80=99re focussed on is two applications = on two endpoints. You=E2=80=99re using =E2=80=9Capplication=E2=80=9D in = a way that=E2=80=99s confusing me. >=20 > Edward Lopez: If we=E2=80=99re talking about transport services and = potential independence from applications, then when a common application = is using different transport services, what=E2=80=99s going to = interchange? What=E2=80=99s going to aid that conversation? That=E2=80=99s= what=E2=80=99s not discussed here. >=20 > Aaron Falk: We have pushed that off. The third effort of the working = group to talk about an experiment with end-to-end compatibility. >=20 > Edward Lopez: Then we=E2=80=99d need transport service negotiation. = Separation of application from transport services leads me to think = there=E2=80=99s a term missing. >=20 > Mirja K=C3=BChlewind: What we want is not that the application is = requesting TCP. What we want is that the application is requesting a = certain service composition, and then the layer below can make the = decision to use TCP. >=20 > Ronald in 't Velt: I have not heard the term =E2=80=9Celement=E2=80=9D = yet. I agree with Kevin Fall. Let=E2=80=99s see what=E2=80=99s already = there. I have a paper copy of ISO 8072 somewhere. I couldn=E2=80=99t = find it. >=20 > Mirja K=C3=BChlewind: I=E2=80=99m sure every term has already been = used somewhere. >=20 > Jana Iyengar: We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CTh= ing 2=E2=80=9D, =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing 4=E2=80=9D. = Seriously, how would I think about TCP over IPv6 over SSL over IPv4? >=20 > Mirja K=C3=BChlewind: That=E2=80=99s an instance. If you request that = service composition you get that stack. >=20 > Aaron Falk: Jana, what is the application asking for? >=20 > Pete Resnick: The whole idea of how discovery takes place where both = transports talk to each other and say this is the way we=E2=80=99re = going to communicate for this particular instance is independent right = now and we=E2=80=99ll have to figure that out, but it=E2=80=99s not = something an application cares about. We need to talk about feature = discovery & negotiation. To address Ken=E2=80=99s comment, reliability = and ordering should absolutely be separate components. >=20 > Stuart Cheshire: I want to follow up to Jana=E2=80=99s point. The = choice about what features to use is not decided only by the = application. The choice of TCP vs UDP is decided by the application, but = the choice of Ethernet vs Wi-Fi (with or without VPN) is decided by the = user. Similarly, the choice of VPN or not may be decided by the = corporate administrator, not the application, or the user. >=20 > Aaron: The application needs to express hints about what it wants. You = say there are other hints. Do we need to add something to our taxonomy = that allows that information to get in? >=20 > Stuart: I don=E2=80=99t think it extends this taxonomy, it might be an = orthogonal dimension. User has an input, administrator has an input, = application has an input. VPN is a classic example: application itself = expresses no interest in security but the user does. >=20 > Andrew McGregor: You can imagine that the API is that the application = asks for a set of components, and the OS decides how to do that. >=20 > Ignacio Solis: We are PARC are building something that doesn=E2=80=99t = use sockets. We have our own terminology. We call the transport layer = the =E2=80=9Cframework=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with = =E2=80=9Ccomponents=E2=80=9D following the design of composable stacks. = The management component is missing here, especially if we are = considering how this relates to middleboxes. =20 >=20 > Mirja K=C3=BChlewind: It would be nice if you could provide some = references to this work on the list. >=20 > Ignacio Solis: We have quite a number of things we=E2=80=99d be happy = to share. >=20 > Mirja K=C3=BChlewind: You give the application a whole view of = what=E2=80=99s available at the transport layer. This work is to have an = abstraction so the application doesn=E2=80=99t need to know the details. >=20 > Ignacio Solis: We completely agree. The API hides the details of stack = assembly from the application. But the application needs to be able to = pick the entry component. The application needs to be able to pick the = API it=E2=80=99s going to use. >=20 > Dave Thaler: I agree with Stuart=E2=80=99s points. I see a = relationship between this and the MIF working group. The MIF working = group is doing similar things here concerning multiple provisioning = domains. The application can express a set of preferences and get back = information about what was chosen. When you think about the choice of = saying which L3 protocol, they say =E2=80=9CI=E2=80=99d like to go = across a secure interface=E2=80=9D and MIF does the interface selection = logic. >=20 > Aaron Falk: Are we re-using any MIF terms or concepts? >=20 > Dave Thaler: I=E2=80=99m not aware of any any terminology collisions. = Possibly we may be using different terms for the same things. The MIF = work is complementary. >=20 > Aaron Falk: Who in the room is active in the MIF working group? >=20 > (Dave Thaler plus one other.) >=20 > Aaron Falk: This whole conversation reminds me of DTN. >=20 > Kevin Fall: With DTN we had to develop a pub/sub-style API. We also = came to the conclusion that a third party needs an API to establish a = policy on those bindings. In sockets there=E2=80=99s PF_* and AF_* to = express some of these desires. But the application can also specify the = precise protocols using IP_PROTO_*. It=E2=80=99s useful to take this = choice that used to be wired in code and expose it though an API to an = agent. The unit of expressing things is URIs. >=20 > Brian Trammell: So this problem has always been trying to match the = crappy interface above the transport to the crappy interface below. The = terminology (and taps charter for that matter) assume the lower = interface can be ignored. Although that might be impossible from a = terminology standpoint. I think we probably don't want to define a = term for the controller... but we might want to have a way to describe = the things that the controller knows about the lower-interface transport = aspects and path aspects. >=20 > Mirja K=C3=BChlewind: The goal for right now is to set up an initial = terminology for us to use. >=20 > Szilveszter: Don=E2=80=99t we have to define how to choose a protocol? = Is it in TAPS scope to say how we compose a transport? Isn=E2=80=99t it = just an interface towards a transport? >=20 > Aaron Falk: That is a question about the working group=E2=80=99s = scope. The second document is to pick a subset of all the things an = application could ask for. Right now we=E2=80=99re trying to figure out = what those behaviors are. >=20 > Toerless Eckert: Not all of the components here are things that we = would traditionally call =E2=80=9Ctransport=E2=80=9D. Some of the = components are in INT area. E.g. what about name resolution? >=20 > Mirja K=C3=BChlewind: I believe name resolution is not a component. = It=E2=80=99s a service. This is just a first step. We can still change = the terms. >=20 > Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to = be using the same APIs as applications. >=20 > Mirja K=C3=BChlewind: Let=E2=80=99s do the first step first. >=20 > Andrew McGregor: Yes, but diagnostic tools require the ability to = specify an exact stack in order to be able to generate the right sort of = packet. >=20 > Aaron Falk: That=E2=80=99s pretty clearly out of scope for the group. = The goal here is to make things easier for application developers. >=20 > Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an application? >=20 > Mirja K=C3=BChlewind: This should be hidden from the application. >=20 > Andrew McGregor: The =E2=80=9Cping=E2=80=9D program is an application? >=20 > Aaron Falk: No, it=E2=80=99s a utility, which is why it=E2=80=99s out = of scope. >=20 > Michael Welzl: I remember from the BoF there was consensus that we = should have some kind of determinism to flag to provide repeatability = for testing. >=20 > Jana Iyengar: What Andrew is suggesting would be good. We need better = tools. Without deterministic unique composition, how can you have = interoperability? >=20 > Mirja K=C3=BChlewind: For interoperability we come up with a new shim = layer. This is what we want to hide from the application. >=20 > Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot = of layer violations. This working group has =E2=80=9Ctransport=E2=80=9D = in the name. Ping uses ICMP. ICMP is not in the transport layer. To = Jana=E2=80=99s point, there=E2=80=99s going to have to be some sort of = rendezvous/discovery. Once an application requests a certain set of = components, how the system establishes talking to the other side is just = something for the lower layers to implement. >=20 > Joe Hildebrand: Let=E2=80=99s agree what the components are before we = debate how they=E2=80=99re negotiated. >=20 > Andrew McGregor: Ping was a bad example. There=E2=80=99s a python = library called =E2=80=9Cscapy=E2=80=9D that lets you specify a bunch of = properties and leave the rest unspecified and it will try and make it = work. =46rom incomplete information it fills in the gaps to make = something sensible. This is a practical example of something that=E2=80=99= s already out there. >=20 > Brian Trammell: The factoring of this terminology, if not the words, = support _everything_ we're talking about here. you can ask for a = component, you can ask for a composition, you can ask for a protocol = instance. What it doesn't support describing yet is getting info up from = the lower layer. >=20 > Kevin Fall: Identification of the endpoint gives me some concern. TCP = has concepts like ports. Semantics are associated with that. The style = of naming is relevant. >=20 > Mirja K=C3=BChlewind: You could have a component =E2=80=9CI want to = transmit web traffic=E2=80=9D and then naturally the first thing the = transport protocol would do is open a connection on port 80. If that = doesn=E2=80=99t work it could do something else. >=20 > Kevin Fall: That=E2=80=99s high level example compared to components = like =E2=80=9Creliability=E2=80=9D. >=20 > Mirja K=C3=BChlewind: This is not for sure. This is the next step. We = have to find out what=E2=80=99s out there and how we name these things. >=20 > Kevin Fall: If these high level examples are what you=E2=80=99re = talking about then high level frameworks well above the sockets layer = are relevant. >=20 > Mirja K=C3=BChlewind: I just don=E2=80=99t know. >=20 > Mirja K=C3=BChlewind: My conclusions from discussion: We=E2=80=99ll = switch the terms =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D= . This is a good starting point. We can have more discussions and change = things if necessary. We need a term like =E2=80=9Caspect=E2=80=9D which = is even a lower granularity than =E2=80=9Ccomponent=E2=80=9D. >=20 > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 >=20 > 14:07 Discussion of draft-fairhurst-taps-transports-00=20 > >=20 > Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja = K=C3=BChlewind. >=20 > Goal is to survey existing transport protocols and extract the common = components they have, and the ways they implement those. >=20 > Slide 4: Relationship between transport protocols and service = component >=20 > Joe Hildebrand: There are other IETF areas who should be included = (like RAI) that are not in the transport area but offer transport-like = facilities. For example websocket. >=20 > Mirja K=C3=BChlewind: As long as they are IETF protocols they are in = scope. >=20 > Dave Thaler: I strongly agree with Joe. Now we=E2=80=99re talking = about architecture, how protocols map to services. I want to go back to = what Stuart said about the multiple parties making the various requests. = For example, it is not (usually) the application deciding that the = link-layer should be Ethernet. We need to avoid the case where the = applications at each end request the same service components but get = different protocols and therefore have not interoperability. What that = means is that the mapping from service components to protocol stacks = needs to be deterministic on both ends. >=20 > Mirja K=C3=BChlewind: There should be some kind of shim layer that = does some kind of negotiation to make sure they can communicate. >=20 > Dave Thaler: Okay, but the draft does not say that. >=20 > Michael Welzl: This table may look like it proposes a mapping, but = it=E2=80=99s just listing the protocols that currently exist. >=20 > Jana Iyengar: Are we explicitly excluding non-IETF protocols? >=20 > Aaron Falk: Yes, for this work item. We might expand the scope later. >=20 > Kevin Fall: In this matrix UDP is defined as unicast, which surprises = me considering that all multicast work uses UDP. How does multicast fit = into this? >=20 > Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast = RESTful verbs. CoAP also has congestion control, so it=E2=80=99s a = transport protocol. >=20 > Mirja K=C3=BChlewind: Right now we want to cover all the obvious = transport protocols. If people want to contribute text for others, we = can add those. >=20 > Aaron Falk: Andrew, is this an area you have expertise in? >=20 > Andrew McGregor: Some. >=20 > ** Aaron Falk: Andrew McGregor will identify a contributor to describe = CoAP (maybe himself). >=20 > Brian (or Robert?) Adamson, NRL: We should solicit additions via the = mailing list. >=20 > Aaron Falk: Please send text. >=20 > Joe Hildebrand: You asked the question: Is this a viable structure? My = answer is: I think so. But we should start with a detailed analysis of = something like TCP to make sure we understand how that fits the model. >=20 > Aaron Falk: I=E2=80=99d suggest exploring two examples so that we have = two data points. Michael already volunteered to do SCTP. >=20 > Slide 5: Who can contribute? >=20 > Dave Thaler: I=E2=80=99m thinking of a type of protocol that=E2=80=99s = missing from the list, and that=E2=80=99s things like TLS. Applications = ask for stuff. Protocols provide stuff. Applications ask for stuff like = confidentiality, integrity, etc. Protocols like TLS and IPSEC provide = confidentiality, integrity, etc. >=20 > Mirja K=C3=BChlewind: Please contribute text. >=20 > Dave Thaler: We think in terms of layers, but security is not a layer. = It=E2=80=99s on the side, affecting everything. We need to include the = things on the side too. >=20 > Brian Trammell: Security is definitely an aspect >=20 > Gorry Fairhurst: +1 >=20 > Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComponent=E2=80= =9D? >=20 > Gorry Fairhurst: What we want is a plan to make one of these sections = concrete from someone with expertise in the protocol. >=20 > Mirja K=C3=BChlewind: Yes. >=20 > Brian Trammell: We're asking the structure question here. >=20 > Andrew McGregor: The structure is ugly but I can=E2=80=99t see how it = could be better. We have to consider how you name the other endpoint. = DNS name? URL? Something else? Should that identity be proved in some = manner? How? TLS certificates? HIP identity hash match. >=20 > Mirja K=C3=BChlewind: I don=E2=80=99t need to specify how identity is = proved. >=20 > Andrew McGregor: You might if you only have credentials in a = particular form. >=20 > Mirja K=C3=BChlewind: This restricts what the transport protocol can = choose. >=20 > Joe Hildebrand: Let=E2=80=99s not debate API details until we have the = principles adequately characterized. Let=E2=80=99s know what the = building blocks are first. >=20 > Aaron Falk: I agree that we should flesh out a couple of sections and = use that as a basis for refining the rest of the document. Who will = volunteer to take on one of these sections? >=20 > ** Kevin Fall: Open mouth, insert work. I will do UDP. >=20 > Mirja K=C3=BChlewind: Are there no MPTCP people here? >=20 > Aaron Falk: What about basic TCP? >=20 > ** Mirja K=C3=BChlewind: I will do basic TCP, but it would be good to = have other people too. >=20 > Varun Singh: Is RTP excluded? >=20 > Mirja K=C3=BChlewind: Will you do that? >=20 > ** Varun Singh: I=E2=80=99ll contribute text for RTP. >=20 > Varun Singh: Is this document on GitHub? >=20 > Mirja K=C3=BChlewind: Gorry Fairhurst and Brian Trammell can decide = that. >=20 > Brian Trammell: I can move to markdown over GitHub, no problem. >=20 > Kevin Fall: Are the lessons we learn here going to reflected in the = previous document? >=20 > Mirja K=C3=BChlewind: This document just lists what=E2=80=99s there. >=20 > Kevin Fall: If we discover that idempotency is an important concept, = how does that get added to the document? >=20 > Joe Hildebrand: Finding those is the point of this exercise. >=20 > Aaron Falk: We=E2=80=99ll give you a cookie. >=20 > Varun Singh: It seems like we=E2=80=99re going to replicate a lot of = text from existing RFCs. >=20 > Aaron Falk: The goal is to take an existing protocol and identify what = services it is offering to the application. That=E2=80=99s what we want = to get in this document. >=20 > Mirja K=C3=BChlewind: What you as an expert for some protocol should = do is describe the protocol as completely as possible. >=20 > Dave Thaler: What are you looking for in each section? Service = components? Protocol features? Both? >=20 > Aaron Falk: I want the protocol components, but the way you get there = is to analyze the protocol features. >=20 > Mirja K=C3=BChlewind: Please provide text. >=20 > ** Dave Thaler: I volunteer to help with getting the matrix right, of = features vs. things that are protocols, e.g. inherent vs. optional is = another key thing for features. I=E2=80=99ve done such work in the past. = It=E2=80=99s useful to know which things are inherent features, and = which things are optional features. For example, with TCP you can have = keepalives or not. >=20 > Mirja K=C3=BChlewind: The first step is to describe the protocols. >=20 > ** Dave Thaler: I=E2=80=99m volunteering to help with the matrix more = than the specific text, but I may be able to do some of that too. >=20 > Jana Iyengar: Let=E2=80=99s not end up with a giant matrix and = checkboxes for various features. That=E2=80=99s not useful. >=20 > Mirja K=C3=BChlewind: There may be cases where two components do not = work together. >=20 > ** Karen Nielsen: I will provide SCTP text. >=20 > Karen Nielsen: Protocol features like ACK or NACK are not specific to = TCP. SCTP also has ACKs. You can=E2=80=99t say that protocol features = are specific to one protocol. >=20 > Mirja K=C3=BChlewind: Protocol features are specific to one protocol. >=20 > Karen Nielsen: So SCTP ACK is different to TCP ACK. >=20 > ** P=C3=A5l-Erik Martinsen: I will provide text for STUN >=20 > Charles Eckel: It will be helpful to combine everything into one = table. >=20 > Mirja K=C3=BChlewind: Having a single matrix would be really nice for = the document. But the first step is to describe the protocols and = extract the components they provide. >=20 > Kenneth Calvert: Is one of the goals here to come out with an ontology = of transport service components? >=20 > Aaron Falk: We are trying to confine the scope to IETF protocols. A = complete ontology would not necessarily be useful. >=20 > Kenneth Calvert: For this draft, before you plunge into the matrix, it = would be useful to define the existing components. >=20 > Mirja K=C3=BChlewind: This is the end goal of the document. >=20 > Brian (or Robert?) Adamson, NRL: Is there a template for a list of the = aspects we care about? >=20 > Mirja K=C3=BChlewind: This is just an initial attempt. >=20 > Brian Trammell: To Kenneth, =E2=80=9Cyes=E2=80=9D (but I am allergic = to the word ontology.) >=20 > Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2=80=99s the = entire point of this working group. >=20 > Michael Ramalho: This is a very hard problem when I think about how = some of these protocols were evolved to meet very special needs. Suppose = I have this application that doesn=E2=80=99t want head-of-line-blocking, = and maybe I don=E2=80=99t want to retransmit once or twice, and let=E2=80=99= s suppose I have something expressive enough to convey this to the = transport layer, and it can=E2=80=99t deliver this without using = multiple TCP connections, and maybe I would have preferred DTLS. How do = you express that to this layer? >=20 > Mirja K=C3=BChlewind: The document is focussed on the simple cases = first. >=20 > Pete Resnick: It would be a terrible failure if, in such situations, = the transport layer would ask the application what to do. The app = doesn=E2=80=99t care and doesn=E2=80=99t know. That I can pull this off = with 3 TCP connections is not something the app cares about. You either = give the app what it asks for or fail. >=20 > = =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 >=20 > ** 14:43 Aaron Falk called for adopting = draft-fairhurst-taps-transports-00 as WG document. > Folks who read the draft: maybe 10 + > Significant hum in support > None against >=20 > -- END >=20 >=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 Wed Dec 3 03:29:08 2014 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 B92071A000C for ; Wed, 3 Dec 2014 03:29:06 -0800 (PST) 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 xsufXdj4iyPl for ; Wed, 3 Dec 2014 03:28:59 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03CE1A1A40 for ; Wed, 3 Dec 2014 03:28:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2A50DD9304; Wed, 3 Dec 2014 12:28:56 +0100 (MET) 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 vQ+cxjYIf+f0; Wed, 3 Dec 2014 12:28:55 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id C29F9D9302; Wed, 3 Dec 2014 12:28:55 +0100 (MET) Message-ID: <547EF3F7.2070104@tik.ee.ethz.ch> Date: Wed, 03 Dec 2014 12:28:55 +0100 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Aaron Falk , "taps@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Ggjyfb4nsUulgj_Hk8ItZEWwISI Subject: Re: [Taps] draft minutes from IETF-91 meeting 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, 03 Dec 2014 11:29:07 -0000 Hi Aaron, I've read the minutes but as at least my statements are all reflected correctly, I didn't further response to your mail. Thanks a lot to the minutes talkers! The minutes document the meeting very detailed and well and therefore are very useful! As I now writing away, please introduce two small changes: 1) I'm pretty sure I've said 'middlebox' and not 'meddlebox' (even though meddlenox might actually be the more accurate term in some cases...) 2) s/We need a term like “aspect”/We might need a term like “aspect”/ Thanks, Mirja On 02.12.2014 23:45, Aaron Falk wrote: > I've seen no comments. It would be Really Nice if at least one person > could read the minutes before I submit them for the proceedings. > > --aaron > > On Sat, Nov 22, 2014 at 4:31 PM, Aaron Falk wrote: > >> If you spoke up in the Honolulu meeting, please review the minutes to >> confirm we captured your point. Thanks to Stuart Cheshire & Michael Welzl >> for their detailed notes. >> >> Thanks, >> >> --aaron >> >> ==================================================== >> >> Transport Services (TAPS) >> 1300-1500 HST Tuesday Afternoon Session I >> Notes taken by Stuart Cheshire & Michael Welzl >> >> AGENDA >> ======= >> 0. Agenda bashing >> 1. Charter Overview (Falk) - 10 min >> 2. Terminology Review (Kühlewind) - 30 min >> 3. Discussion of draft-fairhurst-taps-transports-00 (Kühlewind) >> - 20 min >> 4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg document? >> - 10 min >> >> Action items marked with ** >> >> ——————————————————————————————————— >> >> 13:05 Administrivia >> >> >> Aaron Falk: Who was at the TAPS BoF in Toronto? (Most people raised their >> hands.) >> >> Aaron Falk: And who is on the mailing list? (About the same.) >> >> Aaron Falk: In today’s meeting we’ll be having a discussion of >> terminology, and then a discussion of the working group’s first draft. We >> will be looking for volunteers. The current draft is an independent >> submission from two volunteers: Gorry Fairhurst and Brian Trammell, neither >> of whom could be here. We’ll be asking whether the people in the room want >> to adopt this as a Working Group document. >> >> ——————————————————————————————————— >> >> 13:08 Charter Overview (Falk) – 10 min >> >> Aaron Falk: The TAPS effort is focussing on the same area as the IAB Stack >> Evolution work, which is that there have been 20 years of transport area >> improvements that are largely undeployed because (i) the new transports are >> not supported in most operating systems, and (ii) the new transports may >> not work end-to-end on today’s Internet. As a result, application >> developers often build their own protocol on top of UDP, and sometimes that >> do that badly. The goal of this group is to enable application developers >> to get better performance and better behavior than they can get from TCP or >> UDP. >> >> The first task of the working group is to define what these behaviors are >> that application developers want to get. We call these “transport >> services”. Some examples are: Reliable delivery, in-order delivery, >> confidentiality, latency. It’s a way for applications to express what they >> want from the transport layer, and to ask for combinations that aren’t >> currently available from TCP and UDP. The transport layer then sees what’s >> available and provides the best that it can, which might be HTTP over TCP. >> To do this we’re first going to examine existing IETF technologies to see >> what behaviors they provide, to collect an initial set of behaviors that we >> think might be useful. We’re going to focus on communication between two >> endpoints, at least initially. That’s the first document, to submit to the >> IESG next June. >> >> Then there will be a second document which is a prioritization to select a >> subset of those services, and guidance how you might obtain those services >> using existing mechanisms. We will submit this to the IESG next December. >> >> The third document describes how to do discovery of whether these things >> work, how to do fallback, how to combine the protocols and make them >> available. We will submit this to the IESG in 2016. >> >> We’re not going to do signaling-based QoS. We’re not going to talk about >> new encapsulations and tunneling. We’re not going to define, modify, or >> extend transport protocols. We’re not going to define a language-specific >> API. We’re not going to do a detailed analysis of security, but we will >> document the security properties of existing protocols. The emphasis of >> this work is not security. >> >> Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow >> data-with-SYN, out-of-order delivery) >> >> Aaron Falk: Yes >> >> ——————————————————————————————————— >> >> 13:15 Terminology Review (Kühlewind) – 30 min >> >> >> (Mirja Kühlewind gave presentation of proposed terminology) >> >> Dave Thaler: Why not use term “facility” instead of “service component”? >> The term “service component” usually means a piece of code. >> >> Stein Gjessing: “component” means “part”. That’s not a “thing” or “unit”. >> >> Michael Welzl: I like this a lot. >> >> Brian Trammell: I’m okay with this suggestion. >> >> Kevin Fall: Standards Track RFC 2126 defines the term “transport services” >> as referred to by ISO. Don’t redefine terms that were already defined by an >> International Standard. >> >> Mirja Kühlewind: Our definition is just a little more specific. >> >> >> Kevin Fall: Reliability is not a binary property. UDPLite has partial >> reliability. >> >> Mirja Kühlewind: We discussed earlier whether we need a concept smaller >> than a “service component” for different types of reliability. We call this >> an “aspect”. >> >> Kevin Fall: That term has been reserved as well. >> >> Joe Hildebrand: Just pick Swiss German words instead, and we’ll all learn >> them. This way we have words that don’t have existing meanings in existing >> networking standards. >> >> Dave Thaler: And then we could try using non-US characters in RFCs. >> >> Mirja Kühlewind: I don’t care what we call it. We just have to agree on >> some terminology. Are those six descriptions the right concepts? >> >> Ignacio Solis: Is “reliability” an example of a “service component”? >> >> Mirja Kühlewind: Right. A transport service today provides you with a >> whole package of service components, not all of which you may want. It also >> may not include a service component that you do want. >> >> Ignacio Solis: We’re being bound by old thinking. >> >> Kevin Fall: You asked what is missing here. Is it connection-oriented? Is >> there connection establishment, notification? Is there flow control? None >> of that is mentioned. >> >> Mirja Kühlewind: These concepts are “service components”; a specific >> instantiation would be a “protocol feature”. >> >> Aaron Falk: The first two terms are things that applications ask for. The >> other terms are how you provide those things. >> >> Brian Trammell: Kevin is describing “aspects”. A “feature” is a thing that >> a protocol does on purpose, an “aspect” is something that it does, whether >> on purpose or not. >> >> Gorry Fairhurst: “Feature” is okay. >> >> Ken Calvert: I would call state establishment “mechanism” I don’t know if >> this will ever converge. Don’t conflate wire encoding with logical >> implementation. “Mechanism” is wire encoding + function. Why are you not >> saying “function”? >> >> Mirja Kühlewind: For me, the terms “mechanism” and “function” are too >> abstract. What you described is still a “feature”. >> >> Ken Calvert: I suggest not using “reliability” as an example because there >> are too many different kinds of reliability. >> >> Mirja Kühlewind: Do you think we need a term for concepts with smaller >> granularity than “component”? >> >> Ken Calvert: For that concept, use a Swiss German word. >> >> Mirja Kühlewind: Do we need one more term? >> >> Ken Calvert: Maybe. >> >> Andrew McGregor: The decomposition into pieces looks good, but I think >> “component” and “feature” should be swapped. >> >> Mirja Kühlewind: I got this feedback already. >> >> Jana Iyengar: Well, you just got this feedback again. I agree with Andrew. >> We should switch “component” and “feature”. A software “component” >> implements a “feature”. >> >> Mirja Kühlewind: Switching the terms would help? >> >> (A bunch of “yes” comments from the room.) >> >> Aaron Falk: That’s consensus. Move on. >> >> Edward Lopez: We should talk about segregating transport services from >> applications. Applications become independent of transport services. We >> should start thinking about the rise of transport service gateways. If your >> application uses UDP and my application uses TCP then something’s got to >> traverse. Is a gateway part of a potential terminology? >> >> Mirja Kühlewind: I think that’s out of scope. That would be a meddlebox. >> >> Aaron Falk: The use case we’re focussed on is two applications on two >> endpoints. You’re using “application” in a way that’s confusing me. >> >> Edward Lopez: If we’re talking about transport services and potential >> independence from applications, then when a common application is using >> different transport services, what’s going to interchange? What’s going to >> aid that conversation? That’s what’s not discussed here. >> >> Aaron Falk: We have pushed that off. The third effort of the working group >> to talk about an experiment with end-to-end compatibility. >> >> Edward Lopez: Then we’d need transport service negotiation. Separation of >> application from transport services leads me to think there’s a term >> missing. >> >> Mirja Kühlewind: What we want is not that the application is requesting >> TCP. What we want is that the application is requesting a certain service >> composition, and then the layer below can make the decision to use TCP. >> >> Ronald in 't Velt: I have not heard the term “element” yet. I agree with >> Kevin Fall. Let’s see what’s already there. I have a paper copy of ISO 8072 >> somewhere. I couldn’t find it. >> >> Mirja Kühlewind: I’m sure every term has already been used somewhere. >> >> Jana Iyengar: We should call them “Thing 1”, “Thing 2”, “Thing 3”, “Thing >> 4”. Seriously, how would I think about TCP over IPv6 over SSL over IPv4? >> >> Mirja Kühlewind: That’s an instance. If you request that service >> composition you get that stack. >> >> Aaron Falk: Jana, what is the application asking for? >> >> Pete Resnick: The whole idea of how discovery takes place where both >> transports talk to each other and say this is the way we’re going to >> communicate for this particular instance is independent right now and we’ll >> have to figure that out, but it’s not something an application cares about. >> We need to talk about feature discovery & negotiation. To address Ken’s >> comment, reliability and ordering should absolutely be separate components. >> >> Stuart Cheshire: I want to follow up to Jana’s point. The choice about >> what features to use is not decided only by the application. The choice of >> TCP vs UDP is decided by the application, but the choice of Ethernet vs >> Wi-Fi (with or without VPN) is decided by the user. Similarly, the choice >> of VPN or not may be decided by the corporate administrator, not the >> application, or the user. >> >> Aaron: The application needs to express hints about what it wants. You say >> there are other hints. Do we need to add something to our taxonomy that >> allows that information to get in? >> >> Stuart: I don’t think it extends this taxonomy, it might be an orthogonal >> dimension. User has an input, administrator has an input, application has >> an input. VPN is a classic example: application itself expresses no >> interest in security but the user does. >> >> Andrew McGregor: You can imagine that the API is that the application asks >> for a set of components, and the OS decides how to do that. >> >> Ignacio Solis: We are PARC are building something that doesn’t use >> sockets. We have our own terminology. We call the transport layer the >> “framework”. We build “stacks” with “components” following the design of >> composable stacks. The management component is missing here, especially if >> we are considering how this relates to middleboxes. >> >> Mirja Kühlewind: It would be nice if you could provide some references to >> this work on the list. >> >> Ignacio Solis: We have quite a number of things we’d be happy to share. >> >> Mirja Kühlewind: You give the application a whole view of what’s available >> at the transport layer. This work is to have an abstraction so the >> application doesn’t need to know the details. >> >> Ignacio Solis: We completely agree. The API hides the details of stack >> assembly from the application. But the application needs to be able to pick >> the entry component. The application needs to be able to pick the API it’s >> going to use. >> >> Dave Thaler: I agree with Stuart’s points. I see a relationship between >> this and the MIF working group. The MIF working group is doing similar >> things here concerning multiple provisioning domains. The application can >> express a set of preferences and get back information about what was >> chosen. When you think about the choice of saying which L3 protocol, they >> say “I’d like to go across a secure interface” and MIF does the interface >> selection logic. >> >> Aaron Falk: Are we re-using any MIF terms or concepts? >> >> Dave Thaler: I’m not aware of any any terminology collisions. Possibly we >> may be using different terms for the same things. The MIF work is >> complementary. >> >> Aaron Falk: Who in the room is active in the MIF working group? >> >> (Dave Thaler plus one other.) >> >> Aaron Falk: This whole conversation reminds me of DTN. >> >> Kevin Fall: With DTN we had to develop a pub/sub-style API. We also came >> to the conclusion that a third party needs an API to establish a policy on >> those bindings. In sockets there’s PF_* and AF_* to express some of these >> desires. But the application can also specify the precise protocols using >> IP_PROTO_*. It’s useful to take this choice that used to be wired in code >> and expose it though an API to an agent. The unit of expressing things is >> URIs. >> >> Brian Trammell: So this problem has always been trying to match the crappy >> interface above the transport to the crappy interface below. The >> terminology (and taps charter for that matter) assume the lower interface >> can be ignored. Although that might be impossible from a terminology >> standpoint. I think we probably don't want to define a term for the >> controller... but we might want to have a way to describe the things that >> the controller knows about the lower-interface transport aspects and path >> aspects. >> >> Mirja Kühlewind: The goal for right now is to set up an initial >> terminology for us to use. >> >> Szilveszter: Don’t we have to define how to choose a protocol? Is it in >> TAPS scope to say how we compose a transport? Isn’t it just an interface >> towards a transport? >> >> Aaron Falk: That is a question about the working group’s scope. The second >> document is to pick a subset of all the things an application could ask >> for. Right now we’re trying to figure out what those behaviors are. >> >> Toerless Eckert: Not all of the components here are things that we would >> traditionally call “transport”. Some of the components are in INT area. >> E.g. what about name resolution? >> >> Mirja Kühlewind: I believe name resolution is not a component. It’s a >> service. This is just a first step. We can still change the terms. >> >> Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to be >> using the same APIs as applications. >> >> Mirja Kühlewind: Let’s do the first step first. >> >> Andrew McGregor: Yes, but diagnostic tools require the ability to specify >> an exact stack in order to be able to generate the right sort of packet. >> >> Aaron Falk: That’s pretty clearly out of scope for the group. The goal >> here is to make things easier for application developers. >> >> Andrew McGregor: Is “ping” an application? >> >> Mirja Kühlewind: This should be hidden from the application. >> >> Andrew McGregor: The “ping” program is an application? >> >> Aaron Falk: No, it’s a utility, which is why it’s out of scope. >> >> Michael Welzl: I remember from the BoF there was consensus that we should >> have some kind of determinism to flag to provide repeatability for testing. >> >> Jana Iyengar: What Andrew is suggesting would be good. We need better >> tools. Without deterministic unique composition, how can you have >> interoperability? >> >> Mirja Kühlewind: For interoperability we come up with a new shim layer. >> This is what we want to hide from the application. >> >> Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot of >> layer violations. This working group has “transport” in the name. Ping uses >> ICMP. ICMP is not in the transport layer. To Jana’s point, there’s going to >> have to be some sort of rendezvous/discovery. Once an application requests >> a certain set of components, how the system establishes talking to the >> other side is just something for the lower layers to implement. >> >> Joe Hildebrand: Let’s agree what the components are before we debate how >> they’re negotiated. >> >> Andrew McGregor: Ping was a bad example. There’s a python library called >> “scapy” that lets you specify a bunch of properties and leave the rest >> unspecified and it will try and make it work. From incomplete information >> it fills in the gaps to make something sensible. This is a practical >> example of something that’s already out there. >> >> Brian Trammell: The factoring of this terminology, if not the words, >> support _everything_ we're talking about here. you can ask for a component, >> you can ask for a composition, you can ask for a protocol instance. What it >> doesn't support describing yet is getting info up from the lower layer. >> >> Kevin Fall: Identification of the endpoint gives me some concern. TCP has >> concepts like ports. Semantics are associated with that. The style of >> naming is relevant. >> >> Mirja Kühlewind: You could have a component “I want to transmit web >> traffic” and then naturally the first thing the transport protocol would do >> is open a connection on port 80. If that doesn’t work it could do something >> else. >> >> Kevin Fall: That’s high level example compared to components like >> “reliability”. >> >> Mirja Kühlewind: This is not for sure. This is the next step. We have to >> find out what’s out there and how we name these things. >> >> Kevin Fall: If these high level examples are what you’re talking about >> then high level frameworks well above the sockets layer are relevant. >> >> Mirja Kühlewind: I just don’t know. >> >> Mirja Kühlewind: My conclusions from discussion: We’ll switch the terms >> “component” and “feature”. This is a good starting point. We can have more >> discussions and change things if necessary. We need a term like “aspect” >> which is even a lower granularity than “component”. >> >> ——————————————————————————————————— >> >> 14:07 Discussion of draft-fairhurst-taps-transports-00 >> >> >> Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja Kühlewind. >> >> Goal is to survey existing transport protocols and extract the common >> components they have, and the ways they implement those. >> >> Slide 4: Relationship between transport protocols and service component >> >> Joe Hildebrand: There are other IETF areas who should be included (like >> RAI) that are not in the transport area but offer transport-like >> facilities. For example websocket. >> >> Mirja Kühlewind: As long as they are IETF protocols they are in scope. >> >> Dave Thaler: I strongly agree with Joe. Now we’re talking about >> architecture, how protocols map to services. I want to go back to what >> Stuart said about the multiple parties making the various requests. For >> example, it is not (usually) the application deciding that the link-layer >> should be Ethernet. We need to avoid the case where the applications at >> each end request the same service components but get different protocols >> and therefore have not interoperability. What that means is that the >> mapping from service components to protocol stacks needs to be >> deterministic on both ends. >> >> Mirja Kühlewind: There should be some kind of shim layer that does some >> kind of negotiation to make sure they can communicate. >> >> Dave Thaler: Okay, but the draft does not say that. >> >> Michael Welzl: This table may look like it proposes a mapping, but it’s >> just listing the protocols that currently exist. >> >> Jana Iyengar: Are we explicitly excluding non-IETF protocols? >> >> Aaron Falk: Yes, for this work item. We might expand the scope later. >> >> Kevin Fall: In this matrix UDP is defined as unicast, which surprises me >> considering that all multicast work uses UDP. How does multicast fit into >> this? >> >> Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast >> RESTful verbs. CoAP also has congestion control, so it’s a transport >> protocol. >> >> Mirja Kühlewind: Right now we want to cover all the obvious transport >> protocols. If people want to contribute text for others, we can add those. >> >> Aaron Falk: Andrew, is this an area you have expertise in? >> >> Andrew McGregor: Some. >> >> ** Aaron Falk: Andrew McGregor will identify a contributor to describe >> CoAP (maybe himself). >> >> Brian (or Robert?) Adamson, NRL: We should solicit additions via the >> mailing list. >> >> Aaron Falk: Please send text. >> >> Joe Hildebrand: You asked the question: Is this a viable structure? My >> answer is: I think so. But we should start with a detailed analysis of >> something like TCP to make sure we understand how that fits the model. >> >> Aaron Falk: I’d suggest exploring two examples so that we have two data >> points. Michael already volunteered to do SCTP. >> >> Slide 5: Who can contribute? >> >> Dave Thaler: I’m thinking of a type of protocol that’s missing from the >> list, and that’s things like TLS. Applications ask for stuff. Protocols >> provide stuff. Applications ask for stuff like confidentiality, integrity, >> etc. Protocols like TLS and IPSEC provide confidentiality, integrity, etc. >> >> Mirja Kühlewind: Please contribute text. >> >> Dave Thaler: We think in terms of layers, but security is not a layer. >> It’s on the side, affecting everything. We need to include the things on >> the side too. >> >> Brian Trammell: Security is definitely an aspect >> >> Gorry Fairhurst: +1 >> >> Mirja Kühlewind: “Aspect” or “Component”? >> >> Gorry Fairhurst: What we want is a plan to make one of these sections >> concrete from someone with expertise in the protocol. >> >> Mirja Kühlewind: Yes. >> >> Brian Trammell: We're asking the structure question here. >> >> Andrew McGregor: The structure is ugly but I can’t see how it could be >> better. We have to consider how you name the other endpoint. DNS name? URL? >> Something else? Should that identity be proved in some manner? How? TLS >> certificates? HIP identity hash match. >> >> Mirja Kühlewind: I don’t need to specify how identity is proved. >> >> Andrew McGregor: You might if you only have credentials in a particular >> form. >> >> Mirja Kühlewind: This restricts what the transport protocol can choose. >> >> Joe Hildebrand: Let’s not debate API details until we have the principles >> adequately characterized. Let’s know what the building blocks are first. >> >> Aaron Falk: I agree that we should flesh out a couple of sections and use >> that as a basis for refining the rest of the document. Who will volunteer >> to take on one of these sections? >> >> ** Kevin Fall: Open mouth, insert work. I will do UDP. >> >> Mirja Kühlewind: Are there no MPTCP people here? >> >> Aaron Falk: What about basic TCP? >> >> ** Mirja Kühlewind: I will do basic TCP, but it would be good to have >> other people too. >> >> Varun Singh: Is RTP excluded? >> >> Mirja Kühlewind: Will you do that? >> >> ** Varun Singh: I’ll contribute text for RTP. >> >> Varun Singh: Is this document on GitHub? >> >> Mirja Kühlewind: Gorry Fairhurst and Brian Trammell can decide that. >> >> Brian Trammell: I can move to markdown over GitHub, no problem. >> >> Kevin Fall: Are the lessons we learn here going to reflected in the >> previous document? >> >> Mirja Kühlewind: This document just lists what’s there. >> >> Kevin Fall: If we discover that idempotency is an important concept, how >> does that get added to the document? >> >> Joe Hildebrand: Finding those is the point of this exercise. >> >> Aaron Falk: We’ll give you a cookie. >> >> Varun Singh: It seems like we’re going to replicate a lot of text from >> existing RFCs. >> >> Aaron Falk: The goal is to take an existing protocol and identify what >> services it is offering to the application. That’s what we want to get in >> this document. >> >> Mirja Kühlewind: What you as an expert for some protocol should do is >> describe the protocol as completely as possible. >> >> Dave Thaler: What are you looking for in each section? Service components? >> Protocol features? Both? >> >> Aaron Falk: I want the protocol components, but the way you get there is >> to analyze the protocol features. >> >> Mirja Kühlewind: Please provide text. >> >> ** Dave Thaler: I volunteer to help with getting the matrix right, of >> features vs. things that are protocols, e.g. inherent vs. optional is >> another key thing for features. I’ve done such work in the past. It’s >> useful to know which things are inherent features, and which things are >> optional features. For example, with TCP you can have keepalives or not. >> >> Mirja Kühlewind: The first step is to describe the protocols. >> >> ** Dave Thaler: I’m volunteering to help with the matrix more than the >> specific text, but I may be able to do some of that too. >> >> Jana Iyengar: Let’s not end up with a giant matrix and checkboxes for >> various features. That’s not useful. >> >> Mirja Kühlewind: There may be cases where two components do not work >> together. >> >> ** Karen Nielsen: I will provide SCTP text. >> >> Karen Nielsen: Protocol features like ACK or NACK are not specific to TCP. >> SCTP also has ACKs. You can’t say that protocol features are specific to >> one protocol. >> >> Mirja Kühlewind: Protocol features are specific to one protocol. >> >> Karen Nielsen: So SCTP ACK is different to TCP ACK. >> >> ** Pål-Erik Martinsen: I will provide text for STUN >> >> Charles Eckel: It will be helpful to combine everything into one table. >> >> Mirja Kühlewind: Having a single matrix would be really nice for the >> document. But the first step is to describe the protocols and extract the >> components they provide. >> >> Kenneth Calvert: Is one of the goals here to come out with an ontology of >> transport service components? >> >> Aaron Falk: We are trying to confine the scope to IETF protocols. A >> complete ontology would not necessarily be useful. >> >> Kenneth Calvert: For this draft, before you plunge into the matrix, it >> would be useful to define the existing components. >> >> Mirja Kühlewind: This is the end goal of the document. >> >> Brian (or Robert?) Adamson, NRL: Is there a template for a list of the >> aspects we care about? >> >> Mirja Kühlewind: This is just an initial attempt. >> >> Brian Trammell: To Kenneth, “yes” (but I am allergic to the word ontology.) >> >> Gorry Fairhurst: To Brian (or Robert?) Adamson: That’s the entire point of >> this working group. >> >> Michael Ramalho: This is a very hard problem when I think about how some >> of these protocols were evolved to meet very special needs. Suppose I have >> this application that doesn’t want head-of-line-blocking, and maybe I don’t >> want to retransmit once or twice, and let’s suppose I have something >> expressive enough to convey this to the transport layer, and it can’t >> deliver this without using multiple TCP connections, and maybe I would have >> preferred DTLS. How do you express that to this layer? >> >> Mirja Kühlewind: The document is focussed on the simple cases first. >> >> Pete Resnick: It would be a terrible failure if, in such situations, the >> transport layer would ask the application what to do. The app doesn’t care >> and doesn’t know. That I can pull this off with 3 TCP connections is not >> something the app cares about. You either give the app what it asks for or >> fail. >> >> ——————————————————————————————————— >> >> ** 14:43 Aaron Falk called for adopting draft-fairhurst-taps-transports-00 >> as WG document. >> Folks who read the draft: maybe 10 + >> Significant hum in support >> None against >> >> -- END >> > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Wed Dec 3 03:34:34 2014 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 CFF261A1A63 for ; Wed, 3 Dec 2014 03:34:28 -0800 (PST) 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 ssq0Dm-kzzSl for ; Wed, 3 Dec 2014 03:34:26 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F91C1A0461 for ; Wed, 3 Dec 2014 03:34:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 01C97D9305 for ; Wed, 3 Dec 2014 12:34:25 +0100 (MET) 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 PevrKsc5Cp4H for ; Wed, 3 Dec 2014 12:34:24 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CE80DD9304 for ; Wed, 3 Dec 2014 12:34:24 +0100 (MET) Message-ID: <547EF540.7090403@tik.ee.ethz.ch> Date: Wed, 03 Dec 2014 12:34:24 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "taps@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/lw3IwhjRPKeQF3TDt1d3iflsZ-A Subject: [Taps] terminology and RFC2126 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, 03 Dec 2014 11:34:29 -0000 Hi, just been quickly checking the transport service definition in RFC 2126. From my understanding this is in line with the proposed definition of a transport service (composition) (but not inline with the definition as given in the charter). I still believe that we cannot only refer to RFC2126 though (but probobly should refer RFC2116 somehow) because we really should define this term in the set of the other terms to avoid confusion and provide a common set of terms so we can actually talk to each other. Please let me know if you disagree! Mirja From nobody Wed Dec 3 08:42:42 2014 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 394531A1BEC for ; Wed, 3 Dec 2014 08:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 rFyxOfXcxc17 for ; Wed, 3 Dec 2014 08:42:36 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614DC1A1B47 for ; Wed, 3 Dec 2014 08:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1697; q=dns/txt; s=iport; t=1417624957; x=1418834557; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QHpisXnolHx+SB+p5NcbnYw7WmfiBynJJbW+e3uSkzo=; b=ej1t12PUJ46Ez8tZ3QPN9tjBabcw9pqQO7x4U8+upsP9IXNLAJJnxzIG xVTiPeacTngTo4ebEu0K/PEue3qScXcy2Oy6Pb80jbmdUcwWzvw3cxwTH xGmCY4Q5ftWF6kLHIyDM4zQ5uXF3fpwB8tpnZBncpGhIcGRncLdu7KrGo Q=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAGc8f1StJA2D/2dsb2JhbABagwaBKgTMXQKBExYBAQEBAX2EAwEBAwF5BQsCAQhGMiUCBA4FDognCdZAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF40dg0kHgySBHgEEkA+BdoFAhxSUFoIQgWhvAYFEgQABAQE X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="asc'?scan'208";a="377272590" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP; 03 Dec 2014 16:42:36 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB3GgZiB010736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 16:42:35 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 10:42:35 -0600 From: "Fred Baker (fred)" To: =?Windows-1252?Q?Mirja_K=FChlewind?= Thread-Topic: [Taps] terminology and RFC2126 Thread-Index: AQHQDxgjc32xGnRpwU6CSA5KGqV5VA== Date: Wed, 3 Dec 2014 16:42:34 +0000 Message-ID: <657744E7-0656-48F1-93D1-F82A0DB9628A@cisco.com> References: <547EF540.7090403@tik.ee.ethz.ch> In-Reply-To: <547EF540.7090403@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.121] Content-Type: multipart/signed; boundary="Apple-Mail=_0AB16D88-50A9-4ACC-BD76-D4F7FD7713CD"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/pdM4eeQt1rabW88K6NBB1Z-Ux9s Cc: "taps@ietf.org" Subject: Re: [Taps] terminology and RFC2126 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, 03 Dec 2014 16:42:39 -0000 --Apple-Mail=_0AB16D88-50A9-4ACC-BD76-D4F7FD7713CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 3, 2014, at 3:34 AM, Mirja K=FChlewind = wrote: > just been quickly checking the transport service definition in RFC = 2126. =46rom my understanding this is in line with the proposed = definition of a transport service (composition) (but not inline with the = definition as given in the charter). I still believe that we cannot only = refer to RFC2126 though (but probobly should refer RFC2116 somehow) = because we really should define this term in the set of the other terms = to avoid confusion and provide a common set of terms so we can actually = talk to each other. Where does 1006 come in? 2126 updates 1006, and as near as I can tell = the difference is in what gets left out - TP-2, TP-0, and a couple of = other things. I believe that IEC documents refer primarily to 1006. 2126 defines an interface for TP-4. That would be SCTP=92s message = service. What is needed to make the transport definition also allow for = an SCTP underpinning? --Apple-Mail=_0AB16D88-50A9-4ACC-BD76-D4F7FD7713CD 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 - http://gpgtools.org iD8DBQFUfz1sbjEdbHIsm0MRAmdqAJ9P2IRJPFRGB32P6gaHOASVXAdHgwCg2vUI sYGXx0fuIbV0go1XwsyxY7k= =nNG4 -----END PGP SIGNATURE----- --Apple-Mail=_0AB16D88-50A9-4ACC-BD76-D4F7FD7713CD-- From nobody Thu Dec 4 14:33:39 2014 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 CDAB81A7020 for ; Thu, 4 Dec 2014 14:33:34 -0800 (PST) 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 x6_5X8ZJ0p4s for ; Thu, 4 Dec 2014 14:33:33 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907FA1A6FEA for ; Thu, 4 Dec 2014 14:33:32 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id hs14so10667885lab.11 for ; Thu, 04 Dec 2014 14:33:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2Ln5Mk4P8SuF1m2m/fdNdQo3HWo1Y/G7uEODmcS/3w0=; b=SMCYIbDvAuN6aWA1szn1kr7N+h1LNwBd8Crz/7xblWOMHV4K48lfTWy82T01AGBthF 9OpLVyP85Tr61LalTM3/1Oa96eQd7/1dnngnM1xYrV5EMUNS4PSdIlr2nQD+X4u1zHAR 66u8B381QNagMfJqHa9WBnRjEl3U83KXwfK5dx/DyUMPi32viLQO6aG5gqm8H1bnuiIF yPYVHr1rE1VLFXQZTIY1ERBtcZduDBxbqX+8cTBe87ZxyDoZRd53NWxm9GMp6/rybKv8 QMBM/g2XdQ7VCPTjn6gHWSxgFKiK9/FfqzjphZes2Ff+X/70SlOwYApDZzekuF993cDH B6Zg== X-Received: by 10.112.130.65 with SMTP id oc1mr11913656lbb.7.1417732411121; Thu, 04 Dec 2014 14:33:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.5 with HTTP; Thu, 4 Dec 2014 14:33:10 -0800 (PST) In-Reply-To: References: From: Varun Singh Date: Fri, 5 Dec 2014 00:33:10 +0200 Message-ID: To: Aaron Falk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/7vfyJRmzZtx3O4x8-pDhBylln0c Cc: "taps@ietf.org" Subject: Re: [Taps] doc update 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, 04 Dec 2014 22:33:35 -0000 At the meeting, I had requested that the draft (xml) be made available on Github? IMO it is easier to contribute via pull requests, and also to review the diffs, comment inline, etc. Cheers, Varun On Wed, Dec 3, 2014 at 1:31 AM, Aaron Falk wrote: > Hi Folks- > > A quick update on doc 1. For folks who've agreed to author text, it would > be useful to have some sample sections as a model. Brian tells me the plan > is to get a -00 out with (1) updates from the meeting (primarily on > terminology and structure) and (2) an example transport protocol section out > the door before the end of the year. So, stay tuned! > > Cheers, > > --aaron > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > -- http://www.netlab.tkk.fi/~varun/ From nobody Fri Dec 5 01:19:18 2014 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 2B1A61ACE1A for ; Fri, 5 Dec 2014 01:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 8fTQEArPsbI2 for ; Fri, 5 Dec 2014 01:19:06 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C5C921ACE2C for ; Fri, 5 Dec 2014 01:19:05 -0800 (PST) Received: from [10.176.233.118] (unknown [213.55.184.225]) by trammell.ch (Postfix) with ESMTPSA id 491B01A0382; Fri, 5 Dec 2014 10:18:34 +0100 (CET) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (12B435) From: Brian Trammell Date: Fri, 5 Dec 2014 10:18:24 +0100 To: Varun Singh Archived-At: http://mailarchive.ietf.org/arch/msg/taps/kOJc7Oo7ZgmdXGApqVoQyqjmbXs Cc: Aaron Falk , "taps@ietf.org" Subject: Re: [Taps] doc update 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, 05 Dec 2014 09:19:15 -0000 Hi Varun, all See github.com/britram/taps-transports/ Cheers, Brian Sent from my iPhone > On 04.12.2014, at 23:33, Varun Singh wrote: >=20 > At the meeting, I had requested that the draft (xml) be made available > on Github? > IMO it is easier to contribute via pull requests, and also to review > the diffs, comment inline, etc. >=20 > Cheers, > Varun >=20 >> On Wed, Dec 3, 2014 at 1:31 AM, Aaron Falk wrote: >> Hi Folks- >>=20 >> A quick update on doc 1. For folks who've agreed to author text, it woul= d >> be useful to have some sample sections as a model. Brian tells me the pl= an >> is to get a -00 out with (1) updates from the meeting (primarily on >> terminology and structure) and (2) an example transport protocol section o= ut >> the door before the end of the year. So, stay tuned! >>=20 >> Cheers, >>=20 >> --aaron >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 >=20 >=20 > --=20 > http://www.netlab.tkk.fi/~varun/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 5 05:52:31 2014 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 6304D1A064C for ; Fri, 5 Dec 2014 05:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, HTML_MESSAGE=0.001, 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 TkPBfYBu4XCM for ; Fri, 5 Dec 2014 05:52:20 -0800 (PST) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D261A0636 for ; Fri, 5 Dec 2014 05:52:16 -0800 (PST) Received: by mail-vc0-f174.google.com with SMTP id id10so308748vcb.19 for ; Fri, 05 Dec 2014 05:52:16 -0800 (PST) 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 :cc:content-type; bh=0HSHPaM1naR4TF3ax4kbTNpiJ+l20+5adMyTaEboa3M=; b=NoIa68jsL11DXcDntlBge7XHoTo0l93BRQfbp07Hj1i1ihCi9SsiRf2Z6O/yW9HsWe v0DLnjtvqrNt4ZUrMVQP5ZDmoiJcLXTyOW40AbFrTgnNIz7r4zIqHXauzMR0W6rZjtDE robvsDC/hfVCIrm7PMjSBeTvDC/h1i9/sJ71dGqMFYWlbR8oSgAhW86R1tCjhIm1UCiN Pk1LLZkG617ckY2wkA9j68rsdPLEoKU7zomuYkbRbDkyozQ2uFaTvohn/OQeht1e8vuQ TJEBfnuRC9ZktkJ/IyfM70Cu0+xGPxEqjwlGB11ANUdr+GjQ0cLCl8feD8KmiwHPKpj4 vJZw== MIME-Version: 1.0 X-Received: by 10.52.27.237 with SMTP id w13mr7084027vdg.68.1417787535833; Fri, 05 Dec 2014 05:52:15 -0800 (PST) Received: by 10.52.28.174 with HTTP; Fri, 5 Dec 2014 05:52:15 -0800 (PST) In-Reply-To: <547EF3F7.2070104@tik.ee.ethz.ch> References: <547EF3F7.2070104@tik.ee.ethz.ch> Date: Fri, 5 Dec 2014 08:52:15 -0500 Message-ID: From: Aaron Falk To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=20cf307abed570c1e005097862d1 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/xVsNmwH2VLnQuDw6Ne042r81E2k Cc: "taps@ietf.org" Subject: Re: [Taps] draft minutes from IETF-91 meeting 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, 05 Dec 2014 13:52:29 -0000 --20cf307abed570c1e005097862d1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ack. But I like 'meddlebox' better. :) --aaron On Wed, Dec 3, 2014 at 6:28 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Aaron, > > I've read the minutes but as at least my statements are all reflected > correctly, I didn't further response to your mail. > > Thanks a lot to the minutes talkers! The minutes document the meeting ver= y > detailed and well and therefore are very useful! > > As I now writing away, please introduce two small changes: > > 1) I'm pretty sure I've said 'middlebox' and not 'meddlebox' (even though > meddlenox might actually be the more accurate term in some cases...) > > 2) s/We need a term like =E2=80=9Caspect=E2=80=9D/We might need a term li= ke =E2=80=9Caspect=E2=80=9D/ > > Thanks, > Mirja > > > > On 02.12.2014 23:45, Aaron Falk wrote: > >> I've seen no comments. It would be Really Nice if at least one person >> could read the minutes before I submit them for the proceedings. >> >> --aaron >> >> On Sat, Nov 22, 2014 at 4:31 PM, Aaron Falk wrote= : >> >> If you spoke up in the Honolulu meeting, please review the minutes to >>> confirm we captured your point. Thanks to Stuart Cheshire & Michael >>> Welzl >>> for their detailed notes. >>> >>> Thanks, >>> >>> --aaron >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>> >>> Transport Services (TAPS) >>> 1300-1500 HST Tuesday Afternoon Session I >>> Notes taken by Stuart Cheshire & Michael Welzl >>> >>> AGENDA >>> =3D=3D=3D=3D=3D=3D=3D >>> 0. Agenda bashing >>> 1. Charter Overview (Falk) - 10 min >>> 2. Terminology Review (K=C3=BChlewind) - 30 min >>> 3. Discussion of draft-fairhurst-taps-transports-00 >>> (K=C3=BChlewind) >>> - 20 min >>> 4. Hum: Adopt draft-fairhurst-taps-transports-00 as wg >>> document? >>> - 10 min >>> >>> Action items marked with ** >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 >>> >>> 13:05 Administrivia >>> >>> >>> Aaron Falk: Who was at the TAPS BoF in Toronto? (Most people raised >>> their >>> hands.) >>> >>> Aaron Falk: And who is on the mailing list? (About the same.) >>> >>> Aaron Falk: In today=E2=80=99s meeting we=E2=80=99ll be having a discus= sion of >>> terminology, and then a discussion of the working group=E2=80=99s first= draft. We >>> will be looking for volunteers. The current draft is an independent >>> submission from two volunteers: Gorry Fairhurst and Brian Trammell, >>> neither >>> of whom could be here. We=E2=80=99ll be asking whether the people in th= e room >>> want >>> to adopt this as a Working Group document. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 >>> >>> 13:08 Charter Overview (Falk) =E2=80=93 10 min >>> >>> Aaron Falk: The TAPS effort is focussing on the same area as the IAB >>> Stack >>> Evolution work, which is that there have been 20 years of transport are= a >>> improvements that are largely undeployed because (i) the new transports >>> are >>> not supported in most operating systems, and (ii) the new transports ma= y >>> not work end-to-end on today=E2=80=99s Internet. As a result, applicati= on >>> developers often build their own protocol on top of UDP, and sometimes >>> that >>> do that badly. The goal of this group is to enable application develope= rs >>> to get better performance and better behavior than they can get from TC= P >>> or >>> UDP. >>> >>> The first task of the working group is to define what these behaviors a= re >>> that application developers want to get. We call these =E2=80=9Ctranspo= rt >>> services=E2=80=9D. Some examples are: Reliable delivery, in-order deliv= ery, >>> confidentiality, latency. It=E2=80=99s a way for applications to expres= s what >>> they >>> want from the transport layer, and to ask for combinations that aren=E2= =80=99t >>> currently available from TCP and UDP. The transport layer then sees >>> what=E2=80=99s >>> available and provides the best that it can, which might be HTTP over >>> TCP. >>> To do this we=E2=80=99re first going to examine existing IETF technolog= ies to see >>> what behaviors they provide, to collect an initial set of behaviors tha= t >>> we >>> think might be useful. We=E2=80=99re going to focus on communication b= etween two >>> endpoints, at least initially. That=E2=80=99s the first document, to s= ubmit to >>> the >>> IESG next June. >>> >>> Then there will be a second document which is a prioritization to selec= t >>> a >>> subset of those services, and guidance how you might obtain those >>> services >>> using existing mechanisms. We will submit this to the IESG next Decembe= r. >>> >>> The third document describes how to do discovery of whether these thing= s >>> work, how to do fallback, how to combine the protocols and make them >>> available. We will submit this to the IESG in 2016. >>> >>> We=E2=80=99re not going to do signaling-based QoS. We=E2=80=99re not go= ing to talk about >>> new encapsulations and tunneling. We=E2=80=99re not going to define, mo= dify, or >>> extend transport protocols. We=E2=80=99re not going to define a languag= e-specific >>> API. We=E2=80=99re not going to do a detailed analysis of security, bu= t we will >>> document the security properties of existing protocols. The emphasis of >>> this work is not security. >>> >>> Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow >>> data-with-SYN, out-of-order delivery) >>> >>> Aaron Falk: Yes >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 >>> >>> 13:15 Terminology Review (K=C3=BChlewind) =E2=80=93 30 min >>> >>> >>> (Mirja K=C3=BChlewind gave presentation of proposed terminology) >>> >>> Dave Thaler: Why not use term =E2=80=9Cfacility=E2=80=9D instead of =E2= =80=9Cservice component=E2=80=9D? >>> The term =E2=80=9Cservice component=E2=80=9D usually means a piece of c= ode. >>> >>> Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80=9Cpart=E2=80= =9D. That=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9Cunit=E2=80=9D= . >>> >>> Michael Welzl: I like this a lot. >>> >>> Brian Trammell: I=E2=80=99m okay with this suggestion. >>> >>> Kevin Fall: Standards Track RFC 2126 defines the term =E2=80=9Ctranspor= t >>> services=E2=80=9D >>> as referred to by ISO. Don=E2=80=99t redefine terms that were already d= efined by >>> an >>> International Standard. >>> >>> Mirja K=C3=BChlewind: Our definition is just a little more specific. >>> >>> >>> Kevin Fall: Reliability is not a binary property. UDPLite has partial >>> reliability. >>> >>> Mirja K=C3=BChlewind: We discussed earlier whether we need a concept sm= aller >>> than a =E2=80=9Cservice component=E2=80=9D for different types of relia= bility. We call >>> this >>> an =E2=80=9Caspect=E2=80=9D. >>> >>> Kevin Fall: That term has been reserved as well. >>> >>> Joe Hildebrand: Just pick Swiss German words instead, and we=E2=80=99ll= all learn >>> them. This way we have words that don=E2=80=99t have existing meanings = in >>> existing >>> networking standards. >>> >>> Dave Thaler: And then we could try using non-US characters in RFCs. >>> >>> Mirja K=C3=BChlewind: I don=E2=80=99t care what we call it. We just hav= e to agree on >>> some terminology. Are those six descriptions the right concepts? >>> >>> Ignacio Solis: Is =E2=80=9Creliability=E2=80=9D an example of a =E2=80= =9Cservice component=E2=80=9D? >>> >>> Mirja K=C3=BChlewind: Right. A transport service today provides you wit= h a >>> whole package of service components, not all of which you may want. It >>> also >>> may not include a service component that you do want. >>> >>> Ignacio Solis: We=E2=80=99re being bound by old thinking. >>> >>> Kevin Fall: You asked what is missing here. Is it connection-oriented? = Is >>> there connection establishment, notification? Is there flow control? No= ne >>> of that is mentioned. >>> >>> Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice components=E2= =80=9D; a specific >>> instantiation would be a =E2=80=9Cprotocol feature=E2=80=9D. >>> >>> Aaron Falk: The first two terms are things that applications ask for. T= he >>> other terms are how you provide those things. >>> >>> Brian Trammell: Kevin is describing =E2=80=9Caspects=E2=80=9D. A =E2=80= =9Cfeature=E2=80=9D is a thing >>> that >>> a protocol does on purpose, an =E2=80=9Caspect=E2=80=9D is something th= at it does, >>> whether >>> on purpose or not. >>> >>> Gorry Fairhurst: =E2=80=9CFeature=E2=80=9D is okay. >>> >>> Ken Calvert: I would call state establishment =E2=80=9Cmechanism=E2=80= =9D I don=E2=80=99t know if >>> this will ever converge. Don=E2=80=99t conflate wire encoding with logi= cal >>> implementation. =E2=80=9CMechanism=E2=80=9D is wire encoding + function= . Why are you not >>> saying =E2=80=9Cfunction=E2=80=9D? >>> >>> Mirja K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D and= =E2=80=9Cfunction=E2=80=9D are too >>> abstract. What you described is still a =E2=80=9Cfeature=E2=80=9D. >>> >>> Ken Calvert: I suggest not using =E2=80=9Creliability=E2=80=9D as an ex= ample because >>> there >>> are too many different kinds of reliability. >>> >>> Mirja K=C3=BChlewind: Do you think we need a term for concepts with sma= ller >>> granularity than =E2=80=9Ccomponent=E2=80=9D? >>> >>> Ken Calvert: For that concept, use a Swiss German word. >>> >>> Mirja K=C3=BChlewind: Do we need one more term? >>> >>> Ken Calvert: Maybe. >>> >>> Andrew McGregor: The decomposition into pieces looks good, but I think >>> =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D should be swa= pped. >>> >>> Mirja K=C3=BChlewind: I got this feedback already. >>> >>> Jana Iyengar: Well, you just got this feedback again. I agree with >>> Andrew. >>> We should switch =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80= =9D. A software =E2=80=9Ccomponent=E2=80=9D >>> implements a =E2=80=9Cfeature=E2=80=9D. >>> >>> Mirja K=C3=BChlewind: Switching the terms would help? >>> >>> (A bunch of =E2=80=9Cyes=E2=80=9D comments from the room.) >>> >>> Aaron Falk: That=E2=80=99s consensus. Move on. >>> >>> Edward Lopez: We should talk about segregating transport services from >>> applications. Applications become independent of transport services. We >>> should start thinking about the rise of transport service gateways. If >>> your >>> application uses UDP and my application uses TCP then something=E2=80= =99s got to >>> traverse. Is a gateway part of a potential terminology? >>> >>> Mirja K=C3=BChlewind: I think that=E2=80=99s out of scope. That would b= e a meddlebox. >>> >>> Aaron Falk: The use case we=E2=80=99re focussed on is two applications = on two >>> endpoints. You=E2=80=99re using =E2=80=9Capplication=E2=80=9D in a way = that=E2=80=99s confusing me. >>> >>> Edward Lopez: If we=E2=80=99re talking about transport services and pot= ential >>> independence from applications, then when a common application is using >>> different transport services, what=E2=80=99s going to interchange? What= =E2=80=99s going >>> to >>> aid that conversation? That=E2=80=99s what=E2=80=99s not discussed here= . >>> >>> Aaron Falk: We have pushed that off. The third effort of the working >>> group >>> to talk about an experiment with end-to-end compatibility. >>> >>> Edward Lopez: Then we=E2=80=99d need transport service negotiation. Sep= aration of >>> application from transport services leads me to think there=E2=80=99s a= term >>> missing. >>> >>> Mirja K=C3=BChlewind: What we want is not that the application is reque= sting >>> TCP. What we want is that the application is requesting a certain servi= ce >>> composition, and then the layer below can make the decision to use TCP. >>> >>> Ronald in 't Velt: I have not heard the term =E2=80=9Celement=E2=80=9D = yet. I agree with >>> Kevin Fall. Let=E2=80=99s see what=E2=80=99s already there. I have a pa= per copy of ISO >>> 8072 >>> somewhere. I couldn=E2=80=99t find it. >>> >>> Mirja K=C3=BChlewind: I=E2=80=99m sure every term has already been used= somewhere. >>> >>> Jana Iyengar: We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CT= hing 2=E2=80=9D, =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing >>> 4=E2=80=9D. Seriously, how would I think about TCP over IPv6 over SSL o= ver IPv4? >>> >>> Mirja K=C3=BChlewind: That=E2=80=99s an instance. If you request that s= ervice >>> composition you get that stack. >>> >>> Aaron Falk: Jana, what is the application asking for? >>> >>> Pete Resnick: The whole idea of how discovery takes place where both >>> transports talk to each other and say this is the way we=E2=80=99re goi= ng to >>> communicate for this particular instance is independent right now and >>> we=E2=80=99ll >>> have to figure that out, but it=E2=80=99s not something an application = cares >>> about. >>> We need to talk about feature discovery & negotiation. To address Ken= =E2=80=99s >>> comment, reliability and ordering should absolutely be separate >>> components. >>> >>> Stuart Cheshire: I want to follow up to Jana=E2=80=99s point. The choic= e about >>> what features to use is not decided only by the application. The choice >>> of >>> TCP vs UDP is decided by the application, but the choice of Ethernet vs >>> Wi-Fi (with or without VPN) is decided by the user. Similarly, the choi= ce >>> of VPN or not may be decided by the corporate administrator, not the >>> application, or the user. >>> >>> Aaron: The application needs to express hints about what it wants. You >>> say >>> there are other hints. Do we need to add something to our taxonomy that >>> allows that information to get in? >>> >>> Stuart: I don=E2=80=99t think it extends this taxonomy, it might be an = orthogonal >>> dimension. User has an input, administrator has an input, application h= as >>> an input. VPN is a classic example: application itself expresses no >>> interest in security but the user does. >>> >>> Andrew McGregor: You can imagine that the API is that the application >>> asks >>> for a set of components, and the OS decides how to do that. >>> >>> Ignacio Solis: We are PARC are building something that doesn=E2=80=99t = use >>> sockets. We have our own terminology. We call the transport layer the >>> =E2=80=9Cframework=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with =E2= =80=9Ccomponents=E2=80=9D following the design of >>> composable stacks. The management component is missing here, especially >>> if >>> we are considering how this relates to middleboxes. >>> >>> Mirja K=C3=BChlewind: It would be nice if you could provide some refere= nces to >>> this work on the list. >>> >>> Ignacio Solis: We have quite a number of things we=E2=80=99d be happy t= o share. >>> >>> Mirja K=C3=BChlewind: You give the application a whole view of what=E2= =80=99s >>> available >>> at the transport layer. This work is to have an abstraction so the >>> application doesn=E2=80=99t need to know the details. >>> >>> Ignacio Solis: We completely agree. The API hides the details of stack >>> assembly from the application. But the application needs to be able to >>> pick >>> the entry component. The application needs to be able to pick the API >>> it=E2=80=99s >>> going to use. >>> >>> Dave Thaler: I agree with Stuart=E2=80=99s points. I see a relationship= between >>> this and the MIF working group. The MIF working group is doing similar >>> things here concerning multiple provisioning domains. The application c= an >>> express a set of preferences and get back information about what was >>> chosen. When you think about the choice of saying which L3 protocol, >>> they >>> say =E2=80=9CI=E2=80=99d like to go across a secure interface=E2=80=9D = and MIF does the interface >>> selection logic. >>> >>> Aaron Falk: Are we re-using any MIF terms or concepts? >>> >>> Dave Thaler: I=E2=80=99m not aware of any any terminology collisions. P= ossibly we >>> may be using different terms for the same things. The MIF work is >>> complementary. >>> >>> Aaron Falk: Who in the room is active in the MIF working group? >>> >>> (Dave Thaler plus one other.) >>> >>> Aaron Falk: This whole conversation reminds me of DTN. >>> >>> Kevin Fall: With DTN we had to develop a pub/sub-style API. We also cam= e >>> to the conclusion that a third party needs an API to establish a policy >>> on >>> those bindings. In sockets there=E2=80=99s PF_* and AF_* to express som= e of these >>> desires. But the application can also specify the precise protocols usi= ng >>> IP_PROTO_*. It=E2=80=99s useful to take this choice that used to be wir= ed in code >>> and expose it though an API to an agent. The unit of expressing things = is >>> URIs. >>> >>> Brian Trammell: So this problem has always been trying to match the >>> crappy >>> interface above the transport to the crappy interface below. The >>> terminology (and taps charter for that matter) assume the lower interfa= ce >>> can be ignored. Although that might be impossible from a terminology >>> standpoint. I think we probably don't want to define a term for the >>> controller... but we might want to have a way to describe the things th= at >>> the controller knows about the lower-interface transport aspects and pa= th >>> aspects. >>> >>> Mirja K=C3=BChlewind: The goal for right now is to set up an initial >>> terminology for us to use. >>> >>> Szilveszter: Don=E2=80=99t we have to define how to choose a protocol? = Is it in >>> TAPS scope to say how we compose a transport? Isn=E2=80=99t it just an = interface >>> towards a transport? >>> >>> Aaron Falk: That is a question about the working group=E2=80=99s scope.= The >>> second >>> document is to pick a subset of all the things an application could ask >>> for. Right now we=E2=80=99re trying to figure out what those behaviors = are. >>> >>> Toerless Eckert: Not all of the components here are things that we woul= d >>> traditionally call =E2=80=9Ctransport=E2=80=9D. Some of the components = are in INT area. >>> E.g. what about name resolution? >>> >>> Mirja K=C3=BChlewind: I believe name resolution is not a component. It= =E2=80=99s a >>> service. This is just a first step. We can still change the terms. >>> >>> Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to b= e >>> using the same APIs as applications. >>> >>> Mirja K=C3=BChlewind: Let=E2=80=99s do the first step first. >>> >>> Andrew McGregor: Yes, but diagnostic tools require the ability to speci= fy >>> an exact stack in order to be able to generate the right sort of packet= . >>> >>> Aaron Falk: That=E2=80=99s pretty clearly out of scope for the group. T= he goal >>> here is to make things easier for application developers. >>> >>> Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an application? >>> >>> Mirja K=C3=BChlewind: This should be hidden from the application. >>> >>> Andrew McGregor: The =E2=80=9Cping=E2=80=9D program is an application? >>> >>> Aaron Falk: No, it=E2=80=99s a utility, which is why it=E2=80=99s out o= f scope. >>> >>> Michael Welzl: I remember from the BoF there was consensus that we shou= ld >>> have some kind of determinism to flag to provide repeatability for >>> testing. >>> >>> Jana Iyengar: What Andrew is suggesting would be good. We need better >>> tools. Without deterministic unique composition, how can you have >>> interoperability? >>> >>> Mirja K=C3=BChlewind: For interoperability we come up with a new shim l= ayer. >>> This is what we want to hide from the application. >>> >>> Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot o= f >>> layer violations. This working group has =E2=80=9Ctransport=E2=80=9D in= the name. Ping >>> uses >>> ICMP. ICMP is not in the transport layer. To Jana=E2=80=99s point, ther= e=E2=80=99s going >>> to >>> have to be some sort of rendezvous/discovery. Once an application >>> requests >>> a certain set of components, how the system establishes talking to the >>> other side is just something for the lower layers to implement. >>> >>> Joe Hildebrand: Let=E2=80=99s agree what the components are before we d= ebate how >>> they=E2=80=99re negotiated. >>> >>> Andrew McGregor: Ping was a bad example. There=E2=80=99s a python libra= ry called >>> =E2=80=9Cscapy=E2=80=9D that lets you specify a bunch of properties and= leave the rest >>> unspecified and it will try and make it work. From incomplete informati= on >>> it fills in the gaps to make something sensible. This is a practical >>> example of something that=E2=80=99s already out there. >>> >>> Brian Trammell: The factoring of this terminology, if not the words, >>> support _everything_ we're talking about here. you can ask for a >>> component, >>> you can ask for a composition, you can ask for a protocol instance. Wha= t >>> it >>> doesn't support describing yet is getting info up from the lower layer. >>> >>> Kevin Fall: Identification of the endpoint gives me some concern. TCP h= as >>> concepts like ports. Semantics are associated with that. The style of >>> naming is relevant. >>> >>> Mirja K=C3=BChlewind: You could have a component =E2=80=9CI want to tra= nsmit web >>> traffic=E2=80=9D and then naturally the first thing the transport proto= col would >>> do >>> is open a connection on port 80. If that doesn=E2=80=99t work it could = do >>> something >>> else. >>> >>> Kevin Fall: That=E2=80=99s high level example compared to components li= ke >>> =E2=80=9Creliability=E2=80=9D. >>> >>> Mirja K=C3=BChlewind: This is not for sure. This is the next step. We h= ave to >>> find out what=E2=80=99s out there and how we name these things. >>> >>> Kevin Fall: If these high level examples are what you=E2=80=99re talkin= g about >>> then high level frameworks well above the sockets layer are relevant. >>> >>> Mirja K=C3=BChlewind: I just don=E2=80=99t know. >>> >>> Mirja K=C3=BChlewind: My conclusions from discussion: We=E2=80=99ll sw= itch the terms >>> =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. This is a go= od starting point. We can have >>> more >>> discussions and change things if necessary. We need a term like =E2=80= =9Caspect=E2=80=9D >>> which is even a lower granularity than =E2=80=9Ccomponent=E2=80=9D. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 >>> >>> 14:07 Discussion of draft-fairhurst-taps-transports-00 >>> >>> >>> Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja K=C3=BCh= lewind. >>> >>> Goal is to survey existing transport protocols and extract the common >>> components they have, and the ways they implement those. >>> >>> Slide 4: Relationship between transport protocols and service component >>> >>> Joe Hildebrand: There are other IETF areas who should be included (like >>> RAI) that are not in the transport area but offer transport-like >>> facilities. For example websocket. >>> >>> Mirja K=C3=BChlewind: As long as they are IETF protocols they are in sc= ope. >>> >>> Dave Thaler: I strongly agree with Joe. Now we=E2=80=99re talking about >>> architecture, how protocols map to services. I want to go back to what >>> Stuart said about the multiple parties making the various requests. For >>> example, it is not (usually) the application deciding that the link-lay= er >>> should be Ethernet. We need to avoid the case where the applications at >>> each end request the same service components but get different protocol= s >>> and therefore have not interoperability. What that means is that the >>> mapping from service components to protocol stacks needs to be >>> deterministic on both ends. >>> >>> Mirja K=C3=BChlewind: There should be some kind of shim layer that does= some >>> kind of negotiation to make sure they can communicate. >>> >>> Dave Thaler: Okay, but the draft does not say that. >>> >>> Michael Welzl: This table may look like it proposes a mapping, but it= =E2=80=99s >>> just listing the protocols that currently exist. >>> >>> Jana Iyengar: Are we explicitly excluding non-IETF protocols? >>> >>> Aaron Falk: Yes, for this work item. We might expand the scope later. >>> >>> Kevin Fall: In this matrix UDP is defined as unicast, which surprises m= e >>> considering that all multicast work uses UDP. How does multicast fit in= to >>> this? >>> >>> Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast >>> RESTful verbs. CoAP also has congestion control, so it=E2=80=99s a tran= sport >>> protocol. >>> >>> Mirja K=C3=BChlewind: Right now we want to cover all the obvious transp= ort >>> protocols. If people want to contribute text for others, we can add >>> those. >>> >>> Aaron Falk: Andrew, is this an area you have expertise in? >>> >>> Andrew McGregor: Some. >>> >>> ** Aaron Falk: Andrew McGregor will identify a contributor to describe >>> CoAP (maybe himself). >>> >>> Brian (or Robert?) Adamson, NRL: We should solicit additions via the >>> mailing list. >>> >>> Aaron Falk: Please send text. >>> >>> Joe Hildebrand: You asked the question: Is this a viable structure? My >>> answer is: I think so. But we should start with a detailed analysis of >>> something like TCP to make sure we understand how that fits the model. >>> >>> Aaron Falk: I=E2=80=99d suggest exploring two examples so that we have = two data >>> points. Michael already volunteered to do SCTP. >>> >>> Slide 5: Who can contribute? >>> >>> Dave Thaler: I=E2=80=99m thinking of a type of protocol that=E2=80=99s = missing from the >>> list, and that=E2=80=99s things like TLS. Applications ask for stuff. P= rotocols >>> provide stuff. Applications ask for stuff like confidentiality, >>> integrity, >>> etc. Protocols like TLS and IPSEC provide confidentiality, integrity, >>> etc. >>> >>> Mirja K=C3=BChlewind: Please contribute text. >>> >>> Dave Thaler: We think in terms of layers, but security is not a layer. >>> It=E2=80=99s on the side, affecting everything. We need to include the = things on >>> the side too. >>> >>> Brian Trammell: Security is definitely an aspect >>> >>> Gorry Fairhurst: +1 >>> >>> Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComponent=E2= =80=9D? >>> >>> Gorry Fairhurst: What we want is a plan to make one of these sections >>> concrete from someone with expertise in the protocol. >>> >>> Mirja K=C3=BChlewind: Yes. >>> >>> Brian Trammell: We're asking the structure question here. >>> >>> Andrew McGregor: The structure is ugly but I can=E2=80=99t see how it c= ould be >>> better. We have to consider how you name the other endpoint. DNS name? >>> URL? >>> Something else? Should that identity be proved in some manner? How? TLS >>> certificates? HIP identity hash match. >>> >>> Mirja K=C3=BChlewind: I don=E2=80=99t need to specify how identity is p= roved. >>> >>> Andrew McGregor: You might if you only have credentials in a particular >>> form. >>> >>> Mirja K=C3=BChlewind: This restricts what the transport protocol can ch= oose. >>> >>> Joe Hildebrand: Let=E2=80=99s not debate API details until we have the = principles >>> adequately characterized. Let=E2=80=99s know what the building blocks a= re first. >>> >>> Aaron Falk: I agree that we should flesh out a couple of sections and u= se >>> that as a basis for refining the rest of the document. Who will volunte= er >>> to take on one of these sections? >>> >>> ** Kevin Fall: Open mouth, insert work. I will do UDP. >>> >>> Mirja K=C3=BChlewind: Are there no MPTCP people here? >>> >>> Aaron Falk: What about basic TCP? >>> >>> ** Mirja K=C3=BChlewind: I will do basic TCP, but it would be good to h= ave >>> other people too. >>> >>> Varun Singh: Is RTP excluded? >>> >>> Mirja K=C3=BChlewind: Will you do that? >>> >>> ** Varun Singh: I=E2=80=99ll contribute text for RTP. >>> >>> Varun Singh: Is this document on GitHub? >>> >>> Mirja K=C3=BChlewind: Gorry Fairhurst and Brian Trammell can decide tha= t. >>> >>> Brian Trammell: I can move to markdown over GitHub, no problem. >>> >>> Kevin Fall: Are the lessons we learn here going to reflected in the >>> previous document? >>> >>> Mirja K=C3=BChlewind: This document just lists what=E2=80=99s there. >>> >>> Kevin Fall: If we discover that idempotency is an important concept, ho= w >>> does that get added to the document? >>> >>> Joe Hildebrand: Finding those is the point of this exercise. >>> >>> Aaron Falk: We=E2=80=99ll give you a cookie. >>> >>> Varun Singh: It seems like we=E2=80=99re going to replicate a lot of te= xt from >>> existing RFCs. >>> >>> Aaron Falk: The goal is to take an existing protocol and identify what >>> services it is offering to the application. That=E2=80=99s what we want= to get in >>> this document. >>> >>> Mirja K=C3=BChlewind: What you as an expert for some protocol should do= is >>> describe the protocol as completely as possible. >>> >>> Dave Thaler: What are you looking for in each section? Service >>> components? >>> Protocol features? Both? >>> >>> Aaron Falk: I want the protocol components, but the way you get there i= s >>> to analyze the protocol features. >>> >>> Mirja K=C3=BChlewind: Please provide text. >>> >>> ** Dave Thaler: I volunteer to help with getting the matrix right, of >>> features vs. things that are protocols, e.g. inherent vs. optional is >>> another key thing for features. I=E2=80=99ve done such work in the past= . It=E2=80=99s >>> useful to know which things are inherent features, and which things are >>> optional features. For example, with TCP you can have keepalives or not= . >>> >>> Mirja K=C3=BChlewind: The first step is to describe the protocols. >>> >>> ** Dave Thaler: I=E2=80=99m volunteering to help with the matrix more t= han the >>> specific text, but I may be able to do some of that too. >>> >>> Jana Iyengar: Let=E2=80=99s not end up with a giant matrix and checkbox= es for >>> various features. That=E2=80=99s not useful. >>> >>> Mirja K=C3=BChlewind: There may be cases where two components do not wo= rk >>> together. >>> >>> ** Karen Nielsen: I will provide SCTP text. >>> >>> Karen Nielsen: Protocol features like ACK or NACK are not specific to >>> TCP. >>> SCTP also has ACKs. You can=E2=80=99t say that protocol features are sp= ecific to >>> one protocol. >>> >>> Mirja K=C3=BChlewind: Protocol features are specific to one protocol. >>> >>> Karen Nielsen: So SCTP ACK is different to TCP ACK. >>> >>> ** P=C3=A5l-Erik Martinsen: I will provide text for STUN >>> >>> Charles Eckel: It will be helpful to combine everything into one table. >>> >>> Mirja K=C3=BChlewind: Having a single matrix would be really nice for t= he >>> document. But the first step is to describe the protocols and extract >>> the >>> components they provide. >>> >>> Kenneth Calvert: Is one of the goals here to come out with an ontology = of >>> transport service components? >>> >>> Aaron Falk: We are trying to confine the scope to IETF protocols. A >>> complete ontology would not necessarily be useful. >>> >>> Kenneth Calvert: For this draft, before you plunge into the matrix, it >>> would be useful to define the existing components. >>> >>> Mirja K=C3=BChlewind: This is the end goal of the document. >>> >>> Brian (or Robert?) Adamson, NRL: Is there a template for a list of the >>> aspects we care about? >>> >>> Mirja K=C3=BChlewind: This is just an initial attempt. >>> >>> Brian Trammell: To Kenneth, =E2=80=9Cyes=E2=80=9D (but I am allergic to= the word >>> ontology.) >>> >>> Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2=80=99s the enti= re point >>> of >>> this working group. >>> >>> Michael Ramalho: This is a very hard problem when I think about how som= e >>> of these protocols were evolved to meet very special needs. Suppose I >>> have >>> this application that doesn=E2=80=99t want head-of-line-blocking, and m= aybe I >>> don=E2=80=99t >>> want to retransmit once or twice, and let=E2=80=99s suppose I have some= thing >>> expressive enough to convey this to the transport layer, and it can=E2= =80=99t >>> deliver this without using multiple TCP connections, and maybe I would >>> have >>> preferred DTLS. How do you express that to this layer? >>> >>> Mirja K=C3=BChlewind: The document is focussed on the simple cases firs= t. >>> >>> Pete Resnick: It would be a terrible failure if, in such situations, th= e >>> transport layer would ask the application what to do. The app doesn=E2= =80=99t >>> care >>> and doesn=E2=80=99t know. That I can pull this off with 3 TCP connectio= ns is not >>> something the app cares about. You either give the app what it asks for >>> or >>> fail. >>> >>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 >>> >>> ** 14:43 Aaron Falk called for adopting draft-fairhurst-taps- >>> transports-00 >>> as WG document. >>> Folks who read the draft: maybe 10 + >>> Significant hum in support >>> None against >>> >>> -- END >>> >>> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> >> > -- > ------------------------------------------ > Dipl.-Ing. Mirja K=C3=BChlewind > Communication Systems Group > Institute TIK, ETH Z=C3=BCrich > Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland > > Room ETZ G93 > phone: +41 44 63 26932 > email: mirja.kuehlewind@tik.ee.ethz.ch > ------------------------------------------ > --20cf307abed570c1e005097862d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ack.=C2=A0 But I like 'meddlebox' better. =C2=A0:)=

--aaron

On Wed, Dec 3, 2014 at 6:28 AM, Mirja K=C3=BChlewind = <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
Hi Aaron,

I've read the minutes but as at least my statements are all reflected c= orrectly, I didn't further response to your mail.

Thanks a lot to the minutes talkers! The minutes document the meeting very = detailed and well and therefore are very useful!

As I now writing away, please introduce two small changes:

1) I'm pretty sure I've said 'middlebox' and not 'meddl= ebox' (even though meddlenox might actually be the more accurate term i= n some cases...)

2) s/We need a term like =E2=80=9Caspect=E2=80=9D/We might need a term like= =E2=80=9Caspect=E2=80=9D/

Thanks,
Mirja



On 02.12.2014 23:45, Aaron Falk wrote:
I've seen no comments.=C2=A0 It would be Really Nice if at least one pe= rson
could read the minutes before I submit them for the proceedings.

--aaron

On Sat, Nov 22, 2014 at 4:31 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

If you spoke up in the Honolulu meeting, please review the minutes to
confirm we captured your point.=C2=A0 Thanks to Stuart Cheshire & Micha= el Welzl
for their detailed notes.

Thanks,

--aaron

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

Transport Services (TAPS)
1300-1500 HST Tuesday Afternoon Session I
Notes taken by Stuart Cheshire & Michael Welzl

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AGENDA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00. Agenda bashing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Charter Overview (Falk) - 10 mi= n
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. Terminology Review (K=C3=BChlew= ind) - 30 min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. Discussion of draft-fairhurst-t= aps-transports-00 (K=C3=BChlewind)
- 20 min
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A04. Hum: Adopt draft-fairhurst-taps= -transports-00 as wg document?
- 10 min

Action items marked with **

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94

13:05 Administrivia
<http://www.ietf.org/proceedings/91/slides/slid= es-91-taps-0.pdf>

Aaron Falk: Who was at the TAPS BoF in Toronto?=C2=A0 (Most people raised t= heir
hands.)

Aaron Falk: And who is on the mailing list?=C2=A0 (About the same.)

Aaron Falk: In today=E2=80=99s meeting we=E2=80=99ll be having a discussion= of
terminology, and then a discussion of the working group=E2=80=99s first dra= ft. We
will be looking for volunteers. The current draft is an independent
submission from two volunteers: Gorry Fairhurst and Brian Trammell, neither=
of whom could be here. We=E2=80=99ll be asking whether the people in the ro= om want
to adopt this as a Working Group document.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94

13:08 Charter Overview (Falk) =E2=80=93 10 min

Aaron Falk: The TAPS effort is focussing on the same area as the IAB Stack<= br> Evolution work, which is that there have been 20 years of transport area improvements that are largely undeployed because (i) the new transports are=
not supported in most operating systems, and (ii) the new transports may not work end-to-end on today=E2=80=99s Internet. As a result, application developers often build their own protocol on top of UDP, and sometimes that=
do that badly. The goal of this group is to enable application developers to get better performance and better behavior than they can get from TCP or=
UDP.

The first task of the working group is to define what these behaviors are that application developers want to get. We call these =E2=80=9Ctransport services=E2=80=9D. Some examples are: Reliable delivery, in-order delivery,=
confidentiality, latency. It=E2=80=99s a way for applications to express wh= at they
want from the transport layer, and to ask for combinations that aren=E2=80= =99t
currently available from TCP and UDP. The transport layer then sees what=E2= =80=99s
available and provides the best that it can, which might be HTTP over TCP.<= br> To do this we=E2=80=99re first going to examine existing IETF technologies = to see
what behaviors they provide, to collect an initial set of behaviors that we=
think might be useful.=C2=A0 We=E2=80=99re going to focus on communication = between two
endpoints, at least initially.=C2=A0 That=E2=80=99s the first document, to = submit to the
IESG next June.

Then there will be a second document which is a prioritization to select a<= br> subset of those services, and guidance how you might obtain those services<= br> using existing mechanisms. We will submit this to the IESG next December.
The third document describes how to do discovery of whether these things work, how to do fallback, how to combine the protocols and make them
available. We will submit this to the IESG in 2016.

We=E2=80=99re not going to do signaling-based QoS. We=E2=80=99re not going = to talk about
new encapsulations and tunneling. We=E2=80=99re not going to define, modify= , or
extend transport protocols. We=E2=80=99re not going to define a language-sp= ecific
API.=C2=A0 We=E2=80=99re not going to do a detailed analysis of security, b= ut we will
document the security properties of existing protocols. The emphasis of
this work is not security.

Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow
data-with-SYN, out-of-order delivery)

Aaron Falk: Yes

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94

13:15 Terminology Review (K=C3=BChlewind) =E2=80=93 30 min
<http://www.ietf.org/proceedings/91/slides/slid= es-91-taps-1.pdf>

(Mirja K=C3=BChlewind gave presentation of proposed terminology)

Dave Thaler: Why not use term =E2=80=9Cfacility=E2=80=9D instead of =E2=80= =9Cservice component=E2=80=9D?
The term =E2=80=9Cservice component=E2=80=9D usually means a piece of code.=

Stein Gjessing: =E2=80=9Ccomponent=E2=80=9D means =E2=80=9Cpart=E2=80=9D. T= hat=E2=80=99s not a =E2=80=9Cthing=E2=80=9D or =E2=80=9Cunit=E2=80=9D.

Michael Welzl: I like this a lot.

Brian Trammell: I=E2=80=99m okay with this suggestion.

Kevin Fall: Standards Track RFC 2126 defines the term =E2=80=9Ctransport se= rvices=E2=80=9D
as referred to by ISO. Don=E2=80=99t redefine terms that were already defin= ed by an
International Standard.

Mirja K=C3=BChlewind: Our definition is just a little more specific.


Kevin Fall: Reliability is not a binary property. UDPLite has partial
reliability.

Mirja K=C3=BChlewind: We discussed earlier whether we need a concept smalle= r
than a =E2=80=9Cservice component=E2=80=9D for different types of reliabili= ty. We call this
an =E2=80=9Caspect=E2=80=9D.

Kevin Fall: That term has been reserved as well.

Joe Hildebrand: Just pick Swiss German words instead, and we=E2=80=99ll all= learn
them. This way we have words that don=E2=80=99t have existing meanings in e= xisting
networking standards.

Dave Thaler: And then we could try using non-US characters in RFCs.

Mirja K=C3=BChlewind: I don=E2=80=99t care what we call it. We just have to= agree on
some terminology. Are those six descriptions the right concepts?

Ignacio Solis: Is =E2=80=9Creliability=E2=80=9D an example of a =E2=80=9Cse= rvice component=E2=80=9D?

Mirja K=C3=BChlewind: Right. A transport service today provides you with a<= br> whole package of service components, not all of which you may want. It also=
may not include a service component that you do want.

Ignacio Solis: We=E2=80=99re being bound by old thinking.

Kevin Fall: You asked what is missing here. Is it connection-oriented? Is there connection establishment, notification? Is there flow control? None of that is mentioned.

Mirja K=C3=BChlewind: These concepts are =E2=80=9Cservice components=E2=80= =9D; a specific
instantiation would be a =E2=80=9Cprotocol feature=E2=80=9D.

Aaron Falk: The first two terms are things that applications ask for. The other terms are how you provide those things.

Brian Trammell: Kevin is describing =E2=80=9Caspects=E2=80=9D. A =E2=80=9Cf= eature=E2=80=9D is a thing that
a protocol does on purpose, an =E2=80=9Caspect=E2=80=9D is something that i= t does, whether
on purpose or not.

Gorry Fairhurst: =E2=80=9CFeature=E2=80=9D is okay.

Ken Calvert: I would call state establishment =E2=80=9Cmechanism=E2=80=9D I= don=E2=80=99t know if
this will ever converge. Don=E2=80=99t conflate wire encoding with logical<= br> implementation. =E2=80=9CMechanism=E2=80=9D is wire encoding + function. Wh= y are you not
saying =E2=80=9Cfunction=E2=80=9D?

Mirja K=C3=BChlewind: For me, the terms =E2=80=9Cmechanism=E2=80=9D and =E2= =80=9Cfunction=E2=80=9D are too
abstract. What you described is still a =E2=80=9Cfeature=E2=80=9D.

Ken Calvert: I suggest not using =E2=80=9Creliability=E2=80=9D as an exampl= e because there
are too many different kinds of reliability.

Mirja K=C3=BChlewind: Do you think we need a term for concepts with smaller=
granularity than =E2=80=9Ccomponent=E2=80=9D?

Ken Calvert: For that concept, use a Swiss German word.

Mirja K=C3=BChlewind: Do we need one more term?

Ken Calvert: Maybe.

Andrew McGregor: The decomposition into pieces looks good, but I think
=E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D should be swapped= .

Mirja K=C3=BChlewind: I got this feedback already.

Jana Iyengar: Well, you just got this feedback again. I agree with Andrew.<= br> We should switch =E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D.= A software =E2=80=9Ccomponent=E2=80=9D
implements a =E2=80=9Cfeature=E2=80=9D.

Mirja K=C3=BChlewind: Switching the terms would help?

(A bunch of =E2=80=9Cyes=E2=80=9D comments from the room.)

Aaron Falk: That=E2=80=99s consensus. Move on.

Edward Lopez: We should talk about segregating transport services from
applications. Applications become independent of transport services. We
should start thinking about the rise of transport service gateways. If your=
application uses UDP and my application uses TCP then something=E2=80=99s g= ot to
traverse. Is a gateway part of a potential terminology?

Mirja K=C3=BChlewind: I think that=E2=80=99s out of scope. That would be a = meddlebox.

Aaron Falk: The use case we=E2=80=99re focussed on is two applications on t= wo
endpoints. You=E2=80=99re using =E2=80=9Capplication=E2=80=9D in a way that= =E2=80=99s confusing me.

Edward Lopez: If we=E2=80=99re talking about transport services and potenti= al
independence from applications, then when a common application is using
different transport services, what=E2=80=99s going to interchange? What=E2= =80=99s going to
aid that conversation? That=E2=80=99s what=E2=80=99s not discussed here.
Aaron Falk: We have pushed that off. The third effort of the working group<= br> to talk about an experiment with end-to-end compatibility.

Edward Lopez: Then we=E2=80=99d need transport service negotiation. Separat= ion of
application from transport services leads me to think there=E2=80=99s a ter= m
missing.

Mirja K=C3=BChlewind: What we want is not that the application is requestin= g
TCP. What we want is that the application is requesting a certain service composition, and then the layer below can make the decision to use TCP.

Ronald in 't Velt: I have not heard the term =E2=80=9Celement=E2=80=9D = yet. I agree with
Kevin Fall. Let=E2=80=99s see what=E2=80=99s already there. I have a paper = copy of ISO 8072
somewhere. I couldn=E2=80=99t find it.

Mirja K=C3=BChlewind: I=E2=80=99m sure every term has already been used som= ewhere.

Jana Iyengar: We should call them =E2=80=9CThing 1=E2=80=9D, =E2=80=9CThing= 2=E2=80=9D, =E2=80=9CThing 3=E2=80=9D, =E2=80=9CThing
4=E2=80=9D. Seriously, how would I think about TCP over IPv6 over SSL over = IPv4?

Mirja K=C3=BChlewind: That=E2=80=99s an instance. If you request that servi= ce
composition you get that stack.

Aaron Falk: Jana, what is the application asking for?

Pete Resnick: The whole idea of how discovery takes place where both
transports talk to each other and say this is the way we=E2=80=99re going t= o
communicate for this particular instance is independent right now and we=E2= =80=99ll
have to figure that out, but it=E2=80=99s not something an application care= s about.
We need to talk about feature discovery & negotiation. To address Ken= =E2=80=99s
comment, reliability and ordering should absolutely be separate components.=

Stuart Cheshire: I want to follow up to Jana=E2=80=99s point. The choice ab= out
what features to use is not decided only by the application. The choice of<= br> TCP vs UDP is decided by the application, but the choice of Ethernet vs
Wi-Fi (with or without VPN) is decided by the user. Similarly, the choice of VPN or not may be decided by the corporate administrator, not the
application, or the user.

Aaron: The application needs to express hints about what it wants. You say<= br> there are other hints. Do we need to add something to our taxonomy that
allows that information to get in?

Stuart: I don=E2=80=99t think it extends this taxonomy, it might be an orth= ogonal
dimension. User has an input, administrator has an input, application has an input. VPN is a classic example: application itself expresses no
interest in security but the user does.

Andrew McGregor: You can imagine that the API is that the application asks<= br> for a set of components, and the OS decides how to do that.

Ignacio Solis: We are PARC are building something that doesn=E2=80=99t use<= br> sockets. We have our own terminology. We call the transport layer the
=E2=80=9Cframework=E2=80=9D. We build =E2=80=9Cstacks=E2=80=9D with =E2=80= =9Ccomponents=E2=80=9D following the design of
composable stacks. The management component is missing here, especially if<= br> we are considering how this relates to middleboxes.

Mirja K=C3=BChlewind: It would be nice if you could provide some references= to
this work on the list.

Ignacio Solis: We have quite a number of things we=E2=80=99d be happy to sh= are.

Mirja K=C3=BChlewind: You give the application a whole view of what=E2=80= =99s available
at the transport layer. This work is to have an abstraction so the
application doesn=E2=80=99t need to know the details.

Ignacio Solis: We completely agree. The API hides the details of stack
assembly from the application. But the application needs to be able to pick=
the entry component. The application needs to be able to pick the API it=E2= =80=99s
going to use.

Dave Thaler: I agree with Stuart=E2=80=99s points. I see a relationship bet= ween
this and the MIF working group. The MIF working group is doing similar
things here concerning multiple provisioning domains. The application can express a set of preferences and get back information about what was
chosen.=C2=A0 When you think about the choice of saying which L3 protocol, = they
say =E2=80=9CI=E2=80=99d like to go across a secure interface=E2=80=9D and = MIF does the interface
selection logic.

Aaron Falk: Are we re-using any MIF terms or concepts?

Dave Thaler: I=E2=80=99m not aware of any any terminology collisions. Possi= bly we
may be using different terms for the same things. The MIF work is
complementary.

Aaron Falk: Who in the room is active in the MIF working group?

(Dave Thaler plus one other.)

Aaron Falk: This whole conversation reminds me of DTN.

Kevin Fall: With DTN we had to develop a pub/sub-style API. We also came to the conclusion that a third party needs an API to establish a policy on<= br> those bindings. In sockets there=E2=80=99s PF_* and AF_* to express some of= these
desires. But the application can also specify the precise protocols using IP_PROTO_*. It=E2=80=99s useful to take this choice that used to be wired i= n code
and expose it though an API to an agent. The unit of expressing things is URIs.

Brian Trammell: So this problem has always been trying to match the crappy<= br> interface above the transport to the crappy interface below. The
terminology (and taps charter for that matter) assume the lower interface can be ignored.=C2=A0 =C2=A0Although that might be impossible from a termin= ology
standpoint.=C2=A0 =C2=A0I think we probably don't want to define a term= for the
controller... but we might want to have a way to describe the things that the controller knows about the lower-interface transport aspects and path aspects.

Mirja K=C3=BChlewind: The goal for right now is to set up an initial
terminology for us to use.

Szilveszter: Don=E2=80=99t we have to define how to choose a protocol? Is i= t in
TAPS scope to say how we compose a transport? Isn=E2=80=99t it just an inte= rface
towards a transport?

Aaron Falk: That is a question about the working group=E2=80=99s scope. The= second
document is to pick a subset of all the things an application could ask
for. Right now we=E2=80=99re trying to figure out what those behaviors are.=

Toerless Eckert: Not all of the components here are things that we would traditionally call =E2=80=9Ctransport=E2=80=9D. Some of the components are = in INT area.
E.g. what about name resolution?

Mirja K=C3=BChlewind: I believe name resolution is not a component. It=E2= =80=99s a
service. This is just a first step. We can still change the terms.

Andrew McGregor: We want diagnostic tools (ping, traceroute, etc.) to be using the same APIs as applications.

Mirja K=C3=BChlewind: Let=E2=80=99s do the first step first.

Andrew McGregor: Yes, but diagnostic tools require the ability to specify an exact stack in order to be able to generate the right sort of packet.
Aaron Falk: That=E2=80=99s pretty clearly out of scope for the group. The g= oal
here is to make things easier for application developers.

Andrew McGregor: Is =E2=80=9Cping=E2=80=9D an application?

Mirja K=C3=BChlewind: This should be hidden from the application.

Andrew McGregor: The =E2=80=9Cping=E2=80=9D program is an application?

Aaron Falk: No, it=E2=80=99s a utility, which is why it=E2=80=99s out of sc= ope.

Michael Welzl: I remember from the BoF there was consensus that we should have some kind of determinism to flag to provide repeatability for testing.=

Jana Iyengar: What Andrew is suggesting would be good. We need better
tools. Without deterministic unique composition, how can you have
interoperability?

Mirja K=C3=BChlewind: For interoperability we come up with a new shim layer= .
This is what we want to hide from the application.

Pete Resnick: Discussion of ping, etc, implicitly assumes a whole lot of layer violations. This working group has =E2=80=9Ctransport=E2=80=9D in the= name. Ping uses
ICMP. ICMP is not in the transport layer. To Jana=E2=80=99s point, there=E2= =80=99s going to
have to be some sort of rendezvous/discovery. Once an application requests<= br> a certain set of components, how the system establishes talking to the
other side is just something for the lower layers to implement.

Joe Hildebrand: Let=E2=80=99s agree what the components are before we debat= e how
they=E2=80=99re negotiated.

Andrew McGregor: Ping was a bad example. There=E2=80=99s a python library c= alled
=E2=80=9Cscapy=E2=80=9D that lets you specify a bunch of properties and lea= ve the rest
unspecified and it will try and make it work. From incomplete information it fills in the gaps to make something sensible. This is a practical
example of something that=E2=80=99s already out there.

Brian Trammell: The factoring of this terminology, if not the words,
support _everything_ we're talking about here. you can ask for a compon= ent,
you can ask for a composition, you can ask for a protocol instance. What it=
doesn't support describing yet is getting info up from the lower layer.=

Kevin Fall: Identification of the endpoint gives me some concern. TCP has concepts like ports. Semantics are associated with that. The style of
naming is relevant.

Mirja K=C3=BChlewind: You could have a component =E2=80=9CI want to transmi= t web
traffic=E2=80=9D and then naturally the first thing the transport protocol = would do
is open a connection on port 80. If that doesn=E2=80=99t work it could do s= omething
else.

Kevin Fall: That=E2=80=99s high level example compared to components like =E2=80=9Creliability=E2=80=9D.

Mirja K=C3=BChlewind: This is not for sure. This is the next step. We have = to
find out what=E2=80=99s out there and how we name these things.

Kevin Fall: If these high level examples are what you=E2=80=99re talking ab= out
then high level frameworks well above the sockets layer are relevant.

Mirja K=C3=BChlewind: I just don=E2=80=99t know.

Mirja K=C3=BChlewind: My conclusions from discussion:=C2=A0 We=E2=80=99ll s= witch the terms
=E2=80=9Ccomponent=E2=80=9D and =E2=80=9Cfeature=E2=80=9D. This is a good s= tarting point. We can have more
discussions and change things if necessary. We need a term like =E2=80=9Cas= pect=E2=80=9D
which is even a lower granularity than =E2=80=9Ccomponent=E2=80=9D.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94

14:07 Discussion of draft-fairhurst-taps-transports-00
<http://www.ietf.org/proceedings/91/slides/slid= es-91-taps-4.pdf>

Authors Gorry Fairhurst and Brian Trammell. Presented by Mirja K=C3=BChlewi= nd.

Goal is to survey existing transport protocols and extract the common
components they have, and the ways they implement those.

Slide 4: Relationship between transport protocols and service component

Joe Hildebrand: There are other IETF areas who should be included (like
RAI) that are not in the transport area but offer transport-like
facilities. For example websocket.

Mirja K=C3=BChlewind: As long as they are IETF protocols they are in scope.=

Dave Thaler: I strongly agree with Joe. Now we=E2=80=99re talking about
architecture, how protocols map to services. I want to go back to what
Stuart said about the multiple parties making the various requests. For
example, it is not (usually) the application deciding that the link-layer should be Ethernet. We need to avoid the case where the applications at
each end request the same service components but get different protocols and therefore have not interoperability. What that means is that the
mapping from service components to protocol stacks needs to be
deterministic on both ends.

Mirja K=C3=BChlewind: There should be some kind of shim layer that does som= e
kind of negotiation to make sure they can communicate.

Dave Thaler: Okay, but the draft does not say that.

Michael Welzl: This table may look like it proposes a mapping, but it=E2=80= =99s
just listing the protocols that currently exist.

Jana Iyengar: Are we explicitly excluding non-IETF protocols?

Aaron Falk: Yes, for this work item. We might expand the scope later.

Kevin Fall: In this matrix UDP is defined as unicast, which surprises me considering that all multicast work uses UDP. How does multicast fit into this?

Andrew McGregor: Are CoAP, SPDY, HTTP/2 included? CoAP has multicast
RESTful verbs. CoAP also has congestion control, so it=E2=80=99s a transpor= t
protocol.

Mirja K=C3=BChlewind: Right now we want to cover all the obvious transport<= br> protocols. If people want to contribute text for others, we can add those.<= br>
Aaron Falk: Andrew, is this an area you have expertise in?

Andrew McGregor: Some.

** Aaron Falk: Andrew McGregor will identify a contributor to describe
CoAP (maybe himself).

Brian (or Robert?) Adamson, NRL: We should solicit additions via the
mailing list.

Aaron Falk: Please send text.

Joe Hildebrand: You asked the question: Is this a viable structure? My
answer is: I think so. But we should start with a detailed analysis of
something like TCP to make sure we understand how that fits the model.

Aaron Falk: I=E2=80=99d suggest exploring two examples so that we have two = data
points. Michael already volunteered to do SCTP.

Slide 5: Who can contribute?

Dave Thaler: I=E2=80=99m thinking of a type of protocol that=E2=80=99s miss= ing from the
list, and that=E2=80=99s things like TLS. Applications ask for stuff. Proto= cols
provide stuff. Applications ask for stuff like confidentiality, integrity,<= br> etc. Protocols like TLS and IPSEC provide confidentiality, integrity, etc.<= br>
Mirja K=C3=BChlewind: Please contribute text.

Dave Thaler: We think in terms of layers, but security is not a layer.
It=E2=80=99s on the side, affecting everything. We need to include the thin= gs on
the side too.

Brian Trammell: Security is definitely an aspect

Gorry Fairhurst: +1

Mirja K=C3=BChlewind: =E2=80=9CAspect=E2=80=9D or =E2=80=9CComponent=E2=80= =9D?

Gorry Fairhurst: What we want is a plan to make one of these sections
concrete from someone with expertise in the protocol.

Mirja K=C3=BChlewind: Yes.

Brian Trammell: We're asking the structure question here.

Andrew McGregor: The structure is ugly but I can=E2=80=99t see how it could= be
better. We have to consider how you name the other endpoint. DNS name? URL?=
Something else? Should that identity be proved in some manner? How? TLS
certificates? HIP identity hash match.

Mirja K=C3=BChlewind: I don=E2=80=99t need to specify how identity is prove= d.

Andrew McGregor: You might if you only have credentials in a particular
form.

Mirja K=C3=BChlewind: This restricts what the transport protocol can choose= .

Joe Hildebrand: Let=E2=80=99s not debate API details until we have the prin= ciples
adequately characterized. Let=E2=80=99s know what the building blocks are f= irst.

Aaron Falk: I agree that we should flesh out a couple of sections and use that as a basis for refining the rest of the document. Who will volunteer to take on one of these sections?

** Kevin Fall: Open mouth, insert work. I will do UDP.

Mirja K=C3=BChlewind: Are there no MPTCP people here?

Aaron Falk: What about basic TCP?

** Mirja K=C3=BChlewind: I will do basic TCP, but it would be good to have<= br> other people too.

Varun Singh: Is RTP excluded?

Mirja K=C3=BChlewind: Will you do that?

** Varun Singh: I=E2=80=99ll contribute text for RTP.

Varun Singh: Is this document on GitHub?

Mirja K=C3=BChlewind: Gorry Fairhurst and Brian Trammell can decide that.
Brian Trammell: I can move to markdown over GitHub, no problem.

Kevin Fall: Are the lessons we learn here going to reflected in the
previous document?

Mirja K=C3=BChlewind: This document just lists what=E2=80=99s there.

Kevin Fall: If we discover that idempotency is an important concept, how does that get added to the document?

Joe Hildebrand: Finding those is the point of this exercise.

Aaron Falk: We=E2=80=99ll give you a cookie.

Varun Singh: It seems like we=E2=80=99re going to replicate a lot of text f= rom
existing RFCs.

Aaron Falk: The goal is to take an existing protocol and identify what
services it is offering to the application. That=E2=80=99s what we want to = get in
this document.

Mirja K=C3=BChlewind: What you as an expert for some protocol should do is<= br> describe the protocol as completely as possible.

Dave Thaler: What are you looking for in each section? Service components?<= br> Protocol features? Both?

Aaron Falk: I want the protocol components, but the way you get there is to analyze the protocol features.

Mirja K=C3=BChlewind: Please provide text.

** Dave Thaler: I volunteer to help with getting the matrix right, of
features vs. things that are protocols, e.g. inherent vs. optional is
another key thing for features. I=E2=80=99ve done such work in the past. It= =E2=80=99s
useful to know which things are inherent features, and which things are
optional features. For example, with TCP you can have keepalives or not.
Mirja K=C3=BChlewind: The first step is to describe the protocols.

** Dave Thaler: I=E2=80=99m volunteering to help with the matrix more than = the
specific text, but I may be able to do some of that too.

Jana Iyengar: Let=E2=80=99s not end up with a giant matrix and checkboxes f= or
various features. That=E2=80=99s not useful.

Mirja K=C3=BChlewind: There may be cases where two components do not work together.

** Karen Nielsen: I will provide SCTP text.

Karen Nielsen: Protocol features like ACK or NACK are not specific to TCP.<= br> SCTP also has ACKs. You can=E2=80=99t say that protocol features are specif= ic to
one protocol.

Mirja K=C3=BChlewind: Protocol features are specific to one protocol.

Karen Nielsen: So SCTP ACK is different to TCP ACK.

** P=C3=A5l-Erik Martinsen: I will provide text for STUN

Charles Eckel: It will be helpful to combine everything into one table.

Mirja K=C3=BChlewind: Having a single matrix would be really nice for the document.=C2=A0 But the first step is to describe the protocols and extract= the
components they provide.

Kenneth Calvert: Is one of the goals here to come out with an ontology of transport service components?

Aaron Falk: We are trying to confine the scope to IETF protocols. A
complete ontology would not necessarily be useful.

Kenneth Calvert: For this draft, before you plunge into the matrix, it
would be useful to define the existing components.

Mirja K=C3=BChlewind: This is the end goal of the document.

Brian (or Robert?) Adamson, NRL: Is there a template for a list of the
aspects we care about?

Mirja K=C3=BChlewind: This is just an initial attempt.

Brian Trammell: To Kenneth, =E2=80=9Cyes=E2=80=9D (but I am allergic to the= word ontology.)

Gorry Fairhurst: To Brian (or Robert?) Adamson: That=E2=80=99s the entire p= oint of
this working group.

Michael Ramalho: This is a very hard problem when I think about how some of these protocols were evolved to meet very special needs. Suppose I have<= br> this application that doesn=E2=80=99t want head-of-line-blocking, and maybe= I don=E2=80=99t
want to retransmit once or twice, and let=E2=80=99s suppose I have somethin= g
expressive enough to convey this to the transport layer, and it can=E2=80= =99t
deliver this without using multiple TCP connections, and maybe I would have=
preferred DTLS. How do you express that to this layer?

Mirja K=C3=BChlewind: The document is focussed on the simple cases first.
Pete Resnick: It would be a terrible failure if, in such situations, the transport layer would ask the application what to do. The app doesn=E2=80= =99t care
and doesn=E2=80=99t know. That I can pull this off with 3 TCP connections i= s not
something the app cares about. You either give the app what it asks for or<= br> fail.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94

** 14:43 Aaron Falk called for adopting draft-fairhurst-taps-transpo= rts-00
as WG document.
Folks who read the draft: maybe 10 +
Significant hum in support
None against

-- END




_______________________________________________
Taps mailing list
Taps@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/taps


--
------------------------------------------
Dipl.-Ing. Mirja K=C3=BChlewind
Communication Systems Group
Institute TIK, ETH Z=C3=BCrich
Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland

Room ETZ G93
phone: +41 44 63 26932
email: mirja.kuehlewind@tik.ee.ethz.ch
------------------------------------------

--20cf307abed570c1e005097862d1-- From nobody Tue Dec 16 08:28:26 2014 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 1FDE91A1B6C; Tue, 16 Dec 2014 06:22:06 -0800 (PST) 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 47X3tOR2AWlW; Tue, 16 Dec 2014 06:22:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D631A1B79; Tue, 16 Dec 2014 06:21:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141216142139.3408.90371.idtracker@ietfa.amsl.com> Date: Tue, 16 Dec 2014 06:21:39 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/tKtyd2V_KzJzGuL7iGs98RkuUiE X-Mailman-Approved-At: Tue, 16 Dec 2014 08:28:14 -0800 Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-00.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, 16 Dec 2014 14:22:08 -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 Filename : draft-ietf-taps-transports-00.txt Pages : 7 Date : 2014-12-15 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: http://tools.ietf.org/html/draft-ietf-taps-transports-00 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 Dec 16 13:21:35 2014 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 B34A11A884F for ; Tue, 16 Dec 2014 13:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 OWR948gxO4zP for ; Tue, 16 Dec 2014 13:21:26 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AF01A884D for ; Tue, 16 Dec 2014 13:21:25 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id im6so6824389vcb.11 for ; Tue, 16 Dec 2014 13:21:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N59MsIUiK2iBXe2W+K8W+z3rPot7ka4b17f42xbs0A4=; b=V9s57Hnsfskt9e7fg9sKaDiT9F7+2AH3W6RPEMwH1t+QFpzURkDN521yyzTD+7+M7B P4WGQwn0JERGKHn2qUX5nhUu5srNA64D4d2EHFkpE/+2HYLikURPZPy/f15N9DEC61oE zjo4qhep5uRw3OgT9/DW2XhHtLPw2kA5I8B6u01glZTWQmx5dxfLGmJgY7caIqDqVu2c oXSvkc8KVF/14a5zXdGelKw6fnx+eJrr1UqCgas2vDUnUcLPPGT8aQGeYo5iru35lXpL izN6xNXy4awOczAUlmRKHdVxGl69uEbbBXQrzM3iV7OJc4elHeQRcnCgnZvUyfO0hH8W ILYA== MIME-Version: 1.0 X-Received: by 10.52.27.237 with SMTP id w13mr19889401vdg.68.1418764884797; Tue, 16 Dec 2014 13:21:24 -0800 (PST) Received: by 10.52.28.174 with HTTP; Tue, 16 Dec 2014 13:21:24 -0800 (PST) Date: Tue, 16 Dec 2014 16:21:24 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=20cf307abed5fa71d2050a5bf009 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oo94mw0ev2mm1C2_oH2xkR6lqG4 Subject: [Taps] IETF-92 hotel is posted 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, 16 Dec 2014 21:21:30 -0000 --20cf307abed5fa71d2050a5bf009 Content-Type: text/plain; charset=UTF-8 FYI: http://www.ietf.org/meeting/92/hotel.html --20cf307abed5fa71d2050a5bf009 Content-Type: text/html; charset=UTF-8 --20cf307abed5fa71d2050a5bf009-- From nobody Thu Dec 18 06:07:04 2014 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 406951A8A0D; Thu, 18 Dec 2014 06:06:59 -0800 (PST) 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 0zCTcjogFFmu; Thu, 18 Dec 2014 06:06:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5C61A8A04; Thu, 18 Dec 2014 06:06:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 06:06:55 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/sgyCc6T7e_NiQg3TnuOUjsX7Skk Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-01.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: Thu, 18 Dec 2014 14:06:59 -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-01.txt Pages : 15 Date : 2014-12-18 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: http://tools.ietf.org/html/draft-ietf-taps-transports-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01 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 Thu Dec 18 06:44:56 2014 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 C187F1A89F1 for ; Thu, 18 Dec 2014 06:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 oVHKYb01v28d for ; Thu, 18 Dec 2014 06:44:53 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 783641A1B28 for ; Thu, 18 Dec 2014 06:44:53 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::108d] (unknown [IPv6:2001:67c:10ec:2a49:8000::108d]) by trammell.ch (Postfix) with ESMTPSA id 95EBC1A0403 for ; Thu, 18 Dec 2014 15:44:52 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> Date: Thu, 18 Dec 2014 15:44:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> To: taps WG X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/HRI0EmLTt4dbOUgnF8i2BqHPyfk Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 18 Dec 2014 14:44:55 -0000 Greetings, all, We've posted a -01 rev of the TAPS transports document. We believe that = the format and level of detail for the TCP section is about what we're = targeting for each of the other sections, but this is still open to = discussion. The document also includes at least a little text on most of = the transport protocols identified in the -00 revision. Welcome also to = Mirja K=C3=BChlewind, added as an additional editor. If there are any additional transport protocols we're missing, or other = comments on document structure, please send them to the list. Document source is available (with a kramdown-rfc2629-based workflow) at = https://github.com/britram/taps-transports. Feel free to send pull = requests against the markdown, or XML/text diffs to the editors, for = contributions to sections of the document. Cheers, and merry Christmas, Brian > On 18 Dec 2014, at 15:06, 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-01.txt > Pages : 15 > Date : 2014-12-18 >=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: > http://tools.ietf.org/html/draft-ietf-taps-transports-01 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-01 >=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 From nobody Thu Dec 18 13:37:46 2014 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 4008A1A702E for ; Thu, 18 Dec 2014 13:37:43 -0800 (PST) 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 5lFDjxGrgcKr for ; Thu, 18 Dec 2014 13:37:39 -0800 (PST) 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 C6B7E1A8A3B for ; Thu, 18 Dec 2014 13:37:38 -0800 (PST) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Y1ilM-0007QV-SS for taps@ietf.org; Thu, 18 Dec 2014 22:37:36 +0100 Received: from mwelzl-laptop.caia.swin.edu.au ([136.186.229.136]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1Y1ilM-0001XC-2z for taps@ietf.org; Thu, 18 Dec 2014 22:37:36 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: Date: Fri, 19 Dec 2014 08:37:32 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> To: taps WG X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 7 sum rcpts/h 17 sum msgs/h 7 total rcpts 24066 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A53FAEE50A5301F3B83002D9858A0BFB6DFECEE8 X-UiO-SPAM-Test: remote_host: 136.186.229.136 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 380 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/3cdeOmFVm8zPRdTfRirX7XnUiUc Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 18 Dec 2014 21:37:43 -0000 Hi, Thanks for this update! A question: > We've posted a -01 rev of the TAPS transports document. We believe = that the format and level of detail for the TCP section is about what = we're targeting for each of the other sections, but this is still open = to discussion. Why is Nagle not a part of the protocol components and interface = description? It=E2=80=99s mentioned in the protocol description above, = and it=E2=80=99s something that an application decides. Cheers, Michael From nobody Thu Dec 18 15:40:35 2014 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 27F0C1A913B for ; Thu, 18 Dec 2014 15:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tx4nBZ9C8Xjr for ; Thu, 18 Dec 2014 15:40:32 -0800 (PST) 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 578961A87AD for ; Thu, 18 Dec 2014 15:40:32 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id sBINdxMr024022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Dec 2014 15:39:59 -0800 (PST) Message-ID: <549365CF.7020604@isi.edu> Date: Thu, 18 Dec 2014 15:39:59 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian Trammell , taps WG References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/taps/FA9Py399dKlziJ-qwHc1oePkP8w Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 18 Dec 2014 23:40:34 -0000 Some feedback below. Although I focus on some TCP and UDP specifics, some observations apply to other transports as well. Joe ----- 3.1.1 TCP segments fit into IP packets, but those packets are not necessarily constrained to fit into a lower-layer frame. They can be source fragmented. PathMTU discovery is supported by TCP but may be inhibited by network conditions (ICMP blocking); PLMTUD is supposed to be supported as well. 3.1.2 TCP's API is mostly specified in RFC793. What's missing are how options and parameters are managed. 3.1.3 TCP provides a byte-ordered reliable stream. How that is delivered - e.g., by segments - is irrelevant, if only because TCP can change those segment boundaries during operation (e.g., with path MTU updates). this section should also mention flow control - TCP doesn't dump data on the floor if the receiver can't process it fast enough (vs. UDP) additionally, the ports ought to be discussed in more detail. ports in the SYN have a different meaning that ports in other segments. The SYN destination port indicates the receiving ` service, which typically involves BOTH demuxing to a process within a host AND indicating the format of the stream. Ports there and in all other segments are only demultiplexing indicators. 3.4.1 UDP doesn't fragment packets into IP packets; it maps to a single IP packet, which itself may be fragmented. The IP fragments are what are limited by the lower-layer frames. Because UDP is connectionless, if you're going to talk about properties of sequences of messages, you need to explain what that sequence is - i.e., you need to define what it means to have a UDP flow, and only such flows are subject to flow/congestion control, PMTUD, etc. 3.4.2 RFC768 describes an API for UDP. As with TCP, it leaves out options and parameters. 3.4.3 should include port demuxing here too, with the same caveats as noted above for TCP (i.e., ports for messages have multiple meanings) ---- On 12/18/2014 6:44 AM, Brian Trammell wrote: > Greetings, all, > > We've posted a -01 rev of the TAPS transports document. We believe that the format and level of detail for the TCP section is about what we're targeting for each of the other sections, but this is still open to discussion. The document also includes at least a little text on most of the transport protocols identified in the -00 revision. Welcome also to Mirja Kühlewind, added as an additional editor. > > If there are any additional transport protocols we're missing, or other comments on document structure, please send them to the list. > > Document source is available (with a kramdown-rfc2629-based workflow) at https://github.com/britram/taps-transports. Feel free to send pull requests against the markdown, or XML/text diffs to the editors, for contributions to sections of the document. > > Cheers, and merry Christmas, > > Brian > >> On 18 Dec 2014, at 15:06, 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-01.txt >> Pages : 15 >> Date : 2014-12-18 >> >> 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: >> http://tools.ietf.org/html/draft-ietf-taps-transports-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01 >> >> >> 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 > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Thu Dec 18 23:06:47 2014 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 A991F1AC40B for ; Thu, 18 Dec 2014 23:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 iXghIFm2yl3k for ; Thu, 18 Dec 2014 23:06:36 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 055E61AC3DF for ; Thu, 18 Dec 2014 23:06:35 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 33) id DB1612B4495; Fri, 19 Dec 2014 07:06:33 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by spey.erg.abdn.ac.uk with HTTP; Fri, 19 Dec 2014 07:06:33 -0000 Message-ID: In-Reply-To: <549365CF.7020604@isi.edu> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <549365CF.7020604@isi.edu> Date: Fri, 19 Dec 2014 07:06:33 -0000 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/iJDab8ItwRa5sTJ_ys_arX6A6uQ Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt (UDP) 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, 19 Dec 2014 07:06:42 -0000 Thanks Joe, This is very much a first attempt to quickly put a little substance on the framework, to see if it can work and gather thoughts. Your read through is helpful I'll reply just to the UDP feedback below: > Some feedback below. Although I focus on some TCP and UDP specifics, > some observations apply to other transports as well. > > Joe > > ----- > > 3.4.1 > UDP doesn't fragment packets into IP packets; it maps to > a single IP packet, which itself may be fragmented. The > IP fragments are what are limited by the lower-layer > frames. > Sure, that's a better way to say this, > Because UDP is connectionless, if you're going to talk > about properties of sequences of messages, you need to > explain what that sequence is - i.e., you need to > define what it means to have a UDP flow, and only > such flows are subject to flow/congestion control, > PMTUD, etc. > I get it, we can say that applications send a sequence of messages and that these constitute a UDP flow, that can then implement these mechanisms as an upper layer protocol. > > 3.4.2 > RFC768 describes an API for UDP. As with TCP, > it leaves out options and parameters. > I'd say "describes" is perhaps over stating this - but I accept we do need to acknowledge this REF, and probably also refer to other standards -- do you have ideas of what specific ones we should cite?, For UDP, I thought of also adding: Many operating systems also allow a UDP socket to be connected, i.e., to bind a UDP socket to a specific pair of addresses and ports. This is similar to the corresponding TCP sockets API functionality. However, for UDP, this is only a local operation that serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports [RFC5405]. > 3.4.3 > should include port demuxing here too, with the same > caveats as noted above for TCP (i.e., ports for > messages have multiple meanings) > Yes. I'm not sure how this relates to TAPS, are you thinking that we should say "choice of port" has a bearing on whether a packet is transmitted along an end to end path by the network? Gorry > ---- > > > On 12/18/2014 6:44 AM, Brian Trammell wrote: >> Greetings, all, >> >> We've posted a -01 rev of the TAPS transports document. We believe that >> the format and level of detail for the TCP section is about what we're >> targeting for each of the other sections, but this is still open to >> discussion. The document also includes at least a little text on most of >> the transport protocols identified in the -00 revision. Welcome also to >> Mirja Kühlewind, added as an additional editor. >> >> If there are any additional transport protocols we're missing, or other >> comments on document structure, please send them to the list. >> >> Document source is available (with a kramdown-rfc2629-based workflow) at >> https://github.com/britram/taps-transports. Feel free to send pull >> requests against the markdown, or XML/text diffs to the editors, for >> contributions to sections of the document. >> >> Cheers, and merry Christmas, >> >> Brian >> >>> On 18 Dec 2014, at 15:06, 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-01.txt >>> Pages : 15 >>> Date : 2014-12-18 >>> >>> 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: >>> http://tools.ietf.org/html/draft-ietf-taps-transports-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01 >>> >>> >>> 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 >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Fri Dec 19 01:05:35 2014 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 116861A1EEE for ; Fri, 19 Dec 2014 01:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 9gPM52z9B5cn for ; Fri, 19 Dec 2014 01:05:28 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 59AAD1A6EE0 for ; Fri, 19 Dec 2014 01:05:25 -0800 (PST) Received: from [10.0.27.115] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 19B081A09D9; Fri, 19 Dec 2014 10:05:24 +0100 (CET) X-Apple-Mail-Remote-Attachments: YES In-Reply-To: <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> X-Apple-Mail-Signature: X-Uniform-Type-Identifier: com.apple.mail-draft Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Apple-Base-Url: x-msg://2/ X-Universally-Unique-Identifier: 7CF34A74-F645-4C87-9531-5B66B8B50CF2 Date: Fri, 19 Dec 2014 10:05:23 +0100 Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (12B440) Message-Id: <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> X-Apple-Auto-Saved: 1 From: Brian Trammell References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> To: Michael Welzl X-Apple-Mail-Plain-Text-Draft: yes Content-Type: text/plain; charset=utf-8 X-Apple-Windows-Friendly: 1 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/w0QZ8wUsjRbvG7FAxNTNSFVzK98 Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 09:05:32 -0000 > On 18 Dec 2014, at 22:37, Michael Welzl wrote: >=20 > Hi, >=20 > Thanks for this update! >=20 > A question: >=20 >> We've posted a -01 rev of the TAPS transports document. We believe that t= he format and level of detail for the TCP section is about what we're target= ing for each of the other sections, but this is still open to discussion. >=20 > Why is Nagle not a part of the protocol components and interface descripti= on? It=E2=80=99s mentioned in the protocol description above, and it=E2=80=99= s something that an application decides. Simple omission. Should we make an attempt to give this (as a component) a generic name? "Sel= ectable sender side buffering"? Or can we just call it simply "Nagle"? Thanks, cheers, Brian > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 19 01:31:40 2014 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 4B6541A1BDE for ; Fri, 19 Dec 2014 01:31:39 -0800 (PST) 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 P7kn_h-bCKm1 for ; Fri, 19 Dec 2014 01:31:37 -0800 (PST) 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 DB97D1A0120 for ; Fri, 19 Dec 2014 01:31:36 -0800 (PST) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Y1tuJ-0000Uk-5C; Fri, 19 Dec 2014 10:31:35 +0100 Received: from cpe-137-147-69-158.lnse7.lon.bigpond.net.au ([137.147.69.158] helo=valkyrie.bigpond) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1Y1tuI-0004aD-5k; Fri, 19 Dec 2014 10:31:35 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> Date: Fri, 19 Dec 2014 20:29:52 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 24096 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 30E6E579BC1DD541BC8D74A41D985985C667DE5C X-UiO-SPAM-Test: remote_host: 137.147.69.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 63 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/PT8tUpkiNl2u3CYBJrr-FsdwID4 Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 09:31:39 -0000 > On 19. des. 2014, at 20.05, Brian Trammell wrote: >=20 >=20 >> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >>=20 >> Hi, >>=20 >> Thanks for this update! >>=20 >> A question: >>=20 >>> We've posted a -01 rev of the TAPS transports document. We believe = that the format and level of detail for the TCP section is about what = we're targeting for each of the other sections, but this is still open = to discussion. >>=20 >> Why is Nagle not a part of the protocol components and interface = description? It=E2=80=99s mentioned in the protocol description above, = and it=E2=80=99s something that an application decides. >=20 > Simple omission. >=20 > Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. Cheers, Michael From nobody Fri Dec 19 01:36:12 2014 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 E8B841A6F01 for ; Fri, 19 Dec 2014 01:36:10 -0800 (PST) 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 lSzkDyuXx3k3 for ; Fri, 19 Dec 2014 01:36:09 -0800 (PST) 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 D9A0E1A6F15 for ; Fri, 19 Dec 2014 01:36:08 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Y1tyh-0001Jk-B0; Fri, 19 Dec 2014 10:36:07 +0100 Received: from cpe-137-147-69-158.lnse7.lon.bigpond.net.au ([137.147.69.158] helo=valkyrie.bigpond) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Y1tya-000329-JD; Fri, 19 Dec 2014 10:36:07 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: Date: Fri, 19 Dec 2014 20:35:43 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7AB27793-34EE-4256-BF14-6967F5B3E08F@ifi.uio.no> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 24098 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 1D4E154692DA43F29B00B44B168428D1F347CE76 X-UiO-SPAM-Test: remote_host: 137.147.69.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 64 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/18HwQdxB0iUDQ_rGY64YoQcZ3CU Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 09:36:11 -0000 > On 19. des. 2014, at 20.29, Michael Welzl wrote: >=20 >=20 >> On 19. des. 2014, at 20.05, Brian Trammell wrote: >>=20 >>=20 >>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >>>=20 >>> Hi, >>>=20 >>> Thanks for this update! >>>=20 >>> A question: >>>=20 >>>> We've posted a -01 rev of the TAPS transports document. We believe = that the format and level of detail for the TCP section is about what = we're targeting for each of the other sections, but this is still open = to discussion. >>>=20 >>> Why is Nagle not a part of the protocol components and interface = description? It=E2=80=99s mentioned in the protocol description above, = and it=E2=80=99s something that an application decides. >>=20 >> Simple omission. >>=20 >> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >=20 > In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. Very sorry for writing a separate email! But having this open made me = notice another one: "error detection" (or "integrity check", whatever = you prefer). There's a checksum, it can't be disabled, it's covering the = full data. Different from some other protocols. And another: flow control. Mentioned in the text, but should be a = component because the feature that it implements is meaningful to an = application (if there's no flow control, you may have to take care of it = yourself). Cheers, Michael From nobody Fri Dec 19 06:13:55 2014 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 6FD691A00E2 for ; Fri, 19 Dec 2014 06:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 xMq_08_ggq5q for ; Fri, 19 Dec 2014 06:13:49 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DB96F1A1A99 for ; Fri, 19 Dec 2014 06:13:48 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::ce] (unknown [IPv6:2001:67c:10ec:2a49:8000::ce]) by trammell.ch (Postfix) with ESMTPSA id D0C9A1A02B5; Fri, 19 Dec 2014 15:13:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: Date: Fri, 19 Dec 2014 15:13:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/1SBx7HNYjwo0MFkdj5mGkaos4SI Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 14:13:51 -0000 hi Michael, > On 19 Dec 2014, at 10:29, Michael Welzl wrote: >=20 >=20 >> On 19. des. 2014, at 20.05, Brian Trammell wrote: >>=20 >>=20 >>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >>>=20 >>> Hi, >>>=20 >>> Thanks for this update! >>>=20 >>> A question: >>>=20 >>>> We've posted a -01 rev of the TAPS transports document. We believe = that the format and level of detail for the TCP section is about what = we're targeting for each of the other sections, but this is still open = to discussion. >>>=20 >>> Why is Nagle not a part of the protocol components and interface = description? It=E2=80=99s mentioned in the protocol description above, = and it=E2=80=99s something that an application decides. >>=20 >> Simple omission. >>=20 >> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >=20 > In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. So I'd argue that (1) this isn't *exactly* the same thing, as the = interface to SOCK_SEQPACKET has application PDU preservation as an = explicit part of the API contract, while SOCK_STREAM does not, but (2) = that at the protocol level it might as well be, so "bundling" is exactly = the right word. How about "sender segment bundling" for TCP? Thanks, cheers, Brian From nobody Fri Dec 19 06:14:56 2014 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 0E6CB1A88C5 for ; Fri, 19 Dec 2014 06:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 dzBU32-96INi for ; Fri, 19 Dec 2014 06:14:48 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 81F051A88A7 for ; Fri, 19 Dec 2014 06:14:45 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::ce] (unknown [IPv6:2001:67c:10ec:2a49:8000::ce]) by trammell.ch (Postfix) with ESMTPSA id F1D9C1A0856; Fri, 19 Dec 2014 15:14:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Brian Trammell In-Reply-To: <7AB27793-34EE-4256-BF14-6967F5B3E08F@ifi.uio.no> Date: Fri, 19 Dec 2014 15:14:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E6B9B22-448D-4550-8960-ABC9C44851EE@trammell.ch> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> <7AB27793-34EE-4256-BF14-6967F5B3E08F@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/t4_k8DAhaOJyjiNOobiKk4qM21Q Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 14:14:54 -0000 > On 19 Dec 2014, at 10:35, Michael Welzl wrote: >=20 >>=20 >> On 19. des. 2014, at 20.29, Michael Welzl wrote: >>=20 >>=20 >>> On 19. des. 2014, at 20.05, Brian Trammell wrote: >>>=20 >>>=20 >>>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Thanks for this update! >>>>=20 >>>> A question: >>>>=20 >>>>> We've posted a -01 rev of the TAPS transports document. We believe = that the format and level of detail for the TCP section is about what = we're targeting for each of the other sections, but this is still open = to discussion. >>>>=20 >>>> Why is Nagle not a part of the protocol components and interface = description? It=E2=80=99s mentioned in the protocol description above, = and it=E2=80=99s something that an application decides. >>>=20 >>> Simple omission. >>>=20 >>> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >>=20 >> In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. >=20 > Very sorry for writing a separate email! But having this open made me = notice another one: "error detection" (or "integrity check", whatever = you prefer). There's a checksum, it can't be disabled, it's covering the = full data. Different from some other protocols. > And another: flow control. Mentioned in the text, but should be a = component because the feature that it implements is meaningful to an = application (if there's no flow control, you may have to take care of it = yourself). Yep, both excellent points. Will add to working -02. Thanks, cheers, Brian > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 19 11:17:28 2014 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 DB7B21ACD6B for ; Fri, 19 Dec 2014 11:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 smzlSmMJq7z0 for ; Fri, 19 Dec 2014 11:17:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DE81ACD69 for ; Fri, 19 Dec 2014 11:17:20 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id sBJJH1oe002427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Dec 2014 11:17:01 -0800 (PST) Message-ID: <549479AD.7070301@isi.edu> Date: Fri, 19 Dec 2014 11:17:01 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian Trammell , taps WG References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <549365CF.7020604@isi.edu> In-Reply-To: <549365CF.7020604@isi.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Ggl82o5ay6fq9GSWsCway7leGQE Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 19:17:24 -0000 One additional point: TCP services described in 3.1.3 should also include PUSH and URG capabilities. FWIW, the specific section of RFC793 that defines the TCP interfaces - above and below - is 3.8. Joe On 12/18/2014 3:39 PM, Joe Touch wrote: > Some feedback below. Although I focus on some TCP and UDP specifics, > some observations apply to other transports as well. > > Joe > > ----- > > 3.1.1 > TCP segments fit into IP packets, but those packets are not > necessarily constrained to fit into a lower-layer frame. > They can be source fragmented. > > PathMTU discovery is supported by TCP but may be inhibited > by network conditions (ICMP blocking); PLMTUD is supposed > to be supported as well. > > 3.1.2 > TCP's API is mostly specified in RFC793. > > What's missing are how options and parameters are managed. > > 3.1.3 > TCP provides a byte-ordered reliable stream. How that > is delivered - e.g., by segments - is irrelevant, if only > because TCP can change those segment boundaries during > operation (e.g., with path MTU updates). > > this section should also mention flow control - TCP > doesn't dump data on the floor if the receiver > can't process it fast enough (vs. UDP) > > additionally, the ports ought to be discussed in more detail. > ports in the SYN have a different meaning that ports in other > segments. The SYN destination port indicates the receiving > ` service, which typically involves BOTH demuxing to a process > within a host AND indicating the format of the stream. Ports > there and in all other segments are only demultiplexing > indicators. > > 3.4.1 > UDP doesn't fragment packets into IP packets; it maps to > a single IP packet, which itself may be fragmented. The > IP fragments are what are limited by the lower-layer > frames. > > Because UDP is connectionless, if you're going to talk > about properties of sequences of messages, you need to > explain what that sequence is - i.e., you need to > define what it means to have a UDP flow, and only > such flows are subject to flow/congestion control, > PMTUD, etc. > > > 3.4.2 > RFC768 describes an API for UDP. As with TCP, > it leaves out options and parameters. > > 3.4.3 > should include port demuxing here too, with the same > caveats as noted above for TCP (i.e., ports for > messages have multiple meanings) > > ---- > > > On 12/18/2014 6:44 AM, Brian Trammell wrote: >> Greetings, all, >> >> We've posted a -01 rev of the TAPS transports document. We believe that the format and level of detail for the TCP section is about what we're targeting for each of the other sections, but this is still open to discussion. The document also includes at least a little text on most of the transport protocols identified in the -00 revision. Welcome also to Mirja Kühlewind, added as an additional editor. >> >> If there are any additional transport protocols we're missing, or other comments on document structure, please send them to the list. >> >> Document source is available (with a kramdown-rfc2629-based workflow) at https://github.com/britram/taps-transports. Feel free to send pull requests against the markdown, or XML/text diffs to the editors, for contributions to sections of the document. >> >> Cheers, and merry Christmas, >> >> Brian >> >>> On 18 Dec 2014, at 15:06, 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-01.txt >>> Pages : 15 >>> Date : 2014-12-18 >>> >>> 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: >>> http://tools.ietf.org/html/draft-ietf-taps-transports-01 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01 >>> >>> >>> 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 >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> From nobody Fri Dec 19 14:09:24 2014 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 585B61A7001 for ; Fri, 19 Dec 2014 14:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 5ON2M9ddw3bZ for ; Fri, 19 Dec 2014 14:09:19 -0800 (PST) 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 9668C1ACDC4 for ; Fri, 19 Dec 2014 14:09:09 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Y25jO-0001te-PL; Fri, 19 Dec 2014 23:09:06 +0100 Received: from cpe-137-147-69-158.lnse7.lon.bigpond.net.au ([137.147.69.158] helo=valkyrie.bigpond) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Y25jL-0006DA-RO; Fri, 19 Dec 2014 23:09:06 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_F071D579-7360-44C6-9EC3-C013C66C6361" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: Date: Sat, 20 Dec 2014 09:08:43 +1100 Message-Id: <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 9 sum msgs/h 5 total rcpts 24124 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0F765766302DA2D759B424B50A20202FED321250 X-UiO-SPAM-Test: remote_host: 137.147.69.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 80 max/h 9 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/2dPNgl5es9We9-cL1_SiVzWVIi4 Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 22:09:22 -0000 --Apple-Mail=_F071D579-7360-44C6-9EC3-C013C66C6361 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20. des. 2014, at 01.13, Brian Trammell wrote: >=20 > hi Michael, >=20 >> On 19 Dec 2014, at 10:29, Michael Welzl wrote: >>=20 >>=20 >>> On 19. des. 2014, at 20.05, Brian Trammell wrote: >>>=20 >>>=20 >>>> On 18 Dec 2014, at 22:37, Michael Welzl wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> Thanks for this update! >>>>=20 >>>> A question: >>>>=20 >>>>> We've posted a -01 rev of the TAPS transports document. We believe = that the format and level of detail for the TCP section is about what = we're targeting for each of the other sections, but this is still open = to discussion. >>>>=20 >>>> Why is Nagle not a part of the protocol components and interface = description? It=E2=80=99s mentioned in the protocol description above, = and it=E2=80=99s something that an application decides. >>>=20 >>> Simple omission. >>>=20 >>> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >>=20 >> In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. >=20 > So I'd argue that (1) this isn't *exactly* the same thing, as the = interface to SOCK_SEQPACKET has application PDU preservation as an = explicit part of the API contract, Ahh=E2=80=A6 let me see if I get this right: your point is, in terms of = the actual function, the difference is: SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, = out of which 3 may fit into a 1460-byte segment and get shipped together = after an RTT, wasting space for 110 bytes. TCP: app gives the same app PDUs into the send buffer, where they are = treated as a byte stream and a segment of 1460 bytes can be exactly = filled. If that=E2=80=99s it, then I agree, that=E2=80=99s functionally = different. > while SOCK_STREAM does not, but (2) that at the protocol level it = might as well be, so "bundling" is exactly the right word. How about = "sender segment bundling" for TCP? Ok by me, but we'll have to be careful later: when trying to unify = access to these services across protocols, the two different names for = SCTP and TCP may make it seem like they are entirely different in = functionality when in fact they are not much different indeed: TCP=E2=80=99= s Nagle operates on single bytes, SCTP=E2=80=99s app PDU bundling = operates on potentially larger blocks of a given size? What about: =E2=80=9Cdata bundling (1 byte)=E2=80=9D, as opposed to = =E2=80=9Cdata bundling (application PDU)=E2=80=9D for SCTP ? Cheers, Michael --Apple-Mail=_F071D579-7360-44C6-9EC3-C013C66C6361 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 20. des. 2014, at 01.13, Brian Trammell <ietf@trammell.ch> = wrote:

hi Michael,

On 19 Dec 2014, at = 10:29, Michael Welzl <michawe@ifi.uio.no> wrote:


On 19. = des. 2014, at 20.05, Brian Trammell <ietf@trammell.ch> = wrote:


On 18 Dec 2014, at 22:37, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

Thanks for this update!

A = question:

We've posted a -01 rev of the TAPS transports document. We = believe that the format and level of detail for the TCP section is about = what we're targeting for each of the other sections, but this is still = open to discussion.

Why is = Nagle not a part of the protocol components and interface description? = It=E2=80=99s mentioned in the protocol description above, and it=E2=80=99s= something that an application decides.

Simple omission.

Should we make = an attempt to give this (as a component) a generic name? "Selectable = sender side buffering"? Or can we just call it simply "Nagle"?

In http://heim.ifi.uio.no/michawe/research/publications/futurenet-= icc2011.pdf we took SCTP's term for the same function because we = found it more meaningful than "Nagle": Application PDU Bundling.  I = like that - it's also perhaps useful to folks to reuse terminology when = we mean the exact same thing.

So I'd argue that (1) this isn't *exactly* the = same thing, as the interface to SOCK_SEQPACKET has application PDU = preservation as an explicit part of the API contract, =

Ahh=E2=80=A6 = let me see if I get this right: your point is, in terms of the actual = function, the difference is:
SCTP: app can give app PDUs 1, 2, = 3, 4, each 450 bytes into the buffer, out of which 3 may fit into a = 1460-byte segment and get shipped together after an RTT, wasting space = for 110 bytes.
TCP: app gives the same app PDUs into the send = buffer, where they are treated as a byte stream and a segment of 1460 = bytes can be exactly filled.

If = that=E2=80=99s it, then I agree, that=E2=80=99s functionally = different.


while SOCK_STREAM does not, but (2) that at the = protocol level it might as well be, so "bundling" is exactly the right = word. How about "sender segment bundling" for TCP?

Ok by me, = but we'll have to be careful later: when trying to unify access to these = services across protocols, the two different names for SCTP and TCP may = make it seem like they are entirely different in functionality when in = fact they are not much different indeed: TCP=E2=80=99s Nagle operates on = single bytes, SCTP=E2=80=99s app PDU bundling operates on potentially = larger blocks of a given size?

What = about: =E2=80=9Cdata bundling (1 byte)=E2=80=9D, as opposed to =E2=80=9Cda= ta bundling (application PDU)=E2=80=9D  for SCTP ?


Cheers,
Michael

= --Apple-Mail=_F071D579-7360-44C6-9EC3-C013C66C6361-- From nobody Fri Dec 19 14:25:05 2014 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 22D911A8AA3 for ; Fri, 19 Dec 2014 14:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 XiB8mh6c2g9U for ; Fri, 19 Dec 2014 14:24:59 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9BE1A8A90 for ; Fri, 19 Dec 2014 14:24:59 -0800 (PST) Received: from [192.168.1.200] (p508F0193.dip0.t-ipconnect.de [80.143.1.147]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 199E11C104350; Fri, 19 Dec 2014 23:24:55 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> Date: Fri, 19 Dec 2014 23:24:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3B53D3C5-9CCD-4B3C-9530-9FA5E340AFDC@fh-muenster.de> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/_SXPKLPSjazl-IfHO9r44483XaE Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 22:25:02 -0000 On 19 Dec 2014, at 23:08, Michael Welzl wrote: >=20 >> On 20. des. 2014, at 01.13, Brian Trammell wrote: >>=20 >> hi Michael, >>=20 >>> On 19 Dec 2014, at 10:29, Michael Welzl wrote: >>>=20 >>>=20 >>>> On 19. des. 2014, at 20.05, Brian Trammell = wrote: >>>>=20 >>>>=20 >>>>> On 18 Dec 2014, at 22:37, Michael Welzl = wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Thanks for this update! >>>>>=20 >>>>> A question: >>>>>=20 >>>>>> We've posted a -01 rev of the TAPS transports document. We = believe that the format and level of detail for the TCP section is about = what we're targeting for each of the other sections, but this is still = open to discussion. >>>>>=20 >>>>> Why is Nagle not a part of the protocol components and interface = description? It=92s mentioned in the protocol description above, and = it=92s something that an application decides. >>>>=20 >>>> Simple omission. >>>>=20 >>>> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >>>=20 >>> In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. >>=20 >> So I'd argue that (1) this isn't *exactly* the same thing, as the = interface to SOCK_SEQPACKET has application PDU preservation as an = explicit part of the API contract, >=20 > Ahh=85 let me see if I get this right: your point is, in terms of the = actual function, the difference is: > SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the = buffer, out of which 3 may fit into a 1460-byte segment and get shipped = together after an RTT, wasting space for 110 bytes. I guess the 1460 are related to the IP and TCP header. For SCTP it would be=20 20 bytes for IPv4 header, 12 bytes for the SCTP common header, 16 bytes for the DATA chunk header, 450 byte payload 16 bytes for the DATA chunk header, 450 byte payload 16 bytes for the DATA chunk header, 450 byte payload This gives 1430 bytes. So 70 bytes are left. The SCTP implementation can just leave them unused = or, and that is the point I want to make, add 16 bytes for the DATA chunk header 54 bytes (the initial 54 bytes of the fourth 450 bytes user message) Then the frame is completely used. > TCP: app gives the same app PDUs into the send buffer, where they are = treated as a byte stream and a segment of 1460 bytes can be exactly = filled. >=20 > If that=92s it, then I agree, that=92s functionally different. >=20 >=20 >> while SOCK_STREAM does not, but (2) that at the protocol level it = might as well be, so "bundling" is exactly the right word. How about = "sender segment bundling" for TCP? >=20 > Ok by me, but we'll have to be careful later: when trying to unify = access to these services across protocols, the two different names for = SCTP and TCP may make it seem like they are entirely different in = functionality when in fact they are not much different indeed: TCP=92s = Nagle operates on single bytes, SCTP=92s app PDU bundling operates on = potentially larger blocks of a given size? >=20 > What about: =93data bundling (1 byte)=94, as opposed to =93data = bundling (application PDU)=94 for SCTP ? I wouldn't object against using the term Nagle also for SCTP. It refers = to delaying the initial sending of user message in case of outstanding data. Bundling in SCTP = might happen even when Nagle is turned off, for example when you retransmit messages. Best regards Michael >=20 >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Dec 19 14:25:12 2014 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 33C521A8FD5 for ; Fri, 19 Dec 2014 14:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 zZKuwzdYcbon for ; Fri, 19 Dec 2014 14:25:06 -0800 (PST) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 973361A8AEA for ; Fri, 19 Dec 2014 14:25:05 -0800 (PST) Received: from [10.0.27.100] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 413211A02BC; Fri, 19 Dec 2014 23:24:34 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_C88BF969-7B6E-4882-97BC-EE778AC3E918"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Brian Trammell In-Reply-To: <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> Date: Fri, 19 Dec 2014 23:24:30 +0100 Message-Id: <58C86C88-9C7D-4E54-AC04-EF4C2D5CCD82@trammell.ch> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/9bl3zUaf57PSgwa5GlF9Pee54Rc Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 22:25:09 -0000 --Apple-Mail=_C88BF969-7B6E-4882-97BC-EE778AC3E918 Content-Type: multipart/alternative; boundary="Apple-Mail=_BF20AF6E-FB69-4AD6-A04E-26C1560B3DC9" --Apple-Mail=_BF20AF6E-FB69-4AD6-A04E-26C1560B3DC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Dec 2014, at 23:08, Michael Welzl wrote: >>=20 >> On 20. des. 2014, at 01.13, Brian Trammell wrote: >>=20 >> hi Michael, >>=20 >>> On 19 Dec 2014, at 10:29, Michael Welzl wrote: >>>=20 >>>=20 >>>> On 19. des. 2014, at 20.05, Brian Trammell = wrote: >>>>=20 >>>>=20 >>>>> On 18 Dec 2014, at 22:37, Michael Welzl = wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Thanks for this update! >>>>>=20 >>>>> A question: >>>>>=20 >>>>>> We've posted a -01 rev of the TAPS transports document. We = believe that the format and level of detail for the TCP section is about = what we're targeting for each of the other sections, but this is still = open to discussion. >>>>>=20 >>>>> Why is Nagle not a part of the protocol components and interface = description? It=92s mentioned in the protocol description above, and = it=92s something that an application decides. >>>>=20 >>>> Simple omission. >>>>=20 >>>> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >>>=20 >>> In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. >>=20 >> So I'd argue that (1) this isn't *exactly* the same thing, as the = interface to SOCK_SEQPACKET has application PDU preservation as an = explicit part of the API contract, > Ahh=85 let me see if I get this right: your point is, in terms of the = actual function, the difference is: I was trying to make a much less subtle point from the interface side: = since SCTP actually _has_ a concept of application PDU, it can bundle = them, while TCP has no such concept, so what it's bundling can't really = be PDUs. > SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the = buffer, out of which 3 may fit into a 1460-byte segment and get shipped = together after an RTT, wasting space for 110 bytes. sending app gives PDUS 1,2,3,4 via sendto(), receiver calls recvfrom() = four times and gets four PDUs. > TCP: app gives the same app PDUs into the send buffer, where they are = treated as a byte stream and a segment of 1460 bytes can be exactly = filled. sending app writes PDUS 1,2,3,4 via write(), receiver gets some bytes = from read(), and must either (1) know how large each PDU is in advance = or (2) use some framing information in the byte stream to figure this = out. > If that=92s it, then I agree, that=92s functionally different. >=20 >=20 >> while SOCK_STREAM does not, but (2) that at the protocol level it = might as well be, so "bundling" is exactly the right word. How about = "sender segment bundling" for TCP? >=20 > Ok by me, but we'll have to be careful later: when trying to unify = access to these services across protocols, the two different names for = SCTP and TCP may make it seem like they are entirely different in = functionality when in fact they are not much different indeed: TCP=92s = Nagle operates on single bytes, SCTP=92s app PDU bundling operates on = potentially larger blocks of a given size? >=20 > What about: =93data bundling (1 byte)=94, as opposed to =93data = bundling (application PDU)=94 for SCTP ? "Data bundling" unqualified is just fine by me. Cheers, Brian > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_BF20AF6E-FB69-4AD6-A04E-26C1560B3DC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 19 Dec 2014, at 23:08, Michael = Welzl <michawe@ifi.uio.no>= wrote:


On 20. des. 2014, at 01.13, Brian = Trammell <ietf@trammell.ch> wrote:

hi Michael,

On 19 Dec 2014, at 10:29, Michael = Welzl <michawe@ifi.uio.no> wrote:


On 19. = des. 2014, at 20.05, Brian Trammell <ietf@trammell.ch> = wrote:


On 18 Dec 2014, at 22:37, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

Thanks for this update!

A = question:

We've posted a -01 rev of the TAPS transports document. We = believe that the format and level of detail for the TCP section is about = what we're targeting for each of the other sections, but this is still = open to discussion.

Why is = Nagle not a part of the protocol components and interface description? = It=92s mentioned in the protocol description above, and it=92s something = that an application decides.

Simple omission.

Should we make = an attempt to give this (as a component) a generic name? "Selectable = sender side buffering"? Or can we just call it simply "Nagle"?

In http://heim.ifi.uio.no/michawe/research/publications/futurenet-= icc2011.pdf we = took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling.  I like that - = it's also perhaps useful to folks to reuse terminology when we mean the = exact same thing.

So I'd argue that (1) this isn't *exactly* the same thing, = as the interface to SOCK_SEQPACKET has application PDU preservation as = an explicit part of the API = contract,

Ahh=85 let me see if I get this right: your point is, in = terms of the actual function, the difference = is:

I was trying to make a = much less subtle point from the interface side: since SCTP actually = _has_ a concept of application PDU, it can bundle them, while TCP has no = such concept, so what it's bundling can't really be = PDUs.

SCTP: app can give app PDUs 1, 2, = 3, 4, each 450 bytes into the buffer, out of which 3 may fit into a = 1460-byte segment and get shipped together after an RTT, wasting space = for 110 bytes.

sending app = gives PDUS 1,2,3,4 via sendto(), receiver calls recvfrom() four times = and gets four PDUs.

TCP: app gives the same app = PDUs into the send buffer, where they are treated as a byte stream and a = segment of 1460 bytes can be exactly = filled.

sending app writes = PDUS 1,2,3,4 via write(), receiver gets some bytes from read(), and must = either (1) know how large each PDU is in advance or (2) use some framing = information in the byte stream to figure this out.

If that=92s it, then I agree, that=92s functionally = different.


while SOCK_STREAM does not, but (2) that at the protocol = level it might as well be, so "bundling" is exactly the right word. How = about "sender segment bundling" for TCP?

Ok by me, but we'll have to be careful later: when = trying to unify access to these services across protocols, the two = different names for SCTP and TCP may make it seem like they are entirely = different in functionality when in fact they are not much different = indeed: TCP=92s Nagle operates on single bytes, SCTP=92s app PDU = bundling operates on potentially larger blocks of a given = size?

What about: =93data bundling = (1 byte)=94, as opposed to =93data bundling (application PDU)=94 =  for SCTP ?

"Data = bundling" unqualified is just fine by = me.

Cheers,

Brian
<= br>
Cheers,
Michael

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
= --Apple-Mail=_BF20AF6E-FB69-4AD6-A04E-26C1560B3DC9-- --Apple-Mail=_C88BF969-7B6E-4882-97BC-EE778AC3E918 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 iQEcBAEBCgAGBQJUlKWeAAoJENt3nsOmbNJcZSsH/2opPlyaFUeuvroUAJbllk6W 28OR1OmxSrOGh+hKt3MyTYfrZhiVaNWgVRfCWElIYic7ZrniBEoPWvldPtGIH/bt I3/kDUH/EbHLQ5TPHtxBp5FQqmxlLeH1FuftNftrOCu9JcnzV9D1qgIxXKXETc2J 8Cm08oMnpucmFHXAAaf1sRqSecJ7XzIczUExJVpWMNHIVQByK6yBStKED3eWb2bB OHsB82ratHSuPCD1GZcQg0BanhyGHovkE2SNeyjFmkRhxuHKlhLzv0UfMtxo0prP MKJrFNP7itZ2YtBaM12o5/QhGkYMqnuh4WKrZePdXQlfcW4QMqbHZDmNGZKjPnU= =H+u2 -----END PGP SIGNATURE----- --Apple-Mail=_C88BF969-7B6E-4882-97BC-EE778AC3E918-- From nobody Fri Dec 19 14:40:53 2014 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 B68981A8704 for ; Fri, 19 Dec 2014 14:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gvMNO-Q4N6f4 for ; Fri, 19 Dec 2014 14:40:50 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB9B1A702A for ; Fri, 19 Dec 2014 14:40:50 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id sBJMeKnw022818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Dec 2014 14:40:21 -0800 (PST) Message-ID: <5494A954.1070402@isi.edu> Date: Fri, 19 Dec 2014 14:40:20 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Brian Trammell , Michael Welzl References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> <58C86C88-9C7D-4E54-AC04-EF4C2D5CCD82@trammell.ch> In-Reply-To: <58C86C88-9C7D-4E54-AC04-EF4C2D5CCD82@trammell.ch> 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: http://mailarchive.ietf.org/arch/msg/taps/DrdQPbiI4i8iYuDGB2k2FqWgOYM Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 22:40:51 -0000 On 12/19/2014 2:24 PM, Brian Trammell wrote: ... > I was trying to make a much less subtle point from the interface side: > since SCTP actually _has_ a concept of application PDU, it can bundle > them, while TCP has no such concept, so what it's bundling can't really > be PDUs. TCP has three notions of application interaction regarding user data boundaries: - a bytestream at which point the entire stream is the user API PDU (that's why CLOSE implies EOF; it's really "end of stream") - URG a one-bit flag that is an offset into the bytestream - PSH Of these, only the first two provide user-level "PDU" information. The last is essentially a flow-control signal. However, because of how URG works, it's not useful as an intra-stream marker (it is set for all segments between when activated and not). So I wouldn't say that TCP has no concept of an application PDU. What it lacks are internal PDU boundaries. The stream itself is the PDU. Joe From nobody Fri Dec 19 15:15:35 2014 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 011B81A90AC for ; Fri, 19 Dec 2014 15:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 dih-ETz0UoOx for ; Fri, 19 Dec 2014 15:15:25 -0800 (PST) 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 4C4791A87CD for ; Fri, 19 Dec 2014 15:15:23 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Y26lV-00057n-3n; Sat, 20 Dec 2014 00:15:21 +0100 Received: from cpe-137-147-69-158.lnse7.lon.bigpond.net.au ([137.147.69.158] helo=valkyrie.bigpond) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Y26lK-00049Q-MY; Sat, 20 Dec 2014 00:15:21 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_4454B8B2-FFCF-4004-99EE-98E9E0E67EAF" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Michael Welzl In-Reply-To: <3B53D3C5-9CCD-4B3C-9530-9FA5E340AFDC@fh-muenster.de> Date: Sat, 20 Dec 2014 10:14:42 +1100 Message-Id: <4790DAE9-BFE6-41D1-B061-5E438124EF4A@ifi.uio.no> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> <3B53D3C5-9CCD-4B3C-9530-9FA5E340AFDC@fh-muenster.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1990.1) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 4 total rcpts 24128 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C48CF997F2F4ECB7AE87C82F291C0037024593D5 X-UiO-SPAM-Test: remote_host: 137.147.69.158 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 82 max/h 9 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/_GYV2cKwwLOp5A4bP2NX0RPeZow Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 19 Dec 2014 23:15:29 -0000 --Apple-Mail=_4454B8B2-FFCF-4004-99EE-98E9E0E67EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 20. des. 2014, at 09.24, Michael Tuexen = wrote: >=20 > On 19 Dec 2014, at 23:08, Michael Welzl > wrote: >=20 >>=20 >>> On 20. des. 2014, at 01.13, Brian Trammell wrote: >>>=20 >>> hi Michael, >>>=20 >>>> On 19 Dec 2014, at 10:29, Michael Welzl wrote: >>>>=20 >>>>=20 >>>>> On 19. des. 2014, at 20.05, Brian Trammell = wrote: >>>>>=20 >>>>>=20 >>>>>> On 18 Dec 2014, at 22:37, Michael Welzl = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Thanks for this update! >>>>>>=20 >>>>>> A question: >>>>>>=20 >>>>>>> We've posted a -01 rev of the TAPS transports document. We = believe that the format and level of detail for the TCP section is about = what we're targeting for each of the other sections, but this is still = open to discussion. >>>>>>=20 >>>>>> Why is Nagle not a part of the protocol components and interface = description? It=92s mentioned in the protocol description above, and = it=92s something that an application decides. >>>>>=20 >>>>> Simple omission. >>>>>=20 >>>>> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >>>>=20 >>>> In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. >>>=20 >>> So I'd argue that (1) this isn't *exactly* the same thing, as the = interface to SOCK_SEQPACKET has application PDU preservation as an = explicit part of the API contract, >>=20 >> Ahh=85 let me see if I get this right: your point is, in terms of the = actual function, the difference is: >> SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the = buffer, out of which 3 may fit into a 1460-byte segment and get shipped = together after an RTT, wasting space for 110 bytes. > I guess the 1460 are related to the IP and TCP header. Silly me, yes of course I was thinking of TCP while actually talking = about SCTP :) > For SCTP it would be=20 > 20 bytes for IPv4 header, > 12 bytes for the SCTP common header, > 16 bytes for the DATA chunk header, > 450 byte payload > 16 bytes for the DATA chunk header, > 450 byte payload > 16 bytes for the DATA chunk header, > 450 byte payload > This gives 1430 bytes. > So 70 bytes are left. The SCTP implementation can just leave them = unused or, and that is the point I want to make, > add > 16 bytes for the DATA chunk header > 54 bytes (the initial 54 bytes of the fourth 450 bytes user message) > Then the frame is completely used. Ah, ok. I wasn=92t aware of that. Is that decision up to the = application? >> TCP: app gives the same app PDUs into the send buffer, where they are = treated as a byte stream and a segment of 1460 bytes can be exactly = filled. >>=20 >> If that=92s it, then I agree, that=92s functionally different. >>=20 >>=20 >>> while SOCK_STREAM does not, but (2) that at the protocol level it = might as well be, so "bundling" is exactly the right word. How about = "sender segment bundling" for TCP? >>=20 >> Ok by me, but we'll have to be careful later: when trying to unify = access to these services across protocols, the two different names for = SCTP and TCP may make it seem like they are entirely different in = functionality when in fact they are not much different indeed: TCP=92s = Nagle operates on single bytes, SCTP=92s app PDU bundling operates on = potentially larger blocks of a given size? >>=20 >> What about: =93data bundling (1 byte)=94, as opposed to =93data = bundling (application PDU)=94 for SCTP ? > I wouldn't object against using the term Nagle also for SCTP. It = refers to delaying the initial > sending of user message in case of outstanding data. Bundling in SCTP = might happen even when > Nagle is turned off, for example when you retransmit messages. I like Brian=92s proposal of unqualified =93data bundling=94 - it is = just a bit more meaningful than =93Nagle=94 (despite the historic = relevance of the latter). Cheers, Michael --Apple-Mail=_4454B8B2-FFCF-4004-99EE-98E9E0E67EAF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 20. des. 2014, at 09.24, Michael Tuexen <tuexen@fh-muenster.de> wrote:

On 19 Dec 2014, at 23:08, Michael Welzl = <michawe@ifi.uio.no> wrote:


On 20. des. 2014, at = 01.13, Brian Trammell <ietf@trammell.ch> wrote:

hi= Michael,

On 19 Dec 2014, at 10:29, Michael Welzl <michawe@ifi.uio.no> = wrote:


On 19. des. 2014, at 20.05, Brian Trammell = <ietf@trammell.ch> wrote:


On 18 Dec = 2014, at 22:37, Michael Welzl <michawe@ifi.uio.no> wrote:

Hi,

Thanks for this update!

A question:

We've posted a -01 rev = of the TAPS transports document. We believe that the format and level of = detail for the TCP section is about what we're targeting for each of the = other sections, but this is still open to discussion.

Why is Nagle not a part of the = protocol components and interface description? It=92s mentioned in the = protocol description above, and it=92s something that an application = decides.

Simple omission.

Should we make an attempt to give this (as a = component) a generic name? "Selectable sender side buffering"? Or can we = just call it simply "Nagle"?

In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-= icc2011.pdf we took SCTP's term for the same function because we = found it more meaningful than "Nagle": Application PDU Bundling.  I = like that - it's also perhaps useful to folks to reuse terminology when = we mean the exact same thing.

So= I'd argue that (1) this isn't *exactly* the same thing, as the = interface to SOCK_SEQPACKET has application PDU preservation as an = explicit part of the API contract,

Ahh=85 let me see if I get this right: your point is, in = terms of the actual function, the difference is:
SCTP: app = can give app PDUs 1, 2, 3, 4, each 450 bytes into the buffer, out of = which 3 may fit into a 1460-byte segment and get shipped together after = an RTT, wasting space for 110 bytes.
I guess the 1460 are related to the IP and TCP = header.

Silly me, = yes of course I was thinking of TCP while actually talking about SCTP =  :)


For SCTP it would be 
20 bytes for IPv4 header,
12 bytes for the SCTP common header,
16 bytes for the DATA chunk header,
450 byte payload
16 bytes for the DATA chunk header,
450 byte payload
16 bytes for the DATA chunk header,
450 byte payload
This gives 1430 bytes.
So 70 bytes are left. The SCTP implementation = can just leave them unused or, and that is the point I want to = make,
add
16 bytes for the DATA chunk header
54 bytes (the initial 54 bytes of the fourth 450 = bytes user message)
Then the frame is = completely used.

Ah, ok. I = wasn=92t aware of that. Is that decision up to the = application?


TCP: app gives the same = app PDUs into the send buffer, where they are treated as a byte stream = and a segment of 1460 bytes can be exactly filled.

If that=92s it, then I agree, that=92s functionally = different.


while SOCK_STREAM does not, but (2) that at the = protocol level it might as well be, so "bundling" is exactly the right = word. How about "sender segment bundling" for TCP?

Ok by me, but we'll have to be = careful later: when trying to unify access to these services across = protocols, the two different names for SCTP and TCP may make it seem = like they are entirely different in functionality when in fact they are = not much different indeed: TCP=92s Nagle operates on single bytes, = SCTP=92s app PDU bundling operates on potentially larger blocks of a = given size?

What about: =93data bundling (1 = byte)=94, as opposed to =93data bundling (application PDU)=94  for = SCTP ?
I wouldn't object = against using the term Nagle also for SCTP. It refers to delaying the = initial
sending of user message in = case of outstanding data. Bundling in SCTP might happen even = when
Nagle is turned off, for = example when you retransmit messages.

I like Brian=92s proposal of unqualified =93data = bundling=94 - it is just a bit more meaningful than =93Nagle=94 (despite = the historic relevance of the latter).

Cheers,
Michael

= --Apple-Mail=_4454B8B2-FFCF-4004-99EE-98E9E0E67EAF-- From nobody Sat Dec 20 00:53:13 2014 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 F107B1A0430 for ; Sat, 20 Dec 2014 00:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 cfcg-kYqCKQM for ; Sat, 20 Dec 2014 00:53:06 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936871A07BC for ; Sat, 20 Dec 2014 00:53:06 -0800 (PST) Received: from [192.168.1.200] (p508F0193.dip0.t-ipconnect.de [80.143.1.147]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 16A261C104357; Sat, 20 Dec 2014 09:53:02 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: <4790DAE9-BFE6-41D1-B061-5E438124EF4A@ifi.uio.no> Date: Sat, 20 Dec 2014 09:53:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6868A664-7A3B-4F99-84EA-9F385639A783@fh-muenster.de> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <80A8B715-F239-49F0-B7B1-64A6D4225FC9@ifi.uio.no> <254B3285-6735-4E38-B458-09A5719A3A7F@trammell.ch> <7047A84F-3CE4-4DE6-BC72-E847FBDAB1C0@ifi.uio.no> <3B53D3C5-9CCD-4B3C-9530-9FA5E340AFDC@fh-muenster.de> <4790DAE9-BFE6-41D1-B061-5E438124EF4A@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/eqtBL5QRvNg2PPdZMzidlx7VQRA Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 20 Dec 2014 08:53:09 -0000 On 20 Dec 2014, at 00:14, Michael Welzl wrote: >=20 >> On 20. des. 2014, at 09.24, Michael Tuexen = wrote: >>=20 >> On 19 Dec 2014, at 23:08, Michael Welzl wrote: >>=20 >>>=20 >>>> On 20. des. 2014, at 01.13, Brian Trammell = wrote: >>>>=20 >>>> hi Michael, >>>>=20 >>>>> On 19 Dec 2014, at 10:29, Michael Welzl = wrote: >>>>>=20 >>>>>=20 >>>>>> On 19. des. 2014, at 20.05, Brian Trammell = wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On 18 Dec 2014, at 22:37, Michael Welzl = wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> Thanks for this update! >>>>>>>=20 >>>>>>> A question: >>>>>>>=20 >>>>>>>> We've posted a -01 rev of the TAPS transports document. We = believe that the format and level of detail for the TCP section is about = what we're targeting for each of the other sections, but this is still = open to discussion. >>>>>>>=20 >>>>>>> Why is Nagle not a part of the protocol components and interface = description? It=92s mentioned in the protocol description above, and = it=92s something that an application decides. >>>>>>=20 >>>>>> Simple omission. >>>>>>=20 >>>>>> Should we make an attempt to give this (as a component) a generic = name? "Selectable sender side buffering"? Or can we just call it simply = "Nagle"? >>>>>=20 >>>>> In = http://heim.ifi.uio.no/michawe/research/publications/futurenet-icc2011.pdf= we took SCTP's term for the same function because we found it more = meaningful than "Nagle": Application PDU Bundling. I like that - it's = also perhaps useful to folks to reuse terminology when we mean the exact = same thing. >>>>=20 >>>> So I'd argue that (1) this isn't *exactly* the same thing, as the = interface to SOCK_SEQPACKET has application PDU preservation as an = explicit part of the API contract, >>>=20 >>> Ahh=85 let me see if I get this right: your point is, in terms of = the actual function, the difference is: >>> SCTP: app can give app PDUs 1, 2, 3, 4, each 450 bytes into the = buffer, out of which 3 may fit into a 1460-byte segment and get shipped = together after an RTT, wasting space for 110 bytes. >> I guess the 1460 are related to the IP and TCP header. >=20 > Silly me, yes of course I was thinking of TCP while actually talking = about SCTP :) >=20 >=20 >> For SCTP it would be=20 >> 20 bytes for IPv4 header, >> 12 bytes for the SCTP common header, >> 16 bytes for the DATA chunk header, >> 450 byte payload >> 16 bytes for the DATA chunk header, >> 450 byte payload >> 16 bytes for the DATA chunk header, >> 450 byte payload >> This gives 1430 bytes. >> So 70 bytes are left. The SCTP implementation can just leave them = unused or, and that is the point I want to make, >> add >> 16 bytes for the DATA chunk header >> 54 bytes (the initial 54 bytes of the fourth 450 bytes user message) >> Then the frame is completely used. >=20 > Ah, ok. I wasn=92t aware of that. Is that decision up to the = application? Not via the socket API as it is defined right now. >=20 >=20 >>> TCP: app gives the same app PDUs into the send buffer, where they = are treated as a byte stream and a segment of 1460 bytes can be exactly = filled. >>>=20 >>> If that=92s it, then I agree, that=92s functionally different. >>>=20 >>>=20 >>>> while SOCK_STREAM does not, but (2) that at the protocol level it = might as well be, so "bundling" is exactly the right word. How about = "sender segment bundling" for TCP? >>>=20 >>> Ok by me, but we'll have to be careful later: when trying to unify = access to these services across protocols, the two different names for = SCTP and TCP may make it seem like they are entirely different in = functionality when in fact they are not much different indeed: TCP=92s = Nagle operates on single bytes, SCTP=92s app PDU bundling operates on = potentially larger blocks of a given size? >>>=20 >>> What about: =93data bundling (1 byte)=94, as opposed to =93data = bundling (application PDU)=94 for SCTP ? >> I wouldn't object against using the term Nagle also for SCTP. It = refers to delaying the initial >> sending of user message in case of outstanding data. Bundling in SCTP = might happen even when >> Nagle is turned off, for example when you retransmit messages. >=20 > I like Brian=92s proposal of unqualified =93data bundling=94 - it is = just a bit more meaningful than =93Nagle=94 (despite the historic = relevance of the latter). OK. Then in both cases the application can't turn it off. Using = TCP_NODELAY or SCTP_NODELAY just affects it. Best regards Michael >=20 > Cheers, > Michael >=20 From nobody Mon Dec 22 08:53:36 2014 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 D81581A1A92 for ; Mon, 22 Dec 2014 08:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vRltbz-WoFLr for ; Mon, 22 Dec 2014 08:53:30 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A47A41A1A8E for ; Mon, 22 Dec 2014 08:53:29 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 33) id 8837D2B44A6; Mon, 22 Dec 2014 16:53:28 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by spey.erg.abdn.ac.uk with HTTP; Mon, 22 Dec 2014 16:53:28 -0000 Message-ID: <3553c59ea3ba62c68643d8a06a329740.squirrel@spey.erg.abdn.ac.uk> In-Reply-To: <549479AD.7070301@isi.edu> References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <549365CF.7020604@isi.edu> <549479AD.7070301@isi.edu> Date: Mon, 22 Dec 2014 16:53:28 -0000 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/NS4XUkQERWDWFYfnX1z7--fnK-I Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 22 Dec 2014 16:53:33 -0000 I can see the merits of discussing PUSH, but if this advice is for usage in the future, I think RFC 6093 says SHOULD NOT use, due to the range of TCP implementations that process TCP urgent indications differently. That makes me think it may be wise to note this perhaps, rather than just include it as if there were not issues. Gorry > One additional point: > > TCP services described in 3.1.3 should also include PUSH and URG > capabilities. > > FWIW, the specific section of RFC793 that defines the TCP interfaces - > above and below - is 3.8. > > Joe > > On 12/18/2014 3:39 PM, Joe Touch wrote: >> Some feedback below. Although I focus on some TCP and UDP specifics, >> some observations apply to other transports as well. >> >> Joe >> >> ----- >> >> 3.1.1 >> TCP segments fit into IP packets, but those packets are not >> necessarily constrained to fit into a lower-layer frame. >> They can be source fragmented. >> >> PathMTU discovery is supported by TCP but may be inhibited >> by network conditions (ICMP blocking); PLMTUD is supposed >> to be supported as well. >> >> 3.1.2 >> TCP's API is mostly specified in RFC793. >> >> What's missing are how options and parameters are managed. >> >> 3.1.3 >> TCP provides a byte-ordered reliable stream. How that >> is delivered - e.g., by segments - is irrelevant, if only >> because TCP can change those segment boundaries during >> operation (e.g., with path MTU updates). >> >> this section should also mention flow control - TCP >> doesn't dump data on the floor if the receiver >> can't process it fast enough (vs. UDP) >> >> additionally, the ports ought to be discussed in more detail. >> ports in the SYN have a different meaning that ports in other >> segments. The SYN destination port indicates the receiving >> ` service, which typically involves BOTH demuxing to a process >> within a host AND indicating the format of the stream. Ports >> there and in all other segments are only demultiplexing >> indicators. >> >> 3.4.1 >> UDP doesn't fragment packets into IP packets; it maps to >> a single IP packet, which itself may be fragmented. The >> IP fragments are what are limited by the lower-layer >> frames. >> >> Because UDP is connectionless, if you're going to talk >> about properties of sequences of messages, you need to >> explain what that sequence is - i.e., you need to >> define what it means to have a UDP flow, and only >> such flows are subject to flow/congestion control, >> PMTUD, etc. >> >> >> 3.4.2 >> RFC768 describes an API for UDP. As with TCP, >> it leaves out options and parameters. >> >> 3.4.3 >> should include port demuxing here too, with the same >> caveats as noted above for TCP (i.e., ports for >> messages have multiple meanings) >> >> ---- >> >> >> On 12/18/2014 6:44 AM, Brian Trammell wrote: >>> Greetings, all, >>> >>> We've posted a -01 rev of the TAPS transports document. We believe that >>> the format and level of detail for the TCP section is about what we're >>> targeting for each of the other sections, but this is still open to >>> discussion. The document also includes at least a little text on most >>> of the transport protocols identified in the -00 revision. Welcome also >>> to Mirja Kühlewind, added as an additional editor. >>> >>> If there are any additional transport protocols we're missing, or other >>> comments on document structure, please send them to the list. >>> >>> Document source is available (with a kramdown-rfc2629-based workflow) >>> at https://github.com/britram/taps-transports. Feel free to send pull >>> requests against the markdown, or XML/text diffs to the editors, for >>> contributions to sections of the document. >>> >>> Cheers, and merry Christmas, >>> >>> Brian >>> >>>> On 18 Dec 2014, at 15:06, 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-01.txt >>>> Pages : 15 >>>> Date : 2014-12-18 >>>> >>>> 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: >>>> http://tools.ietf.org/html/draft-ietf-taps-transports-01 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01 >>>> >>>> >>>> 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 >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Mon Dec 22 12:13:56 2014 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 4F9831A6F10 for ; Mon, 22 Dec 2014 12:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 T8_JK6SHg56P for ; Mon, 22 Dec 2014 12:13:51 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD0F41A1B30 for ; Mon, 22 Dec 2014 12:13:51 -0800 (PST) Received: from [192.168.1.15] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id sBMKD8w0018125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Dec 2014 12:13:18 -0800 (PST) Message-ID: <54987B59.9050109@isi.edu> Date: Mon, 22 Dec 2014 12:13:13 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <549365CF.7020604@isi.edu> <549479AD.7070301@isi.edu> <3553c59ea3ba62c68643d8a06a329740.squirrel@spey.erg.abdn.ac.uk> In-Reply-To: <3553c59ea3ba62c68643d8a06a329740.squirrel@spey.erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/taps/EzZTXnLroFLqBvVk8IQMe3q-99s Cc: Brian Trammell , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.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, 22 Dec 2014 20:13:54 -0000 Hi, Gorry, On 12/22/2014 8:53 AM, gorry@erg.abdn.ac.uk wrote: > I can see the merits of discussing PUSH, but if this advice is for usage > in the future, I think RFC 6093 says SHOULD NOT use, due to the range of > TCP implementations that process TCP urgent indications differently. That > makes me think it may be wise to note this perhaps, rather than just > include it as if there were not issues. IMO, you need to explain what you're doing before you jump into recommendations for the future. The current reality is that PUSH is defined for TCP, required in implementations, and can be used by applications (SHOULD NOT != MUST NOT). As far as APIs go, though - TCP has a fairly detailed one. It's in RFC793, and it should be summarized in its entirety (including updated current recommendations) if you're going to talk about transport APIs. Joe > > Gorry > >> One additional point: >> >> TCP services described in 3.1.3 should also include PUSH and URG >> capabilities. >> >> FWIW, the specific section of RFC793 that defines the TCP interfaces - >> above and below - is 3.8. >> >> Joe >> >> On 12/18/2014 3:39 PM, Joe Touch wrote: >>> Some feedback below. Although I focus on some TCP and UDP specifics, >>> some observations apply to other transports as well. >>> >>> Joe >>> >>> ----- >>> >>> 3.1.1 >>> TCP segments fit into IP packets, but those packets are not >>> necessarily constrained to fit into a lower-layer frame. >>> They can be source fragmented. >>> >>> PathMTU discovery is supported by TCP but may be inhibited >>> by network conditions (ICMP blocking); PLMTUD is supposed >>> to be supported as well. >>> >>> 3.1.2 >>> TCP's API is mostly specified in RFC793. >>> >>> What's missing are how options and parameters are managed. >>> >>> 3.1.3 >>> TCP provides a byte-ordered reliable stream. How that >>> is delivered - e.g., by segments - is irrelevant, if only >>> because TCP can change those segment boundaries during >>> operation (e.g., with path MTU updates). >>> >>> this section should also mention flow control - TCP >>> doesn't dump data on the floor if the receiver >>> can't process it fast enough (vs. UDP) >>> >>> additionally, the ports ought to be discussed in more detail. >>> ports in the SYN have a different meaning that ports in other >>> segments. The SYN destination port indicates the receiving >>> ` service, which typically involves BOTH demuxing to a process >>> within a host AND indicating the format of the stream. Ports >>> there and in all other segments are only demultiplexing >>> indicators. >>> >>> 3.4.1 >>> UDP doesn't fragment packets into IP packets; it maps to >>> a single IP packet, which itself may be fragmented. The >>> IP fragments are what are limited by the lower-layer >>> frames. >>> >>> Because UDP is connectionless, if you're going to talk >>> about properties of sequences of messages, you need to >>> explain what that sequence is - i.e., you need to >>> define what it means to have a UDP flow, and only >>> such flows are subject to flow/congestion control, >>> PMTUD, etc. >>> >>> >>> 3.4.2 >>> RFC768 describes an API for UDP. As with TCP, >>> it leaves out options and parameters. >>> >>> 3.4.3 >>> should include port demuxing here too, with the same >>> caveats as noted above for TCP (i.e., ports for >>> messages have multiple meanings) >>> >>> ---- >>> >>> >>> On 12/18/2014 6:44 AM, Brian Trammell wrote: >>>> Greetings, all, >>>> >>>> We've posted a -01 rev of the TAPS transports document. We believe that >>>> the format and level of detail for the TCP section is about what we're >>>> targeting for each of the other sections, but this is still open to >>>> discussion. The document also includes at least a little text on most >>>> of the transport protocols identified in the -00 revision. Welcome also >>>> to Mirja Kühlewind, added as an additional editor. >>>> >>>> If there are any additional transport protocols we're missing, or other >>>> comments on document structure, please send them to the list. >>>> >>>> Document source is available (with a kramdown-rfc2629-based workflow) >>>> at https://github.com/britram/taps-transports. Feel free to send pull >>>> requests against the markdown, or XML/text diffs to the editors, for >>>> contributions to sections of the document. >>>> >>>> Cheers, and merry Christmas, >>>> >>>> Brian >>>> >>>>> On 18 Dec 2014, at 15:06, 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-01.txt >>>>> Pages : 15 >>>>> Date : 2014-12-18 >>>>> >>>>> 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: >>>>> http://tools.ietf.org/html/draft-ietf-taps-transports-01 >>>>> >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-01 >>>>> >>>>> >>>>> 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 >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>