From nobody Mon Jun 1 02:23:55 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9501F1A90EE for ; Mon, 1 Jun 2015 02:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 pUGMMl0Oqhc1 for ; Mon, 1 Jun 2015 02:23:49 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811FC1A90E1 for ; Mon, 1 Jun 2015 02:23:47 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YzLwS-0005TU-JF; Mon, 01 Jun 2015 11:23:32 +0200 Received: from [194.86.25.98] (helo=[10.2.0.75]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1YzLwR-00079r-LW; Mon, 01 Jun 2015 11:23:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <20150601001753.GF31213@blasturvion.dynhost.nicta.com.au> Date: Mon, 1 Jun 2015 12:23:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <20150601001753.GF31213@blasturvion.dynhost.nicta.com.au> To: Olivier Mehani X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 11 sum msgs/h 3 total rcpts 29616 max rcpts/h 54 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: 28311D8AC3AC98B5117754998A6D8313DBC493D5 X-UiO-SPAM-Test: remote_host: 194.86.25.98 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 29 max/h 7 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , taps WG , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 09:23:54 -0000 > On 1. jun. 2015, at 03.17, Olivier Mehani = wrote: >=20 > Hey Mirja, >=20 > On Fri, May 29, 2015 at 10:27:46AM +0200, Mirja K=C3=BChlewind wrote: >>> I am not sure I have the same understanding of what features are. >>> More than what is exposed through the API (which indeed is very >>> little in the majority of the cases), I think features is what the >>> application implicitly expects when selecting a specific transport. >> Yes and no. So what you describe is the current state. A transport >> service is a set of transport services features and today you can >> select those features only implicitly by selection the transport >> protocol itself. >> However, I think that it is worth to provide an interface to = configure >> each feature explicitly. Not completely sure yet that it is true. But >> for me that=E2=80=99s one of the goals of this working group to = figure out if >> this statement is true. >=20 > Yes, that's how I understand it too. Nonetheless, we need to start = with > what we have: groups of features that we need to identify and = separate. >=20 >>> At the moment, looking at the draft, I think that most =E2=80=9CTransp= ort >>> Protocol Components=E2=80=9D sections actually conflate features and = components, >>> and probably list more of the former than the latter. I don't think = this >>> is quite in line with the terminology: > [...] >>>=20 >>> For example for TCP, I would say that the following are features = (that the application wants) >>> - reliable delivery >>> - ordered delivery for each byte stream >>> - stream-oriented delivery in a single stream >>> - unicast >>> - data bundling (Nagle's algorithm) >>> - port multiplexing >>> while these are components (that the application doesn't see) >>> - connection setup with feature negotiation and application-to-port = mapping >>> - error detection (checksum) >>> - segmentation >>> - flow control >>> - congestion control >> I also see this very slightly different. Features and components are >> for my understanding nothing exclusive. Each feature also has a >> corresponding component (but not the other way around). However, = while >> the feature is =E2=80=9Areliable delivery=E2=80=98 (because that all = the app cares >> about), the component might be more specific like "reliable delivery >> using accumulated ACKs and retransmissions=E2=80=99 as TCP does. >=20 > Yes, I completely agree. But I think the difference you higlight is > important: each feature has one (or more, I'd say) corresponding > components, while components might not necessarily result in an > application-visible feature.=20 >=20 >> The more important point is, that the current lists in the doc need >> work! Maybe some of the point you=E2=80=99ve listed above as features = must be >> phrased more detailed to describe/list the actually component and = then >> we need to decide which components actually also provide a feature >> (that should be exposed) and on which level this correlates to a >> feature. So the split you proposed above is a good starting point for >> this. >=20 > I'm glad to read it (: >=20 >>>> "transport service features" (components that are exposed to the >>>> application) ... and here come all the things found in today's (not >>>> tomorrow's!) APIs, as defined by the specs alone, not >>>> implementations and "transport protocol components" ... which is >>>> all the rest. I'm thinking of just a way of splitting the component >>>> lists, just to say "the following ones are exposed in the API >>>> today". >>> I think this makes sense. That said, beyond just the specs, I think >>> it would be useful to consider what current implementations provide >>> too, as this may offer a slightly different set of features which >>> is, nonetheless, what developers of real applications are dealing >>> with. >> You mean it term of APIs or component? Collecting information of >> components are are currently implemented/used is the purpose of this >> doc. Collecting information about API/config interfaces of what is >> implemented/used today is also useful but a rat-hole=E2=80=A6 = therefore we try >> cover this aspect briefly in this doc but do not aim for completeness >> here. >=20 > Yes, this is likely for a later document. However, I think we should > make sure that some transport API have not implemented some > non-standardised behaviours that a non-negligible number of = applications > use. I am not sure it's the case, but if it is so, we probably want to > take that onboard at some point too. I'd like to stress "at some point" (if at all). Maybe not even in this = particular document? This is exactly the layering problem here - transport protocol designers = will have thought through what kind of information should be exposed. = App programmers are now facing today's systems that they need to = optimize as good as they can. Maybe ad hoc decisions are / were made to = allow some protocol tuning that shouldn't really be an application's = problem. To me, apps fine tuning protocols in non-standard ways is already one = small step in the direction of what TAPS is trying to help against: = every application programmer re-doing the job again, developing their = own transport protocols inside their app. I think it's important to start with what the protocol designers thought = should be exposed and no more, and then we can draw a clean line and say = "look, maybe these decisions should be revisited, this and this is = constantly being used by applications". Cheers, Michael From nobody Mon Jun 1 06:32:11 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCDE1ACDD1 for ; Mon, 1 Jun 2015 06:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDb6Z_AmSSPn for ; Mon, 1 Jun 2015 06:32:07 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD201A8F4C for ; Mon, 1 Jun 2015 06:32:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 53385D931C; Mon, 1 Jun 2015 15:32:05 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BTIBfuszvnQI; Mon, 1 Jun 2015 15:32:05 +0200 (MEST) Received: from [192.168.178.33] (x4d02fd66.dyn.telefonica.de [77.2.253.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id BBEE4D9319; Mon, 1 Jun 2015 15:32:04 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 1 Jun 2015 15:32:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , taps WG , Olivier Mehani , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 13:32:10 -0000 Hi Joe, hi Michael, I completely welcome to add more text to the Interface description = section (3.1.2). Currently this section is very short and says regarding = the (higher layer) interface described in FRC793: "A User/TCP Interface is defined in [RFC0793] providing six user commands: Open, Send, Receive, Close, Status. This interface does not describe configuration of TCP options or parameters beside use of the PUSH and URGENT flags.=E2=80=9C This text was already added based on Joe=E2=80=99s input. Please provide = more text if you think this is not sufficient.=20 Probably we should at least add one more sentence describing the = TCP-to-User interface (as it is called in RFC 793) like this: =E2=80=9EFurther the TCP-to-User interface is described providing = information on the local connection name, the response string, the send = and received buffer addresses, the Byte count (which counts bytes = received) as well as the PUSH flag and URGENT flag.=E2=80=9C However, from my point of view I actually think that these (basic) = things do not need to be discussed in more detail because the described = interface is completely okay and can probably be mostly say as it is. = The more complicated question is which additional things are needed and, = even more important, how can you design a transport interface where the = application does not need to choose the protocol first. Because the = interface in RFC 793 only describes a User/TCP interface where TCP = already determines a certain transport service or a set of transport = services features relating to specific transport components. The whole = goal or taps is to make things more flexible which mean we need more = information before we open a connection and probably also during the = connection. One information could be =E2=80=9EI want to use a TCP = header=E2=80=9C and maybe together with these features=E2=80=A6 However, = as soon as we have chosen certain protocol which might be TCP be still = need Open, send, receive and closes commands as described in RFC 793. So what I want to say is, that the described interface in RFC 793 is so = basic that it is not wrong and should be described in this doc (as it = is) but it does help us very much to get to the goal we would like to = reach in taps which I currently would describe as: Extend the = application layer interface to consequently provide a more flexible = transport layer. Or even better the other way around: Create a more = flexible transport layer which most likely will lead to an extended = application-level interface. Another thing I also would like to say (again) at this point is that the = current doc will not specify an new interface. We on purpose =E2=80=9Aonly= =E2=80=98 talk about transport components and features in this document = because we first need to know what we want to do before we can talk = about the interface. However, again, if you think there is something important missing in = this doc, please send text! Currently we will (more or less) just integrate all text that we get = because it is much easier to discuss about text that is there and = something that is not there. That does also mean that any text that is = currently in the doc can be discussed, changed or removed! Mirja > Am 30.05.2015 um 14:24 schrieb Michael Welzl : >=20 >=20 >> On 29. mai 2015, at 19.32, Joe Touch wrote: >>=20 >> First, I think this discussion would benefit from a clarification of >> what "API" means, or at least to stop using that term in isolation. >>=20 >> There are three distinct concepts: >>=20 >> A- abstract protocol "upper layer interface"=09 >> e.g., OPEN, CLOSE, ABORT, as per RFC 793 >>=20 >> B- programmer API >> e.g., Linux C/C++ TCP socket interface >>=20 >> C- instance of a programmer API >> e.g., Linux Ubuntu 15.04 C/C++ TCP socket interface >>=20 >> IMO, this document MUST discuss A, and can be address potential >> extensions to A based on examining variants of B and C. >>=20 >> There are also the protocol features, which are the properties of the >> protocol that: >> - can be explicitly configured and monitored >> these are *exactly* A, B, and/or C above >>=20 >> - can be implicitly detected >> some are based on the definition of the protocol, >> such as reliable, byte sequence delivery >>=20 >> some are an artifact of the implementation, >> such as specific delays due to burst losses >>=20 >> However, *none* of this is a rat-hole IF TAPS is intended to explain = the >> service interface to the user. IMO, B and C above should be secondary >> considerations after A is clearly documented, but this draft is a = long >> way from that. >=20 > I agree: A should be there, and it should probably the primary focus, = as starting with a list of A would add a lot of clarity to the document = and the discussion of it. >=20 > Some text on protocol internals, explaing what a protocol does even = though these things may not be exposed to an application, can be = valuable even if only to know which protocol to choose. So I'm not = suggesting removing everything but I'd agree that the focus of the = document should shift towards a list of A. >=20 > Cheers, > Michael From nobody Mon Jun 1 09:45:34 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C521B2D17 for ; Mon, 1 Jun 2015 09:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xz0kj3Nqrw0l for ; Mon, 1 Jun 2015 09:45:31 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479FC1B2CE3 for ; Mon, 1 Jun 2015 09:45:31 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YzSpx-0004m9-6i; Mon, 01 Jun 2015 18:45:17 +0200 Received: from [194.86.25.98] (helo=[10.2.0.75]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YzSpw-0002gJ-Jn; Mon, 01 Jun 2015 18:45:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Mon, 1 Jun 2015 19:45:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 13 sum msgs/h 6 total rcpts 29644 max rcpts/h 54 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: AD8015148F95FB2148342F61B8AB99001D35FB7C X-UiO-SPAM-Test: remote_host: 194.86.25.98 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 42 max/h 8 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , taps WG , Olivier Mehani , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:45:33 -0000 > On 1. jun. 2015, at 16.32, Mirja K=C3=BChlewind = wrote: >=20 > Hi Joe, hi Michael, >=20 > I completely welcome to add more text to the Interface description = section (3.1.2). Currently this section is very short and says regarding = the (higher layer) interface described in FRC793: >=20 > "A User/TCP Interface is defined in [RFC0793] providing six user > commands: Open, Send, Receive, Close, Status. This interface does > not describe configuration of TCP options or parameters beside use = of > the PUSH and URGENT flags.=E2=80=9C >=20 > This text was already added based on Joe=E2=80=99s input. Please = provide more text if you think this is not sufficient.=20 >=20 > Probably we should at least add one more sentence describing the = TCP-to-User interface (as it is called in RFC 793) like this: >=20 > =E2=80=9EFurther the TCP-to-User interface is described providing = information on the local connection name, the response string, the send = and received buffer addresses, the Byte count (which counts bytes = received) as well as the PUSH flag and URGENT flag.=E2=80=9C I agree > However, from my point of view I actually think that these (basic) = things do not need to be discussed in more detail because the described = interface is completely okay and can probably be mostly say as it is. I agree > The more complicated question is which additional things are needed = and, even more important, how can you design a transport interface where = the application does not need to choose the protocol first. Because the = interface in RFC 793 only describes a User/TCP interface where TCP = already determines a certain transport service or a set of transport = services features relating to specific transport components. The whole = goal or taps is to make things more flexible which mean we need more = information before we open a connection and probably also during the = connection. True, but this sounds out of scope of this document? This is just = supposed to list the services... =20 > One information could be =E2=80=9EI want to use a TCP header=E2=80=9C = and maybe together with these features=E2=80=A6 However, as soon as we = have chosen certain protocol which might be TCP be still need Open, = send, receive and closes commands as described in RFC 793. I'd say "I want to use a TCP header" should definitely be out of scope = of all this because it defeats the purpose of the TAPS idea. If I know I = want to use a TCP header, I don't use TAPS, I use TCP! We're not aiming = at replacing the interface for all applications, just offering something = new. > So what I want to say is, that the described interface in RFC 793 is = so basic that it is not wrong and should be described in this doc (as it = is) but it does help us very much to get to the goal we would like to = reach in taps which I currently would describe as: Extend the = application layer interface to consequently provide a more flexible = transport layer. Or even better the other way around: Create a more = flexible transport layer which most likely will lead to an extended = application-level interface. Yes, but... > Another thing I also would like to say (again) at this point is that = the current doc will not specify an new interface. Exactly :-) > We on purpose =E2=80=9Aonly=E2=80=98 talk about transport components = and features in this document because we first need to know what we want = to do before we can talk about the interface. >=20 > However, again, if you think there is something important missing in = this doc, please send text! > Currently we will (more or less) just integrate all text that we get = because it is much easier to discuss about text that is there and = something that is not there. That does also mean that any text that is = currently in the doc can be discussed, changed or removed! Good, thanks. Anyway my point was that, in this list of services, we = should be clear about Joe's item A: what is currently offered to apps by = the current specs. This is the most important part of the list because = it reflects what designers of these protocols (and with them, some form = of prior IETF group consensus) think should be offered to apps. Going beyond that by discussing internals or things that some apps now = can tune is a nice extra perhaps, but I think it should be a secondary = goal. Cheers, Michael From nobody Mon Jun 1 10:02:43 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6631B2F36 for ; Mon, 1 Jun 2015 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xx-1bL-Bok2 for ; Mon, 1 Jun 2015 10:02:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C73E1B2F0D for ; Mon, 1 Jun 2015 10:02:40 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t51GtfqG009808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Jun 2015 09:55:41 -0700 (PDT) Message-ID: <556C8E8C.9020102@isi.edu> Date: Mon, 01 Jun 2015 09:55:40 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> 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: Cc: Brian Trammell , taps WG , Olivier Mehani Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:02:41 -0000 On 6/1/2015 9:45 AM, Michael Welzl wrote: > >> On 1. jun. 2015, at 16.32, Mirja Kühlewind wrote: >> >> Hi Joe, hi Michael, >> >> I completely welcome to add more text to the Interface description section (3.1.2). Currently this section is very short and says regarding the (higher layer) interface described in FRC793: >> >> "A User/TCP Interface is defined in [RFC0793] providing six user >> commands: Open, Send, Receive, Close, Status. This interface does >> not describe configuration of TCP options or parameters beside use of >> the PUSH and URGENT flags.“ >> >> This text was already added based on Joe’s input. Please provide more text if you think this is not sufficient. >> >> Probably we should at least add one more sentence describing the TCP-to-User interface (as it is called in RFC 793) like this: >> >> „Further the TCP-to-User interface is described providing information on the local connection name, the response string, the send and received buffer addresses, the Byte count (which counts bytes received) as well as the PUSH flag and URGENT flag.“ > > I agree My concern is that there is no clear relation between 3.1.2 and 3.1.3. In fact, many of the properties of 3.1.3 are the result of the interface mentioned in 3.1.2. Also, a few aspects of the 3.1.2 interface aren't considered in 3.1.3. So what's the point of 3.1.3? >From the definition: Transport Protocol Component: an implementation of a transport service feature within a protocol. Unfortunately, the items in 3.1.3 aren't implementations; they're general properties. An implementation would be Reno or CUBIC. In addition, API isn't defined (e.g., see my previous 3 descriptions), so it's never clear what should be in 3.1.2 (or the corresponding sections of other protocols). As a result, I do not understand the purpose of either section of this document, or this document as a whole. Joe From nobody Mon Jun 1 11:38:24 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5F1B30DD for ; Mon, 1 Jun 2015 11:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8X1BbIKYx0l for ; Mon, 1 Jun 2015 11:38:21 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51BC1B30F8 for ; Mon, 1 Jun 2015 11:38:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 47AB6D931C; Mon, 1 Jun 2015 20:38:19 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4xZBtd-auUzi; Mon, 1 Jun 2015 20:38:19 +0200 (MEST) Received: from [192.168.178.33] (x4d02fd66.dyn.telefonica.de [77.2.253.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id DBA5AD9309; Mon, 1 Jun 2015 20:38:18 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <556C8E8C.9020102@isi.edu> Date: Mon, 1 Jun 2015 20:38:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:38:23 -0000 Hi Joe >=20 > My concern is that there is no clear relation between 3.1.2 and 3.1.3. Yes, that=E2=80=99s actually true. Initially there was no section 3.1.2 = as this doc is not on interfaces. However it seems to be incomplete = without mentioning interfaces at all. If we keep this section, you are = right, the relation should be there. >=20 > In fact, many of the properties of 3.1.3 are the result of the = interface > mentioned in 3.1.2. Really? Can you give an example? I would rather hope that we can = describe the transport components independent of the currently/any = interface. > Also, a few aspects of the 3.1.2 interface aren't > considered in 3.1.3. To complete 3.1.3, looking at interface is probably useful. Can you list = what=E2=80=99s missing? >=20 > So what's the point of 3.1.3? I=E2=80=99d rather ask what=E2=80=99s the point of 3.1.2=E2=80=A6? 3.1.3 = is/should become a list of components as basis for discuss which = features should/must be exposed to the app-layer.=20 >=20 >> =46rom the definition: > Transport Protocol Component: an implementation of a transport > service feature within a protocol. >=20 > Unfortunately, the items in 3.1.3 aren't implementations; they're > general properties. An implementation would be Reno or CUBIC. I agree that what=E2=80=99s currently listed is not on the right level = of detail (see also my other mail to Olivier). Not sure if Reno/Cubic is = on the right level either. Maybe it=E2=80=99s delay/loos-based or = foreground/background or AIMD, but congestion control is especially = complicated I=E2=80=99d say. That=E2=80=99s what we have to figure out = now. >=20 > In addition, API isn't defined (e.g., see my previous 3 descriptions), > so it's never clear what should be in 3.1.2 (or the corresponding > sections of other protocols). I don=E2=80=99t know either what should be in 3.1.2 right now. Anything = that is useful for 3.1.3 or 4 should be mentioned; everything else will = be removed at the end (potentially even the whole section).=20 >=20 > As a result, I do not understand the purpose of either section of this > document, or this document as a whole. That=E2=80=99s to bad. Maybe we should state this more explicitly in the = intro=E2=80=A6? According to our charter, while taps itself is chartered = to describe "an (abstract) interface for applications=20 to make use of Transport Services=E2=80=9C, this first document is only = used to "identifying the=20 [components] provided by existing IETF protocols=E2=80=9C as a starting = point. Further we would like to add some discussion in section 4 which = of the identified components should/can be exposed as a transport = feature that the app should see. [Note that the terminology changed and = whenever services is written in the charter it should basically be = component.] Does this help? Mirja >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Jun 1 11:59:02 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86ED81B315C for ; Mon, 1 Jun 2015 11:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz84if6NtJyk for ; Mon, 1 Jun 2015 11:58:58 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE65A1B315E for ; Mon, 1 Jun 2015 11:58:57 -0700 (PDT) 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 t51Itox0000036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Jun 2015 11:55:54 -0700 (PDT) Message-ID: <556CAAB5.5050806@isi.edu> Date: Mon, 01 Jun 2015 11:55:49 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> In-Reply-To: <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> 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: Cc: taps WG , touch@isi.edu Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:58:59 -0000 On 6/1/2015 11:38 AM, Mirja Kühlewind wrote: > Hi Joe >> >> My concern is that there is no clear relation between 3.1.2 and 3.1.3. > > Yes, that’s actually true. Initially there was no section 3.1.2 as > this doc is not on interfaces. However it seems to be incomplete without > mentioning interfaces at all. If we keep this section, you are right, > the relation should be there. Interfaces *define* services: We use the term "Transport Service" to mean an end-to-end facility provided by the transport layer. That service can only be provided correctly if information is supplied from the application. The API defines the information supplied from (and to) the application. Thus, if TAPS doesn't include the API in its flagship document, then I have no idea what you're all doing. >> In fact, many of the properties of 3.1.3 are the result of the interface >> mentioned in 3.1.2. > > Really? Can you give an example? I would rather hope that we can > describe the transport components independent of the currently/any > interface. Your own charter indicates why that is not possible. (Again, I mean "abstract API", not the C or Linux implementations of these). Properties: - stateful result of OPEN and CLOSE commands - active calling party result active/passive OPEN commands i.e., one party needs to actively call the other - byte-oriented, in order result of SEND/RECEIVE calls in order that input/output blocks of bytes in linear sequence - independent of the application data boundaries result of the semantics fo the SEND/RECEIVE calls, which input/output blocks of bytes where the call data boundaries are defined as NOT corresponding to TCP segment boundaries or events - OOB signaling result of PUSH and URG interface >> Also, a few aspects of the 3.1.2 interface aren't >> considered in 3.1.3. > > To complete 3.1.3, looking at interface is probably useful. Can you list what’s missing? I've done this multiple times already. >> So what's the point of 3.1.3? > > I’d rather ask what’s the point of 3.1.2…? 3.1.3 is/should become a > list of components as basis for discuss which features should/must be > exposed to the app-layer. The list of "components" doesn't fit the definition within this doc, so I disagree with this. >>> From the definition: >> Transport Protocol Component: an implementation of a transport >> service feature within a protocol. >> >> Unfortunately, the items in 3.1.3 aren't implementations; they're >> general properties. An implementation would be Reno or CUBIC. > > I agree that what’s currently listed is not on the right level of > detail (see also my other mail to Olivier). Not sure if Reno/Cubic is on > the right level either. Maybe it’s delay/loos-based or > foreground/background or AIMD, but congestion control is especially > complicated I’d say. That’s what we have to figure out now. You need to update your definitions first if that's the case. >> In addition, API isn't defined (e.g., see my previous 3 descriptions), >> so it's never clear what should be in 3.1.2 (or the corresponding >> sections of other protocols). > > I don’t know either what should be in 3.1.2 right now. Anything that is > useful for 3.1.3 or 4 should be mentioned; everything else will be > removed at the end (potentially even the whole section). The expectations for what are in each section should be defined in this document. Again, if we all don't know what's being written, writing is premature. >> As a result, I do not understand the purpose of either section of this >> document, or this document as a whole. > > That’s to bad. Maybe we should state this more explicitly in the > intro…? According to our charter, while taps itself is chartered to > describe "an (abstract) interface for applications > to make use of Transport Services“, That is an API - more specifically, it's a future, desired abstract API. > this first document is only used to "identifying the > [components] provided by existing IETF protocols“ as a starting > point. IMO, you need to start by defining the current abstract API, then the internal capabilities (independent of implementation) that might be exposed. I don't see how to do that with this "shopping-list" of issues. Joe From nobody Mon Jun 1 12:12:45 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023011B31F1 for ; Mon, 1 Jun 2015 12:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuyh158qf6-t for ; Mon, 1 Jun 2015 12:12:42 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A308B1B31AA for ; Mon, 1 Jun 2015 12:12:42 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YzV8a-0003SU-GL; Mon, 01 Jun 2015 21:12:40 +0200 Received: from [194.86.25.98] (helo=[10.2.0.75]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YzV8a-0001Nq-1L; Mon, 01 Jun 2015 21:12:40 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> Date: Mon, 1 Jun 2015 22:12:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 16 sum msgs/h 9 total rcpts 29671 max rcpts/h 54 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: CCFE3C8548C0168A00B1D346B366FE740CC4C4ED X-UiO-SPAM-Test: remote_host: 194.86.25.98 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 59 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: taps WG , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 19:12:44 -0000 About one bit in particular: > That=E2=80=99s to bad. Maybe we should state this more explicitly in = the intro=E2=80=A6? According to our charter, while taps itself is = chartered to describe "an (abstract) interface for applications=20 > to make use of Transport Services=E2=80=9C, this first document is = only used to "identifying the=20 > [components] provided by existing IETF protocols=E2=80=9C as a = starting point. Further we would like to add some discussion in section = 4 which of the identified components should/can be exposed as a = transport feature that the app should see. [Note that the terminology = changed and whenever services is written in the charter it should = basically be component.] This confuses me. draft-ietf-taps-transports-04 defines a "Transport Protocol Component" = as "an implementation of a transport service feature within a protocol." I'm fine with that definition but I can't see why this should replace = "service" in the charter. The first document should list the services = provided by existing IETF protocols, that's how to get started. = Additionally listing components is probably fine if that helps = explaining how services are constructed, but the focus is on what = transports provide - services. Cheers, Michael From nobody Mon Jun 1 12:23:26 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889711B2B2D for ; Mon, 1 Jun 2015 12:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WviF8roPOVOH for ; Mon, 1 Jun 2015 12:23:18 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565121B3144 for ; Mon, 1 Jun 2015 12:23:17 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YzVIp-0004SA-LB; Mon, 01 Jun 2015 21:23:15 +0200 Received: from [194.86.25.98] (helo=[10.2.0.75]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YzVIp-0001Aa-7u; Mon, 01 Jun 2015 21:23:15 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> Date: Mon, 1 Jun 2015 22:23:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 19 sum msgs/h 10 total rcpts 29674 max rcpts/h 54 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: 5A07BC655E486939EA13C58841AE13B6916009DC X-UiO-SPAM-Test: remote_host: 194.86.25.98 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 60 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: taps WG , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 19:23:19 -0000 I'll try addressing another detail, maybe that helps get us aligned: > On 1. jun. 2015, at 21.38, Mirja K=C3=BChlewind = wrote: >=20 > Hi Joe >>=20 >> My concern is that there is no clear relation between 3.1.2 and = 3.1.3. >=20 > Yes, that=E2=80=99s actually true. Initially there was no section = 3.1.2 as this doc is not on interfaces. However it seems to be = incomplete without mentioning interfaces at all. If we keep this = section, you are right, the relation should be there. The document is about services. These are provided via interfaces - so = the document should very much be about interfaces. 3.1.3 describes TCP, it lists all the things you get with TCP - nothing = that the application can configure, but what you get with it anyway. The complete service provided by TCP consists of everything TCP is AND = the what the application can configure about it. It gives you segmentation, congestion control, .... AND it lets you use = PUSH and an URGENT pointer and ... Cheers, Michael From nobody Mon Jun 1 13:19:57 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF141A8A58 for ; Mon, 1 Jun 2015 13:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9y_lpm9OQV0 for ; Mon, 1 Jun 2015 13:19:56 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3981A8A0E for ; Mon, 1 Jun 2015 13:19:56 -0700 (PDT) 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 t51KHWTp021481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Jun 2015 13:17:32 -0700 (PDT) Message-ID: <556CBDDC.6060904@isi.edu> Date: Mon, 01 Jun 2015 13:17:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> 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: Cc: taps WG , touch@isi.edu Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 20:19:57 -0000 On 6/1/2015 12:23 PM, Michael Welzl wrote: > I'll try addressing another detail, maybe that helps get us aligned: > > >> On 1. jun. 2015, at 21.38, Mirja Kühlewind wrote: >> >> Hi Joe >>> >>> My concern is that there is no clear relation between 3.1.2 and 3.1.3. >> >> Yes, that’s actually true. Initially there was no section 3.1.2 as this doc is not on interfaces. However it seems to be incomplete without mentioning interfaces at all. If we keep this section, you are right, the relation should be there. > > The document is about services. These are provided via interfaces - so the document should very much be about interfaces. > 3.1.3 describes TCP, it lists all the things you get with TCP - nothing that the application can configure, but what you get with it anyway. > > The complete service provided by TCP consists of everything TCP is AND the what the application can configure about it. Yes. > It gives you segmentation, congestion control, .... AND it lets you use PUSH and an URGENT pointer and ... Segmentation is HOW TCP gives you a reliable byte-sequence service over a packet service. It is absolutely NOT something provided to the user or under user control. Users can set MTU values on *some systems*, but that's not part of the TCP API (to the application) nor does MTU necessarily correspond to actual data boundaries (TCP is allowed to do a lot of things). Joe From nobody Mon Jun 1 13:34:55 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB61B33C6 for ; Mon, 1 Jun 2015 13:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-jex0aJ8VOk for ; Mon, 1 Jun 2015 13:34:51 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8F661B33BD for ; Mon, 1 Jun 2015 13:34:50 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YzWQ4-0003ZV-Ca; Mon, 01 Jun 2015 22:34:48 +0200 Received: from [194.86.25.98] (helo=[10.2.0.75]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1YzWQ3-0001RI-T6; Mon, 01 Jun 2015 22:34:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <556CBDDC.6060904@isi.edu> Date: Mon, 1 Jun 2015 23:34:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <960E5B02-C324-454A-B627-4ECAAE91E93E@ifi.uio.no> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <556CBDDC.6060904@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 14 sum msgs/h 6 total rcpts 29682 max rcpts/h 54 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: 41142926D7E9A854ED773B2EC04FED0C61D3A3ED X-UiO-SPAM-Test: remote_host: 194.86.25.98 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 64 max/h 15 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 20:34:53 -0000 > On 1. jun. 2015, at 23.17, Joe Touch wrote: >=20 >=20 >=20 > On 6/1/2015 12:23 PM, Michael Welzl wrote: >> I'll try addressing another detail, maybe that helps get us aligned: >>=20 >>=20 >>> On 1. jun. 2015, at 21.38, Mirja K=C3=BChlewind = wrote: >>>=20 >>> Hi Joe >>>>=20 >>>> My concern is that there is no clear relation between 3.1.2 and = 3.1.3. >>>=20 >>> Yes, that=E2=80=99s actually true. Initially there was no section = 3.1.2 as this doc is not on interfaces. However it seems to be = incomplete without mentioning interfaces at all. If we keep this = section, you are right, the relation should be there. >>=20 >> The document is about services. These are provided via interfaces - = so the document should very much be about interfaces. >> 3.1.3 describes TCP, it lists all the things you get with TCP - = nothing that the application can configure, but what you get with it = anyway. >>=20 >> The complete service provided by TCP consists of everything TCP is = AND the what the application can configure about it. >=20 > Yes. >=20 >> It gives you segmentation, congestion control, .... AND it lets you = use PUSH and an URGENT pointer and ... >=20 > Segmentation is HOW TCP gives you a reliable byte-sequence service = over > a packet service. >=20 > It is absolutely NOT something provided to the user or under user > control. Users can set MTU values on *some systems*, but that's not = part > of the TCP API (to the application) nor does MTU necessarily = correspond > to actual data boundaries (TCP is allowed to do a lot of things). Yes, I didn't mean that segmentation is under user control. Let me = rephrase my above sentence: >> It gives you, via its non-configurable static behavior: segmentation, = congestion control, .... AND it lets you control some things: PUSH and = an URGENT pointer and ... Cheers, Michael From nobody Mon Jun 1 14:22:45 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5F61A0035 for ; Mon, 1 Jun 2015 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWYrsPETt5n2 for ; Mon, 1 Jun 2015 14:22:42 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812ED1A002F for ; Mon, 1 Jun 2015 14:22:42 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t51LMGJM006632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 1 Jun 2015 14:22:16 -0700 (PDT) Message-ID: <556CCD07.9080504@isi.edu> Date: Mon, 01 Jun 2015 14:22:15 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <556CBDDC.6060904@isi.edu> <960E5B02-C324-454A-B627-4ECAAE91E93E@ifi.uio.no> In-Reply-To: <960E5B02-C324-454A-B627-4ECAAE91E93E@ifi.uio.no> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 21:22:44 -0000 On 6/1/2015 1:34 PM, Michael Welzl wrote: .... >> Segmentation is HOW TCP gives you a reliable byte-sequence service over >> a packet service. >> >> It is absolutely NOT something provided to the user or under user >> control. Users can set MTU values on *some systems*, but that's not part >> of the TCP API (to the application) nor does MTU necessarily correspond >> to actual data boundaries (TCP is allowed to do a lot of things). > > Yes, I didn't mean that segmentation is under user control. Let me rephrase my above sentence: > >>> It gives you, via its non-configurable static behavior: >>> segmentation, congestion control, .... AND it lets you control some >>> things: PUSH and an URGENT pointer and ... But it doesn't "give" you segmentation. It uses segmentation to provide a reliable byte stream over a packetized service. If we wanted, we could arguably export a TCP service over a circuit that did NOT need to rely on segmentation. This discussion really needs to distinguish between WHAT TCP exports and HOW TCP makes that happen - the latter may or may not ever be visible to the user. Joe From nobody Mon Jun 1 23:13:39 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBAC1A6FF9 for ; Mon, 1 Jun 2015 23:13:37 -0700 (PDT) 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 R2FIxzE-CGcA for ; Mon, 1 Jun 2015 23:13:35 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C461A701A for ; Mon, 1 Jun 2015 23:13:34 -0700 (PDT) X-AuditID: 12074423-f79496d000000d43-19-556d498d1fed Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.35.03395.D894D655; Tue, 2 Jun 2015 02:13:33 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t526DWFU017841; Tue, 2 Jun 2015 02:13:33 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t526DUaY009416; Tue, 2 Jun 2015 02:13:31 -0400 Received: from W92EXHUB15.exchange.mit.edu (18.7.73.26) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Jun 2015 02:13:01 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.162]) by W92EXHUB15.exchange.mit.edu ([18.7.73.26]) with mapi id 14.03.0158.001; Tue, 2 Jun 2015 02:13:30 -0400 From: Marie-Jose Montpetit To: Joe Touch Thread-Topic: [Taps] I-D Action: draft-ietf-taps-transports-04.txt Thread-Index: AQHQl7FIUwE5HR8PKE+UWFpM4Ir68Z2OgpOAgACZ2QCAAPIVgIAAR+2AgAEDuQCAAJLKAIAACGsAgAADsACAABUJgIAA0fqAgAAGSgCAABGqgIAAhpaAgAE8R4CAAzd8gIAANfiAgAAC6wCAABysgIAADI8AgAAPLACAAATRAIAADUSAgACUbYA= Date: Tue, 2 Jun 2015 06:13:29 +0000 Message-ID: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <556CBDDC.6060904@isi.edu> <960E5B02-C324-454A-B627-4ECAAE91E93E@ifi.uio.no> <556CCD07.9080504@isi.edu> In-Reply-To: <556CCD07.9080504@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [198.211.103.24] Content-Type: multipart/signed; boundary="Apple-Mail=_C7CA3DAB-F6C7-4030-BFC9-0EE5F834C83A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02TWUwTURSGvdPpdEoYMgxLLwWMjIgJm0oAiRDcUKqRxJhCjDHCSMe22pam Uwj0CUU0KRpFm7DFyOoDNdpARBAVqYqC0UACPhhkUfABMIKJsojiDMP29p37/+c/9yT34hKq EVPiepOVtZgYA415oJTcLyLq+hFj+s6Zt+EJc+/bpAkupwNNGDyd8GDxDroPVdXXzyMqp3NU omr/8QhVdU3/wo6jpzySNKxBn8dadiRneehGim4g5s6Q/IXWHlkhcGy2AzkOyVjYX9aCiuwP e4ceYnbggVNkHQKdfwelYtEBYPPcNCoWXQBOLM2tFC0ANjiKgNBPkY0AjjsPCoyRkXC8uFYi sC8ZDEcWp2RCg4SsAHD6YxciCD7kfvjqaadMNB2An4s7gMj8iOcuTGCUDIX9VSXLfoLcA2vd k4g4rAyH7XadwHJyO6z7c2k5B/BLzPbcX/ZISAX8NHYXEZfzhaN977DVRf89GV1hGpaWd2Pi 5RwAjlQsAXGYN+yuGENvAli5Iatyo69yg080RcB7NZOSSoDzHAlv1wDxOA5Ovp5Z4URYvtCJ iRwCHSWjsmqAN4JgjdEWZWT0Bo7NjuKyGZOJtUTFRxv11mhWk9sEhGcgS9naChY7aTcgcUB7 Ept+GtIpKZPHFRjdIABHaD/i4mFjOuV1NkdToGM4XaYl18BybhDKz/ricvYCJWrKMbG0LxES x/sIDVNgYy05q7ZAHKUVRNOcl5oitYyVvcCyZtayqgbhOA2JpVS+0dvCatn8c3qDdV1GcLkb QNyTD09UCeGcmTFyeq2o94AQpYLwEQRSEHS5prXe1Sc+ART8Wj5EqeDy5D/AWvcEH4zwwVdJ gxBsZdYlZSFIyzife8hPOVWdWkuc8L/1jaMGY/37MlIH2j/sTqHKr5X9foOnBJlfBBZ9HeYG yhMV9qzJLVnz08Mxe5sjq9RJagWhTQ/rmNk2/vKx+0r1ISmtOtntVTjbljbbMJusHnOFQYUh I9VWZUs5cyx/6Oj3DiK6ICbzcrL5WbwtoD2aRjkdsytcYuGY//p/qGa9AwAA Archived-At: Cc: =?iso-8859-1?Q?Mirja_K=FChlewind?= , Michael Welzl , taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 06:13:37 -0000 --Apple-Mail=_C7CA3DAB-F6C7-4030-BFC9-0EE5F834C83A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with your last statement. We must find a way to distinguish = between the features that an application may require and network = functionalities that derive from those features.=20 Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Jun 1, 2015, at 11:22 PM, Joe Touch wrote: >=20 >=20 >=20 > On 6/1/2015 1:34 PM, Michael Welzl wrote: > .... >>> Segmentation is HOW TCP gives you a reliable byte-sequence service = over >>> a packet service. >>>=20 >>> It is absolutely NOT something provided to the user or under user >>> control. Users can set MTU values on *some systems*, but that's not = part >>> of the TCP API (to the application) nor does MTU necessarily = correspond >>> to actual data boundaries (TCP is allowed to do a lot of things). >>=20 >> Yes, I didn't mean that segmentation is under user control. Let me = rephrase my above sentence: >>=20 >>>> It gives you, via its non-configurable static behavior: >>>> segmentation, congestion control, .... AND it lets you control some >>>> things: PUSH and an URGENT pointer and ... >=20 > But it doesn't "give" you segmentation. It uses segmentation to = provide > a reliable byte stream over a packetized service. If we wanted, we = could > arguably export a TCP service over a circuit that did NOT need to rely > on segmentation. >=20 > This discussion really needs to distinguish between WHAT TCP exports = and > HOW TCP makes that happen - the latter may or may not ever be visible = to > the user. >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_C7CA3DAB-F6C7-4030-BFC9-0EE5F834C83A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDRDCCA0Aw ggKpoAMCAQICEQDvxXGV9K8f4AQSxWSxJJPrMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0 ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTQwNzAyMTM1MzUyWhcN MTUwNzMwMTM1MzUyWjCBqzELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs aWVudCBDQSB2MTEdMBsGA1UEAxMUTWFyaWUtSm9zZSBNb250cGV0aXQxHjAcBgkqhkiG9w0BCQEW D21hcmllam9ATUlULkVEVTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMWfBmhCuS6ol1Q/ KWrhtk0nMP3xU6T6R7Q7y/VnbE6BtYxFaRQ09PzHiv9B58UDhbhNN5y59BVPWWfevOImFitx4PY0 c6wMYGxC6aR0l9VySQ0VNavkRRKujyPxxjz+GRb64mAWzP0xqutz6SaZ2Fi0lxgccRheH/d0OLTg agUCAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBRCoWStx3OeBP0pszhPjQgj z28cdDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRjbGllbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBAHdNroykei2WKB4gO19mPUIyPMBFZrw5f87upM40csBB5HBBtZO4 op6JqoMxs93UrS+KO2+UK8c4zL/lRBRfbmQ7/r+gbJn0YqMb93eEHXR2u07xiRxHrI8oaC9RGhzc NMjbuAPbxlfY55CEPA2LLT/3nibZfvy+UPV/Xdkbg71gMYICtTCCArECAQEwgYEwbDELMAkGA1UE BhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5z dGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/FcZX0rx/gBBLF ZLEkk+swCQYFKw4DAhoFAKCCAYkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNjAyMDYxMzI5WjAjBgkqhkiG9w0BCQQxFgQUouYN+IF9VVe77bixWg7lr+MY1YQw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYAveSTV8xDpIftPKhcoxg0E2G7Hyw0MMRqu Y0J9q/Iapf53TvAQzJe9upvbYDLepezZzeJnHaXg99cmfV5DB6TMA/uCjv4UnduilRKBA/hdXr2d 6wRA0AYEvIBGv3TuR7XMi+QvPlg9leySDiloxYqJGr5u1Un9hbL+pgKfEyTyvAAAAAAAAA== --Apple-Mail=_C7CA3DAB-F6C7-4030-BFC9-0EE5F834C83A-- From nobody Tue Jun 2 07:58:18 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91BB1ACD3B for ; Tue, 2 Jun 2015 07:58:17 -0700 (PDT) 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 dpKDIdSN80bX for ; Tue, 2 Jun 2015 07:58:15 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04ECF1ACD2F for ; Tue, 2 Jun 2015 07:58:14 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so89846576igb.0 for ; Tue, 02 Jun 2015 07:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IuuaVeKJW5iOeHRxkAKAO/YXBHUiIwPjOwjKXDK7YfU=; b=N9CjaEUm0LH4sDsSa4jtY3uP+7bhQra+q7BkzKXPMW4aGVxW68YTdsO2CToy/1NsLf 47SLdHbrGQ+/fxUXBHUxtsj5/nlpZtk27nAeFpZjl3P+xef/MtEl6e0N/gauom/l0GOI I3gvQD+n2dv7j3JvJ0rZDIx8coXyobBZbzdMCHr04o3C8rS3whu5U7OLIKB1QyhdGn7T WlIf/TMiuhobU9Kq4B1O3TGW2tblRHO5QonvfmY/q+2Elgv7/MRnhBFo2dZK7J2g5pu1 OswRc4HwXVoHvmCLzE6o3MH90UmtcdHEMtZNZjbzosHbefCkZH+gZ0Za3M8EaeIkwmqv TOZw== MIME-Version: 1.0 X-Received: by 10.107.170.80 with SMTP id t77mr27488171ioe.31.1433257094377; Tue, 02 Jun 2015 07:58:14 -0700 (PDT) Received: by 10.107.163.74 with HTTP; Tue, 2 Jun 2015 07:58:14 -0700 (PDT) In-Reply-To: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <556CBDDC.6060904@isi.edu> <960E5B02-C324-454A-B627-4ECAAE91E93E@ifi.uio.no> <556CCD07.9080504@isi.edu> Date: Tue, 2 Jun 2015 10:58:14 -0400 Message-ID: From: Aaron Falk To: Marie-Jose Montpetit Content-Type: multipart/alternative; boundary=001a11415d58fb780605178a2b1a Archived-At: Cc: taps WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 14:58:17 -0000 --001a11415d58fb780605178a2b1a Content-Type: text/plain; charset=UTF-8 IMO, this has been an interesting and valuable discussion. One takeaway (for me) is that we have been sloppy in using the terms "interface" as well as "implementation". I think there has been some clarification on the need to document the "interface" for transport protocols. I would further suggest avoiding the term "implementation" which sometimes is used to mean "translate a feature to a mechanism" and sometimes "translate a mechanism to code". Joe's definition of the various meanings of API raise this. --aaron On Tue, Jun 2, 2015 at 2:13 AM, Marie-Jose Montpetit wrote: > I agree with your last statement. We must find a way to distinguish > between the features that an application may require and network > functionalities that derive from those features. > > > > Marie-Jose Montpetit, Ph.D. > mariejo@mit.edu > @SocialTVMIT > > > On Jun 1, 2015, at 11:22 PM, Joe Touch wrote: > > > > > > > > On 6/1/2015 1:34 PM, Michael Welzl wrote: > > .... > >>> Segmentation is HOW TCP gives you a reliable byte-sequence service over > >>> a packet service. > >>> > >>> It is absolutely NOT something provided to the user or under user > >>> control. Users can set MTU values on *some systems*, but that's not > part > >>> of the TCP API (to the application) nor does MTU necessarily correspond > >>> to actual data boundaries (TCP is allowed to do a lot of things). > >> > >> Yes, I didn't mean that segmentation is under user control. Let me > rephrase my above sentence: > >> > >>>> It gives you, via its non-configurable static behavior: > >>>> segmentation, congestion control, .... AND it lets you control some > >>>> things: PUSH and an URGENT pointer and ... > > > > But it doesn't "give" you segmentation. It uses segmentation to provide > > a reliable byte stream over a packetized service. If we wanted, we could > > arguably export a TCP service over a circuit that did NOT need to rely > > on segmentation. > > > > This discussion really needs to distinguish between WHAT TCP exports and > > HOW TCP makes that happen - the latter may or may not ever be visible to > > the user. > > > > Joe > > > > _______________________________________________ > > 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 > > --001a11415d58fb780605178a2b1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IMO, this has been an interesting and valuable discussion.= =C2=A0 One takeaway (for me) is that we have been sloppy in using the terms= "interface" as well as "implementation".=C2=A0 I think= there has been some clarification on the need to document the "interf= ace" for transport protocols.=C2=A0 I would further suggest avoiding t= he term "implementation" which sometimes is used to mean "tr= anslate a feature to a mechanism" =C2=A0and sometimes "translate = a mechanism to code".=C2=A0 Joe's definition of the various meanin= gs of API raise this.

--aaron

On Tue, Jun 2, 2015 at 2:13 AM, = Marie-Jose Montpetit <mariejo@mit.edu> wrote:
I agree with your last statement. We must find a way to d= istinguish between the features that an application may require and network= functionalities that derive from those features.



Marie-Jose Montpetit, Ph.D.
mariejo@mit.edu
@SocialTVMIT

> On Jun 1, 2015, at 11:22 PM, Joe Touch <touch@isi.edu> wrote:
>
>
>
> On 6/1/2015 1:34 PM, Michael Welzl wrote:
> ....
>>> Segmentation is HOW TCP gives you a reliable byte-sequence ser= vice over
>>> a packet service.
>>>
>>> It is absolutely NOT something provided to the user or under u= ser
>>> control. Users can set MTU values on *some systems*, but that&= #39;s not part
>>> of the TCP API (to the application) nor does MTU necessarily c= orrespond
>>> to actual data boundaries (TCP is allowed to do a lot of thing= s).
>>
>> Yes, I didn't mean that segmentation is under user control. Le= t me rephrase my above sentence:
>>
>>>> It gives you, via its non-configurable static behavior: >>>> segmentation, congestion control, .... AND it lets you con= trol some
>>>> things: PUSH and an URGENT pointer and ...
>
> But it doesn't "give" you segmentation. It uses segmenta= tion to provide
> a reliable byte stream over a packetized service. If we wanted, we cou= ld
> arguably export a TCP service over a circuit that did NOT need to rely=
> on segmentation.
>
> This discussion really needs to distinguish between WHAT TCP exports a= nd
> HOW TCP makes that happen - the latter may or may not ever be visible = to
> the user.
>
> Joe
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


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


--001a11415d58fb780605178a2b1a-- From nobody Tue Jun 2 23:22:53 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221DD1A700C for ; Tue, 2 Jun 2015 23:22:50 -0700 (PDT) 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 GQl6LAper2zB for ; Tue, 2 Jun 2015 23:22:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18AC71A1B1C for ; Tue, 2 Jun 2015 23:22:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWW35525; Wed, 03 Jun 2015 06:22:46 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 3 Jun 2015 07:22:45 +0100 Received: from NKGEML509-MBS.china.huawei.com ([169.254.2.68]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 3 Jun 2015 14:22:39 +0800 From: Youjianjie To: "taps@ietf.org" Thread-Topic: New Version Notification for draft-you-taps-3red-model-00.txt Thread-Index: AQHQncKb5u9qDCUfJkqkN6M8E9P/zJ2aTeDg Date: Wed, 3 Jun 2015 06:22:39 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Taps] Fw: New Version Notification for draft-you-taps-3red-model-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 06:22:50 -0000 SGksDQoNClRoaXMgZHJhZnQgcHJvcG9zZXMgYSAzUkVEIG1vZGVsLCBpLmUuIFJhdGUsIFJlc3Bv bnNlLCBSZWxpYWJpbGl0eSwgRWZmaWNpZW5jeSBhbmQgRGlmZmVyZW50aWF0aW9uLCB0byBlbmFi bGUgYXBwbGljYXRpb25zIHRvIG1ha2UgdXNlIG9mIHZhcmlvdXMgdHJhbnNwb3J0IHNlcnZpY2Vz Lg0KWW91ciBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMsDQpKaWFuamllDQoN Ci0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAx NeW5tDbmnIgz5pelIDE0OjAwDQrmlLbku7bkuro6IFlvdWppYW5qaWU7IFlvdWppYW5qaWUNCuS4 u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC15b3UtdGFwcy0zcmVkLW1v ZGVsLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC15b3UtdGFwcy0zcmVk LW1vZGVsLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppYW5qaWUg WW91IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LXlv dS10YXBzLTNyZWQtbW9kZWwNClJldmlzaW9uOgkwMA0KVGl0bGU6CQkzUkVEIE1vZGVsIGZvciBU QVBTDQpEb2N1bWVudCBkYXRlOgkyMDE1LTA2LTAyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz c2lvbg0KUGFnZXM6CQkxMA0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC15b3UtdGFwcy0zcmVkLW1vZGVsLTAwLnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvdS10YXBzLTNy ZWQtbW9kZWwvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXlvdS10YXBzLTNyZWQtbW9kZWwtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1l bnQgZGVmaW5lcyBhIDNSRUQgbW9kZWwgdG8gZGVzY3JpYmUgdHJhbnNwb3J0IHNlcnZpY2UNCiAg IGZlYXR1cmVzLiAgQXBwbGljYXRpb25zIGNhbiBtYWtlIHVzZSBvZiB0aGUgM1JFRCBtb2RlbCB0 byByZXF1ZXN0DQogICB0cmFuc3BvcnQgc2VydmljZXMgZnJvbSB0aGUgVEFQUyBieSBzZW5kaW5n IGEgcmVxdWVzdCB3aGljaCBjb250YWlucw0KICAgdGhlIGV4cGxpY2l0IDNSRUQgcmVxdWlyZW1l bnQgcGFyYW1ldGVycy4gIFRoZSBwdXJwb3NlIG9mIHRoaXMNCiAgIGRvY3VtZW50IGlzIHRvIGVu YWJsZSBhcHBsaWNhdGlvbnMgdG8gbWFrZSB1c2Ugb2YgdmFyaW91cyB0cmFuc3BvcnQNCiAgIHNl cnZpY2VzIHdpdGhvdXQgY3VzdG9taXphdGlvbiBvciByZS1pbXBsZW1lbnRhdGlvbi4NCg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Jun 3 06:26:24 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA98E1A8842 for ; Wed, 3 Jun 2015 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-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 tHKu2VeKl_MX for ; Wed, 3 Jun 2015 06:26:20 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2480D1A8849 for ; Wed, 3 Jun 2015 06:26:20 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z08gU-0000zo-7e for taps@ietf.org; Wed, 03 Jun 2015 15:26:18 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z08gT-0007ik-OI for taps@ietf.org; Wed, 03 Jun 2015 15:26:18 +0200 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 3 Jun 2015 15:26:17 +0200 To: taps WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 5 sum msgs/h 3 total rcpts 29737 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 81CDFBAB7BF4F6B30FD4622E6BFE1316C412B420 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1135 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] A proposal to throw out RTP 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 Jun 2015 13:26:23 -0000 Hi, I know this has been discussed before, but only briefly. I have two = arguments that I'd like to bring forward towards removing RTP (/RTCP) = from draft-ietf-taps-transports-04 and the documents that will follow = it. I understand that it's a non-obvious question whether RTP should be = considered a transport protocol or not, and I don't want to take a side = in this or step on anyone's toes here - these are more practical, = pragmatic considerations, and I'd just like to see how people react. If = folks go crazy in response to this I won't keep arguing, but I'd be = happy if I'd see some agreement: Argument #1: RTP implementations need to be tied closer to the = application than the implementation of transport such as TCP, DCCP, = SCTP. There is usually a very tight interaction with the codec and RTP - = a reaction to one specific incoming RTCP message, for instance. So I'd = rather see a future TAPS system being *used* by RTP instead of = *providing* RTP functionality. Argument #2: TAPS has a non-negligible risk of ending up as an academic = exercise. I understand that but I don't want that - I think we should do = our best to keep TAPS "real". If that is our goal, including the world's = largest protocol isn't perhaps ideal... I think it should be in our = interest to try to keep the list in draft-ietf-taps-transports-04.txt = reasonably contained. Cheers, Michael From nobody Wed Jun 3 07:49:30 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80531A89EB for ; Wed, 3 Jun 2015 07:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 iMDrVi7e4Dne for ; Wed, 3 Jun 2015 07:49:27 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 79B691A89C7 for ; Wed, 3 Jun 2015 07:49:27 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 173261B00071; Wed, 3 Jun 2015 15:49:30 +0100 (BST) Received: from 37.205.56.247 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Wed, 3 Jun 2015 15:48:27 +0100 Message-ID: In-Reply-To: References: Date: Wed, 3 Jun 2015 15:48:27 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" 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: Cc: taps WG Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 14:49:29 -0000 > Hi, > > I know this has been discussed before, but only briefly. I have two > arguments that I'd like to bring forward towards removing RTP (/RTCP) from > draft-ietf-taps-transports-04 and the documents that will follow it. I > understand that it's a non-obvious question whether RTP should be > considered a transport protocol or not, and I don't want to take a side in > this or step on anyone's toes here - these are more practical, pragmatic > considerations, and I'd just like to see how people react. If folks go > crazy in response to this I won't keep arguing, but I'd be happy if I'd > see some agreement: > > Argument #1: RTP implementations need to be tied closer to the application > than the implementation of transport such as TCP, DCCP, SCTP. There is > usually a very tight interaction with the codec and RTP - a reaction to > one specific incoming RTCP message, for instance. So I'd rather see a > future TAPS system being *used* by RTP instead of *providing* RTP > functionality. > I think the same. > Argument #2: TAPS has a non-negligible risk of ending up as an academic > exercise. I understand that but I don't want that - I think we should do > our best to keep TAPS "real". If that is our goal, including the world's > largest protocol isn't perhaps ideal... I think it should be in our > interest to try to keep the list in draft-ietf-taps-transports-04.txt > reasonably contained. > I'd prefer the document not to ignore RTP - but to say enough, so that people can read further should this wish. If the above is correct, then I think perhaps this document can cover this in the introduction, along with a mention perhaps of other framing or content-oriented protocols that can use transports. > Cheers, > Michael > Gorry > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed Jun 3 08:04:46 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A211A8A89 for ; Wed, 3 Jun 2015 08:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNF4e2mDS5ad for ; Wed, 3 Jun 2015 08:04:42 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2821A89ED for ; Wed, 3 Jun 2015 08:04:41 -0700 (PDT) Received: from nb-10604.ethz.ch (nb-10604.ethz.ch [82.130.102.91]) by trammell.ch (Postfix) with ESMTPSA id DE5721A01FE; Wed, 3 Jun 2015 17:04:10 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_65EB9086-2685-45E2-886A-D717C34A5AE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 3 Jun 2015 17:04:10 +0200 Message-Id: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> References: To: Gorry Fairhurst X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Michael Welzl , taps WG Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 15:04:45 -0000 --Apple-Mail=_65EB9086-2685-45E2-886A-D717C34A5AE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 03 Jun 2015, at 16:48, gorry@erg.abdn.ac.uk wrote: >=20 >> Hi, >>=20 >> I know this has been discussed before, but only briefly. I have two >> arguments that I'd like to bring forward towards removing RTP (/RTCP) = from >> draft-ietf-taps-transports-04 and the documents that will follow it. = I >> understand that it's a non-obvious question whether RTP should be >> considered a transport protocol or not, and I don't want to take a = side in >> this or step on anyone's toes here - these are more practical, = pragmatic >> considerations, and I'd just like to see how people react. If folks = go >> crazy in response to this I won't keep arguing, but I'd be happy if = I'd >> see some agreement: >>=20 >> Argument #1: RTP implementations need to be tied closer to the = application >> than the implementation of transport such as TCP, DCCP, SCTP. There = is >> usually a very tight interaction with the codec and RTP - a reaction = to >> one specific incoming RTCP message, for instance. So I'd rather see a >> future TAPS system being *used* by RTP instead of *providing* RTP >> functionality. >>=20 > I think the same. +1 >=20 >> Argument #2: TAPS has a non-negligible risk of ending up as an = academic >> exercise. I understand that but I don't want that - I think we should = do >> our best to keep TAPS "real". If that is our goal, including the = world's >> largest protocol isn't perhaps ideal... I think it should be in our >> interest to try to keep the list in draft-ietf-taps-transports-04.txt >> reasonably contained. >>=20 > I'd prefer the document not to ignore RTP - but to say enough, so that > people can read further should this wish. If the above is correct, = then I > think perhaps this document can cover this in the introduction, along = with > a mention perhaps of other framing or content-oriented protocols that = can > use transports. Agree as well. If we completely ignore RTP, it will be conspicuous in = its absence. I'd suggest a bit of tombstone text in the RTP section that explains the = rationale behind not really digging into RTP for components/features... = I can put together something (based more or less on this message) for = the -05 rev I'm working on... Cheers, Brian >> Cheers, >> Michael >>=20 > Gorry >=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 --Apple-Mail=_65EB9086-2685-45E2-886A-D717C34A5AE1 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 iQEcBAEBCgAGBQJVbxdqAAoJENt3nsOmbNJctWoIAMnk0+vRn/J2bgtgIOLRPKCl D6+tf+fdwH7Oc/rJTfj5WPiWD9xvr+4Rg5ficsWlNB6PDZ+CIu16nJwrgedNSTbd vgYH89NiB2lIKzDa8hiJtGYsERIQZ2y3TFbAavnZttZMqtKjVDKtlg5eSbF8cXKC QnFcqpWD9YpsIObMZCKFNEJuuybVJytAwQC95bZRWny9gLNW8YbpC5gZFJe2KN2e wwOBivjHHRMLntSwxWRWaZ8Ma8qT3J+IpTOB8DWHjfIIrle6iV7UqSMQg0ru6Vav deY4SO2S0Fogk5mlpkvvhnTbtmiQJwRupU9NqWv5zJ+0hs0nuRQ2Azgy/K8SGto= =P4tN -----END PGP SIGNATURE----- --Apple-Mail=_65EB9086-2685-45E2-886A-D717C34A5AE1-- From nobody Wed Jun 3 08:10:59 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973DF1A89F9 for ; Wed, 3 Jun 2015 08:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 nws_h5XmKr9s for ; Wed, 3 Jun 2015 08:10:55 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DD31A8029 for ; Wed, 3 Jun 2015 08:10:55 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so9110658lbb.2 for ; Wed, 03 Jun 2015 08:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s/12krl71U0zU68UPN9HVLwzuIqaCJDHPqcc2BSFtys=; b=DeIbrLmpLLUlAldbWbwzrVoiYqTE3aDIuLk1mVXE6ugFxaT5bhzHNnPNYCqvBsyPn7 g2EpGoD7U/fcCIMnMb1kwr3UfF8JFCeYHmxwj+4W21vS+U5WzypwtdfjWzJ6yhrz2n2y lx6uXMxKEvAtSpTITq345GhdYwk0JZC6/U3JPhDP8fODu0o56x8tAnNqn+n+M+ziCshB fW7LdW+PylpaE/zAkSUDkDkwpOiyQsS/qsVpE3kk7pLdeQOEqAUgLlS8FSuMmA/xbGxb wV3M+ocbfnJ1uSBHtMf+x8o7blTrWxqXH5djH+fskfhGcA+dOIWTiVnZ4VIQJLeUdsH0 4MXg== MIME-Version: 1.0 X-Received: by 10.152.8.102 with SMTP id q6mr2367096laa.27.1433344253660; Wed, 03 Jun 2015 08:10:53 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.25.14.205 with HTTP; Wed, 3 Jun 2015 08:10:53 -0700 (PDT) Received: by 10.25.14.205 with HTTP; Wed, 3 Jun 2015 08:10:53 -0700 (PDT) In-Reply-To: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> Date: Wed, 3 Jun 2015 11:10:53 -0400 X-Google-Sender-Auth: 0sJHAlf3Ux-hadEhs3jQNHoHsAw Message-ID: From: Jon Crowcroft To: Brian Trammell Content-Type: multipart/alternative; boundary=001a11c3658214934105179e77eb Archived-At: Cc: Gorry Fairhurst , Michael Welzl , taps@ietf.org Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 15:10:57 -0000 --001a11c3658214934105179e77eb Content-Type: text/plain; charset=UTF-8 +1 Don't ignore, but dont actively work on... On 3 Jun 2015 11:04, "Brian Trammell" wrote: > > > On 03 Jun 2015, at 16:48, gorry@erg.abdn.ac.uk wrote: > > > >> Hi, > >> > >> I know this has been discussed before, but only briefly. I have two > >> arguments that I'd like to bring forward towards removing RTP (/RTCP) > from > >> draft-ietf-taps-transports-04 and the documents that will follow it. I > >> understand that it's a non-obvious question whether RTP should be > >> considered a transport protocol or not, and I don't want to take a side > in > >> this or step on anyone's toes here - these are more practical, pragmatic > >> considerations, and I'd just like to see how people react. If folks go > >> crazy in response to this I won't keep arguing, but I'd be happy if I'd > >> see some agreement: > >> > >> Argument #1: RTP implementations need to be tied closer to the > application > >> than the implementation of transport such as TCP, DCCP, SCTP. There is > >> usually a very tight interaction with the codec and RTP - a reaction to > >> one specific incoming RTCP message, for instance. So I'd rather see a > >> future TAPS system being *used* by RTP instead of *providing* RTP > >> functionality. > >> > > I think the same. > > +1 > > > > >> Argument #2: TAPS has a non-negligible risk of ending up as an academic > >> exercise. I understand that but I don't want that - I think we should do > >> our best to keep TAPS "real". If that is our goal, including the world's > >> largest protocol isn't perhaps ideal... I think it should be in our > >> interest to try to keep the list in draft-ietf-taps-transports-04.txt > >> reasonably contained. > >> > > I'd prefer the document not to ignore RTP - but to say enough, so that > > people can read further should this wish. If the above is correct, then I > > think perhaps this document can cover this in the introduction, along > with > > a mention perhaps of other framing or content-oriented protocols that can > > use transports. > > Agree as well. If we completely ignore RTP, it will be conspicuous in its > absence. > > I'd suggest a bit of tombstone text in the RTP section that explains the > rationale behind not really digging into RTP for components/features... I > can put together something (based more or less on this message) for the -05 > rev I'm working on... > > Cheers, > > Brian > > >> Cheers, > >> Michael > >> > > Gorry > > > >> _______________________________________________ > >> 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 > > --001a11c3658214934105179e77eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

+1
Don't ignore, but dont actively work on...

On 3 Jun 2015 11:04, "Brian Trammell" = <ietf@trammell.ch> wrote:

> On 03 Jun 2015, at 16:48, gorr= y@erg.abdn.ac.uk wrote:
>
>> Hi,
>>
>> I know this has been discussed before, but only briefly. I have tw= o
>> arguments that I'd like to bring forward towards removing RTP = (/RTCP) from
>> draft-ietf-taps-transports-04 and the documents that will follow i= t. I
>> understand that it's a non-obvious question whether RTP should= be
>> considered a transport protocol or not, and I don't want to ta= ke a side in
>> this or step on anyone's toes here - these are more practical,= pragmatic
>> considerations, and I'd just like to see how people react. If = folks go
>> crazy in response to this I won't keep arguing, but I'd be= happy if I'd
>> see some agreement:
>>
>> Argument #1: RTP implementations need to be tied closer to the app= lication
>> than the implementation of transport such as TCP, DCCP, SCTP. Ther= e is
>> usually a very tight interaction with the codec and RTP - a reacti= on to
>> one specific incoming RTCP message, for instance. So I'd rathe= r see a
>> future TAPS system being *used* by RTP instead of *providing* RTP<= br> >> functionality.
>>
> I think the same.

+1

>
>> Argument #2: TAPS has a non-negligible risk of ending up as an aca= demic
>> exercise. I understand that but I don't want that - I think we= should do
>> our best to keep TAPS "real". If that is our goal, inclu= ding the world's
>> largest protocol isn't perhaps ideal... I think it should be i= n our
>> interest to try to keep the list in draft-ietf-taps-transports-04.= txt
>> reasonably contained.
>>
> I'd prefer the document not to ignore RTP - but to say enough, so = that
> people can read further should this wish. If the above is correct, the= n I
> think perhaps this document can cover this in the introduction, along = with
> a mention perhaps of other framing or content-oriented protocols that = can
> use transports.

Agree as well. If we completely ignore RTP, it will be conspicuous in its a= bsence.

I'd suggest a bit of tombstone text in the RTP section that explains th= e rationale behind not really digging into RTP for components/features... I= can put together something (based more or less on this message) for the -0= 5 rev I'm working on...

Cheers,

Brian

>> Cheers,
>> Michael
>>
> Gorry
>
>> _______________________________________________
>> 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
ht= tps://www.ietf.org/mailman/listinfo/taps

--001a11c3658214934105179e77eb-- From nobody Wed Jun 3 08:58:19 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0784F1A911A for ; Wed, 3 Jun 2015 08:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukDWi0XFD6XX for ; Wed, 3 Jun 2015 08:58:13 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358CB1A911B for ; Wed, 3 Jun 2015 08:58:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C7AA0D930A; Wed, 3 Jun 2015 17:58:11 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TRMjHq8i-gTE; Wed, 3 Jun 2015 17:58:11 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 9370BD9309; Wed, 3 Jun 2015 17:58:11 +0200 (MEST) Message-ID: <556F2413.5040308@tik.ee.ethz.ch> Date: Wed, 03 Jun 2015 17:58:11 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "taps@ietf.org" References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> In-Reply-To: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 15:58:16 -0000 Hi all, On 03.06.2015 17:04, Brian Trammell wrote: > >> On 03 Jun 2015, at 16:48, gorry@erg.abdn.ac.uk wrote: >> >>> Hi, >>> >>> I know this has been discussed before, but only briefly. I have two >>> arguments that I'd like to bring forward towards removing RTP (/RTCP) from >>> draft-ietf-taps-transports-04 and the documents that will follow it. I >>> understand that it's a non-obvious question whether RTP should be >>> considered a transport protocol or not, and I don't want to take a side in >>> this or step on anyone's toes here - these are more practical, pragmatic >>> considerations, and I'd just like to see how people react. If folks go >>> crazy in response to this I won't keep arguing, but I'd be happy if I'd >>> see some agreement: >>> >>> Argument #1: RTP implementations need to be tied closer to the application >>> than the implementation of transport such as TCP, DCCP, SCTP. There is >>> usually a very tight interaction with the codec and RTP - a reaction to >>> one specific incoming RTCP message, for instance. So I'd rather see a >>> future TAPS system being *used* by RTP instead of *providing* RTP >>> functionality. >>> >> I think the same. > > +1 Actually I think I don't agree here. Yes, it's tied closer to the application but I think for taps this is a (good) example where the interface is at a much higher level and therefore might have a value to discuss it. However... (see below) > >> >>> Argument #2: TAPS has a non-negligible risk of ending up as an academic >>> exercise. I understand that but I don't want that - I think we should do >>> our best to keep TAPS "real". If that is our goal, including the world's >>> largest protocol isn't perhaps ideal... I think it should be in our >>> interest to try to keep the list in draft-ietf-taps-transports-04.txt >>> reasonably contained. >>> >> I'd prefer the document not to ignore RTP - but to say enough, so that >> people can read further should this wish. If the above is correct, then I >> think perhaps this document can cover this in the introduction, along with >> a mention perhaps of other framing or content-oriented protocols that can >> use transports. > > Agree as well. If we completely ignore RTP, it will be conspicuous in its absence. > > I'd suggest a bit of tombstone text in the RTP section that explains the rationale behind not really digging into RTP for components/features... I can put together something (based more or less on this message) for the -05 rev I'm working on... ... I agree here. But I think (right now) I would still like to have an own RTP section but be very brief and give some reasoning why we don't wnant to go into further details. Just as a side remark, I don't see any reason to mention RTP in any following documents though. Mirja > > Cheers, > > Brian > >>> Cheers, >>> Michael >>> >> Gorry >> >>> _______________________________________________ >>> 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 > -- ------------------------------------------ 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 Jun 3 09:48:15 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664F01A1EF4 for ; Wed, 3 Jun 2015 09:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipDxRmpucR2b for ; Wed, 3 Jun 2015 09:48:11 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEED41A90D3 for ; Wed, 3 Jun 2015 09:48:10 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0Bpp-0006jk-Bk; Wed, 03 Jun 2015 18:48:09 +0200 Received: from m83-176-92-100.cust.tele2.no ([83.176.92.100]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Z0Bpo-0008P9-B4; Wed, 03 Jun 2015 18:48:09 +0200 References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> Mime-Version: 1.0 (1.0) In-Reply-To: <556F2413.5040308@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <9C1D185E-EE77-43BB-A50B-FAE178E82DB2@ifi.uio.no> X-Mailer: iPhone Mail (11D201) From: Michael Welzl Date: Wed, 3 Jun 2015 18:48:04 +0200 To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 29750 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 47C0CCEF2719EE43D0FEA8267E851CD76A52060E X-UiO-SPAM-Test: remote_host: 83.176.92.100 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 2 max/h 1 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 16:48:13 -0000 i'm fine with all that... Sent from my iPhone > On 3. juni 2015, at 17:58, Mirja K=C3=BChlewind wrote: >=20 > Hi all, >=20 >> On 03.06.2015 17:04, Brian Trammell wrote: >>=20 >>>> On 03 Jun 2015, at 16:48, gorry@erg.abdn.ac.uk wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I know this has been discussed before, but only briefly. I have two >>>> arguments that I'd like to bring forward towards removing RTP (/RTCP) f= rom >>>> draft-ietf-taps-transports-04 and the documents that will follow it. I >>>> understand that it's a non-obvious question whether RTP should be >>>> considered a transport protocol or not, and I don't want to take a side= in >>>> this or step on anyone's toes here - these are more practical, pragmati= c >>>> considerations, and I'd just like to see how people react. If folks go >>>> crazy in response to this I won't keep arguing, but I'd be happy if I'd= >>>> see some agreement: >>>>=20 >>>> Argument #1: RTP implementations need to be tied closer to the applicat= ion >>>> than the implementation of transport such as TCP, DCCP, SCTP. There is >>>> usually a very tight interaction with the codec and RTP - a reaction to= >>>> one specific incoming RTCP message, for instance. So I'd rather see a >>>> future TAPS system being *used* by RTP instead of *providing* RTP >>>> functionality. >>> I think the same. >>=20 >> +1 >=20 > Actually I think I don't agree here. Yes, it's tied closer to the applicat= ion but I think for taps this is a (good) example where the interface is at a= much higher level and therefore might have a value to discuss it. However..= . (see below) >=20 >>=20 >>>=20 >>>> Argument #2: TAPS has a non-negligible risk of ending up as an academic= >>>> exercise. I understand that but I don't want that - I think we should d= o >>>> our best to keep TAPS "real". If that is our goal, including the world'= s >>>> largest protocol isn't perhaps ideal... I think it should be in our >>>> interest to try to keep the list in draft-ietf-taps-transports-04.txt >>>> reasonably contained. >>> I'd prefer the document not to ignore RTP - but to say enough, so that >>> people can read further should this wish. If the above is correct, then I= >>> think perhaps this document can cover this in the introduction, along wi= th >>> a mention perhaps of other framing or content-oriented protocols that ca= n >>> use transports. >>=20 >> Agree as well. If we completely ignore RTP, it will be conspicuous in its= absence. >>=20 >> I'd suggest a bit of tombstone text in the RTP section that explains the r= ationale behind not really digging into RTP for components/features... I can= put together something (based more or less on this message) for the -05 rev= I'm working on... >=20 > ... I agree here. But I think (right now) I would still like to have an ow= n RTP section but be very brief and give some reasoning why we don't wnant t= o go into further details. Just as a side remark, I don't see any reason to m= ention RTP in any following documents though. >=20 > Mirja >=20 >=20 >>=20 >> Cheers, >>=20 >> Brian >>=20 >>>> Cheers, >>>> Michael >>> Gorry >>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > --=20 > ------------------------------------------ > Dipl.-Ing. Mirja K=C3=BChlewind > Communication Systems Group > Institute TIK, ETH Z=C3=BCrich > Gloriastrasse 35, 8092 Z=C3=BCrich, Switzerland >=20 > Room ETZ G93 > phone: +41 44 63 26932 > email: mirja.kuehlewind@tik.ee.ethz.ch > ------------------------------------------ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Jun 3 11:44:12 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5FF1AD356 for ; Wed, 3 Jun 2015 11:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 ruoidR_WRPh2 for ; Wed, 3 Jun 2015 11:44:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFD81AD357 for ; Wed, 3 Jun 2015 11:44:10 -0700 (PDT) Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 3 Jun 2015 18:44:09 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0172.012; Wed, 3 Jun 2015 18:44:09 +0000 From: Christian Huitema To: =?iso-8859-1?Q?Mirja_K=FChlewind?= , "taps@ietf.org" Thread-Topic: [Taps] A proposal to throw out RTP Thread-Index: AQHQngDlrRXvG4zeAEaMx4AZHjZg+52a3LCAgAAEZQCAAA8XgIAAK/lA Date: Wed, 3 Jun 2015 18:44:09 +0000 Message-ID: References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> In-Reply-To: <556F2413.5040308@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [131.107.159.254] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 3:OK1Qh7k/ejwNuhWnbj5xp6pjTom341HTWNuC+17uulRHAp2TkfGaYVPwASjnYDULurnM3z6SpWtbi3/9f+9pA5BaeCwTU2k1HD7UvEIvryR50LSKhdM4MzV5tNYrbUvyJcuqeF7TFxwzO60/m5kysA==; 10:tOK+p6xGj0IMvw7dSS5FgN/mlE2y4d5Zxkj5OPHL6EVM5kG3I8CkVfjw6IBTRq3KDNYYgyLZ2t0F0lorLeznyZkT/5UT7qlA+mD+yfbWVH0=; 6:63A7ySsXGbdNbbWg+05vopa9gonkWqb68shjwvUoU+hRVD4GzaG6eJDg1qa/wC+h x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520003)(5005006)(3002001); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656; x-forefront-prvs: 05961EBAFC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(46102003)(54356999)(50986999)(76176999)(74316001)(64706001)(2501003)(122556002)(40100003)(101416001)(62966003)(77156002)(66066001)(86612001)(87936001)(86362001)(76576001)(102836002)(92566002)(5002640100001)(189998001)(106116001)(68736005)(77096005)(2900100001)(5001960100002)(106356001)(2656002)(81156007)(99286002)(2950100001)(4001540100001)(5001860100001)(5001770100001)(33656002)(97736004)(105586002)(5001830100001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2015 18:44:09.3414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656 Archived-At: Cc: Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 18:44:12 -0000 > Actually I think I don't agree here. Yes, it's tied closer to the applica= tion but I > think for taps this is a (good) example where the interface is at a much = higher > level and therefore might have a value to discuss it. However... (see bel= ow) I don't quite agree either. RTP is an extreme example of the split between "generic transport library" = and "application specific transport implementation." There are quite a few = RTP functions that are seldom found in other transports, but are worth cons= idering: 1) The use of timestamps. This is quite fundamental for "real time" applica= tions that need to synchronize the rendering of different media streams. 2) The tolerance for losses. This requires alignment of transmission units = to "natural" media boundaries such as audio or video frames, or compression= units within video frames. 3) The practice of FEC, including variable rate FEC. This is quite common i= n video transmission. A given frame will be transmitted as N data packets p= lus P redundancy packets, where N and P depend on size and importance of th= e frame, e.g. anchor frame versus delta. -- Christian Huitema From nobody Wed Jun 3 13:08:01 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E320F1A0282 for ; Wed, 3 Jun 2015 13:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btnwdZN6_ceR for ; Wed, 3 Jun 2015 13:07:57 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D391A7028 for ; Wed, 3 Jun 2015 13:07:56 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0Ex8-0008WI-8D; Wed, 03 Jun 2015 22:07:54 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0Ex7-0003hi-Mw; Wed, 03 Jun 2015 22:07:54 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Wed, 3 Jun 2015 22:07:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> To: Christian Huitema X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 29757 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AFB926071B11CCE728F1EDA36176143DCD8259D7 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1143 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 20:08:00 -0000 Okay, I promised I won't insist, and I don't... still contributing to = the tech debate here: In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just = to be clear, I agree about mentioning RTP in the draft and I agree that = it provides important functions! The question is whether RTP's functions = should belong to the TAPS "service set" (which in fact is going to be = defined in the group's second item, but this depends on the first...). > On 3. jun. 2015, at 20.44, Christian Huitema = wrote: >=20 >> Actually I think I don't agree here. Yes, it's tied closer to the = application but I >> think for taps this is a (good) example where the interface is at a = much higher >> level and therefore might have a value to discuss it. However... (see = below) >=20 > I don't quite agree either. >=20 > RTP is an extreme example of the split between "generic transport = library" and "application specific transport implementation." There are = quite a few RTP functions that are seldom found in other transports, but = are worth considering: >=20 > 1) The use of timestamps. This is quite fundamental for "real time" = applications that need to synchronize the rendering of different media = streams. Agreed - but that would make sense and work *over* pretty much every = transport protocol, right? > 2) The tolerance for losses. This requires alignment of transmission = units to "natural" media boundaries such as audio or video frames, or = compression units within video frames. ... which just means that RTP has to run over a transport that allows = the application to control message boundaries. > 3) The practice of FEC, including variable rate FEC. This is quite = common in video transmission. A given frame will be transmitted as N = data packets plus P redundancy packets, where N and P depend on size and = importance of the frame, e.g. anchor frame versus delta. ... which is indeed very closely tied to the application, and might not = be the kind of thing you want to have in a generic layer, but you could = implement it on top? Cheers, Michael From nobody Wed Jun 3 14:26:37 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E651ACD66 for ; Wed, 3 Jun 2015 14:26:36 -0700 (PDT) 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 gmLQ7KWw8U51 for ; Wed, 3 Jun 2015 14:26:34 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EF91A8AFC for ; Wed, 3 Jun 2015 14:26:33 -0700 (PDT) Received: by wiga1 with SMTP id a1so28274812wig.0 for ; Wed, 03 Jun 2015 14:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VRGLwigkATSE8z408+fUkm9d0HE8rfxuzkQ5S5H272w=; b=L8E4TP2jCTgzgHMryNJ7DIdGfaJLD0fQ7KnpP8SpZT/u1rJDt5qusxAC4YJdmuT1q8 d/LWX7OLX9iBVDuRenO8HLbcikzZI3i/1k3DxfYCl00ynMORLu4PwGf+fjFJGxsz5Ya1 2aG4CoaLQMvBDfgBm2+/DtTddFx41E+9sR0QqwtTh10FGwWEIrLZtbADWP/r/7ywbwlx fHhSC2ZBDRr8u5qqTGMZoxsIsIaW4vfzFv26PP26snajTGqqftkpgAypWvtRRVQ7AcDQ WYmCAlB695JtyL4nM5bXF71d7KZO893jIwTar0VDwDmG3GVkVblQrh4Ek7ft/Luebg3a i9rA== MIME-Version: 1.0 X-Received: by 10.194.237.34 with SMTP id uz2mr6329307wjc.155.1433366792740; Wed, 03 Jun 2015 14:26:32 -0700 (PDT) Received: by 10.28.145.7 with HTTP; Wed, 3 Jun 2015 14:26:32 -0700 (PDT) In-Reply-To: <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> Date: Wed, 3 Jun 2015 23:26:32 +0200 Message-ID: From: Mohamed Oulmahdi To: Michael Welzl Content-Type: multipart/alternative; boundary=089e01493c6e83a6810517a3b6df Archived-At: Cc: Christian Huitema , "taps@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 21:26:36 -0000 --089e01493c6e83a6810517a3b6df Content-Type: text/plain; charset=UTF-8 I think that speaking specifically about any protocol in this document will not be in the sens of an "abstract" interface for the Transport layer, because abstraction means that application will no longer be aware of who or what Transport services are really offered. But in the same time, this abstract interface should cover all the protocols aspects, and so, applications should not see a difference in the offered service, i.e. some services (or functionalities) which are no longer available. I think that this list of services is too short and must be extended to add more services, especially those already offered, like data encryption for example, or message-oriented transmission ... On Wed, Jun 3, 2015 at 10:07 PM, Michael Welzl wrote: > Okay, I promised I won't insist, and I don't... still contributing to the > tech debate here: > > In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just to > be clear, I agree about mentioning RTP in the draft and I agree that it > provides important functions! The question is whether RTP's functions > should belong to the TAPS "service set" (which in fact is going to be > defined in the group's second item, but this depends on the first...). > > > > On 3. jun. 2015, at 20.44, Christian Huitema > wrote: > > > >> Actually I think I don't agree here. Yes, it's tied closer to the > application but I > >> think for taps this is a (good) example where the interface is at a > much higher > >> level and therefore might have a value to discuss it. However... (see > below) > > > > I don't quite agree either. > > > > RTP is an extreme example of the split between "generic transport > library" and "application specific transport implementation." There are > quite a few RTP functions that are seldom found in other transports, but > are worth considering: > > > > 1) The use of timestamps. This is quite fundamental for "real time" > applications that need to synchronize the rendering of different media > streams. > > Agreed - but that would make sense and work *over* pretty much every > transport protocol, right? > > > > 2) The tolerance for losses. This requires alignment of transmission > units to "natural" media boundaries such as audio or video frames, or > compression units within video frames. > > ... which just means that RTP has to run over a transport that allows the > application to control message boundaries. > > > > 3) The practice of FEC, including variable rate FEC. This is quite > common in video transmission. A given frame will be transmitted as N data > packets plus P redundancy packets, where N and P depend on size and > importance of the frame, e.g. anchor frame versus delta. > > ... which is indeed very closely tied to the application, and might not be > the kind of thing you want to have in a generic layer, but you could > implement it on top? > > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --089e01493c6e83a6810517a3b6df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that speaking specifically about any protocol= in this document will not be in the sens of an "abstract" interf= ace for the Transport layer, because abstraction means that application wil= l no longer be aware of who or what Transport services are really offered. = But in the same time, this abstract interface should cover all the protocol= s aspects, and so, applications should not see a difference in the offered = service, i.e. some services (or functionalities) which are no longer availa= ble. I think that this list of services is too short and must be extended t= o add more services, especially those already offered, like data encryption= for example, or message-oriented transmission ...=C2=A0

=

On Wed, Jun= 3, 2015 at 10:07 PM, Michael Welzl <michawe@ifi.uio.no> wr= ote:
Okay, I promised I won't insist,= and I don't... still contributing to the tech debate here:

In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just = to be clear, I agree about mentioning RTP in the draft and I agree that it = provides important functions! The question is whether RTP's functions s= hould belong to the TAPS "service set" (which in fact is going to= be defined in the group's second item, but this depends on the first..= .).


> On 3. jun. 2015, at 20.44, Christian Huitema <huitema@microsoft.com> wrote:
>
>> Actually I think I don't agree here. Yes, it's tied closer= to the application but I
>> think for taps this is a (good) example where the interface is at = a much higher
>> level and therefore might have a value to discuss it. However... (= see below)
>
> I don't quite agree either.
>
> RTP is an extreme example of the split between "generic transport= library" and "application specific transport implementation.&quo= t; There are quite a few RTP functions that are seldom found in other trans= ports, but are worth considering:
>
> 1) The use of timestamps. This is quite fundamental for "real tim= e" applications that need to synchronize the rendering of different me= dia streams.

Agreed - but that would make sense and work *over* pretty much every= transport protocol, right?


> 2) The tolerance for losses. This requires alignment of transmission u= nits to "natural" media boundaries such as audio or video frames,= or compression units within video frames.

... which just means that RTP has to run over a transport that allow= s the application to control message boundaries.


> 3) The practice of FEC, including variable rate FEC. This is quite com= mon in video transmission. A given frame will be transmitted as N data pack= ets plus P redundancy packets, where N and P depend on size and importance = of the frame, e.g. anchor frame versus delta.

... which is indeed very closely tied to the application, and might = not be the kind of thing you want to have in a generic layer, but you could= implement it on top?


Cheers,
Michael

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

--089e01493c6e83a6810517a3b6df-- From nobody Wed Jun 3 15:11:24 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBB91A8957 for ; Wed, 3 Jun 2015 15:11:22 -0700 (PDT) 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 HeFhdTYV9H4G for ; Wed, 3 Jun 2015 15:11:19 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8655B1A0029 for ; Wed, 3 Jun 2015 15:11:18 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0GsT-0001QF-Hf; Thu, 04 Jun 2015 00:11:13 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0GsR-0005Vq-Uk; Thu, 04 Jun 2015 00:11:13 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_E95A2B26-B78B-44FC-B9CC-78D2E0A693F0" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Thu, 4 Jun 2015 00:11:10 +0200 Message-Id: References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> To: Mohamed Oulmahdi X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 29766 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5DE9AA116B03F2236F10BBD38A46AA8208FC3B7A X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1146 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Christian Huitema , "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 22:11:23 -0000 --Apple-Mail=_E95A2B26-B78B-44FC-B9CC-78D2E0A693F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 nono. read the charter. it says that we=E2=80=99ll: "1) Define a set of Transport Services, identifying the=20 services provided by existing IETF protocols and congestion=20 control mechanisms. As a starting point, the working group will=20 consider services used=20 between two endpoints.=E2=80=9D This is bottom-up, and let=E2=80=99s start this as small as =E2=80=A6 = feasible. Cheers, Michael > On 3. jun. 2015, at 23.26, Mohamed Oulmahdi = wrote: >=20 > I think that speaking specifically about any protocol in this document = will not be in the sens of an "abstract" interface for the Transport = layer, because abstraction means that application will no longer be = aware of who or what Transport services are really offered. But in the = same time, this abstract interface should cover all the protocols = aspects, and so, applications should not see a difference in the offered = service, i.e. some services (or functionalities) which are no longer = available. I think that this list of services is too short and must be = extended to add more services, especially those already offered, like = data encryption for example, or message-oriented transmission ...=20 >=20 >=20 > On Wed, Jun 3, 2015 at 10:07 PM, Michael Welzl > wrote: > Okay, I promised I won't insist, and I don't... still contributing to = the tech debate here: >=20 > In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just = to be clear, I agree about mentioning RTP in the draft and I agree that = it provides important functions! The question is whether RTP's functions = should belong to the TAPS "service set" (which in fact is going to be = defined in the group's second item, but this depends on the first...). >=20 >=20 > > On 3. jun. 2015, at 20.44, Christian Huitema > wrote: > > > >> Actually I think I don't agree here. Yes, it's tied closer to the = application but I > >> think for taps this is a (good) example where the interface is at a = much higher > >> level and therefore might have a value to discuss it. However... = (see below) > > > > I don't quite agree either. > > > > RTP is an extreme example of the split between "generic transport = library" and "application specific transport implementation." There are = quite a few RTP functions that are seldom found in other transports, but = are worth considering: > > > > 1) The use of timestamps. This is quite fundamental for "real time" = applications that need to synchronize the rendering of different media = streams. >=20 > Agreed - but that would make sense and work *over* pretty much every = transport protocol, right? >=20 >=20 > > 2) The tolerance for losses. This requires alignment of transmission = units to "natural" media boundaries such as audio or video frames, or = compression units within video frames. >=20 > ... which just means that RTP has to run over a transport that allows = the application to control message boundaries. >=20 >=20 > > 3) The practice of FEC, including variable rate FEC. This is quite = common in video transmission. A given frame will be transmitted as N = data packets plus P redundancy packets, where N and P depend on size and = importance of the frame, e.g. anchor frame versus delta. >=20 > ... which is indeed very closely tied to the application, and might = not be the kind of thing you want to have in a generic layer, but you = could implement it on top? >=20 >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = >=20 --Apple-Mail=_E95A2B26-B78B-44FC-B9CC-78D2E0A693F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 nono. read the charter. it says that we=E2=80=99ll:

"1) Define a set of = Transport Services, identifying the 
services = provided by existing IETF protocols and congestion 
control mechanisms. As a starting point, the working group = will 
consider services used 
between two endpoints.=E2=80=9D

This is bottom-up, and let=E2=80=99s = start this as small as =E2=80=A6 feasible.

Cheers,
Michael


On 3. jun. 2015, at 23.26, Mohamed Oulmahdi <m.oulmahdi@gmail.com> wrote:

I think that speaking specifically about any = protocol in this document will not be in the sens of an "abstract" = interface for the Transport layer, because abstraction means that = application will no longer be aware of who or what Transport services = are really offered. But in the same time, this abstract interface should = cover all the protocols aspects, and so, applications should not see a = difference in the offered service, i.e. some services (or = functionalities) which are no longer available. I think that this list = of services is too short and must be extended to add more services, = especially those already offered, like data encryption for example, or = message-oriented transmission ... 


On Wed, Jun 3, 2015 at 10:07 PM, = Michael Welzl <michawe@ifi.uio.no> wrote:
Okay, I promised I = won't insist, and I don't... still contributing to the tech debate = here:

In line - essentially, I'm suggesting RTP-over-TAPS here. BTW and just = to be clear, I agree about mentioning RTP in the draft and I agree that = it provides important functions! The question is whether RTP's functions = should belong to the TAPS "service set" (which in fact is going to be = defined in the group's second item, but this depends on the = first...).


> On 3. jun. 2015, at 20.44, Christian Huitema <huitema@microsoft.com> wrote:
>
>> Actually I think I don't agree here. Yes, it's tied closer to = the application but I
>> think for taps this is a (good) example where the interface is = at a much higher
>> level and therefore might have a value to discuss it. = However... (see below)
>
> I don't quite agree either.
>
> RTP is an extreme example of the split between "generic transport = library" and "application specific transport implementation." There are = quite a few RTP functions that are seldom found in other transports, but = are worth considering:
>
> 1) The use of timestamps. This is quite fundamental for "real time" = applications that need to synchronize the rendering of different media = streams.

Agreed - but that would make sense and work *over* pretty much = every transport protocol, right?


> 2) The tolerance for losses. This requires alignment of = transmission units to "natural" media boundaries such as audio or video = frames, or compression units within video frames.

... which just means that RTP has to run over a transport that = allows the application to control message boundaries.


> 3) The practice of FEC, including variable rate FEC. This is quite = common in video transmission. A given frame will be transmitted as N = data packets plus P redundancy packets, where N and P depend on size and = importance of the frame, e.g. anchor frame versus delta.

... which is indeed very closely tied to the application, and = might not be the kind of thing you want to have in a generic layer, but = you could implement it on top?


Cheers,
Michael

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps


= --Apple-Mail=_E95A2B26-B78B-44FC-B9CC-78D2E0A693F0-- From nobody Wed Jun 3 22:45:50 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8981A0089 for ; Wed, 3 Jun 2015 22:45:49 -0700 (PDT) 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 XoUhpu2Egtw3 for ; Wed, 3 Jun 2015 22:45:47 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB661A004C for ; Wed, 3 Jun 2015 22:45:46 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-79-556fe6094e22 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E6.D5.03325.906EF655; Thu, 4 Jun 2015 01:45:45 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t545jiuF014800; Thu, 4 Jun 2015 01:45:44 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (oc11exedge3.exchange.mit.edu [18.9.3.21]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t545jg8H021882; Thu, 4 Jun 2015 01:45:43 -0400 Received: from W92EXCAS20.exchange.mit.edu (18.7.71.33) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Jun 2015 01:45:31 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.162]) by W92EXCAS20.exchange.mit.edu ([18.7.71.33]) with mapi id 14.03.0158.001; Thu, 4 Jun 2015 01:45:34 -0400 From: Marie-Jose Montpetit To: Christian Huitema Thread-Topic: [Taps] A proposal to throw out RTP Thread-Index: AQHQngDl/9vgiWyJhkSTMiyQ20ZM452bH7+AgAAEZACAAA8XgIAALl+AgAB1v2Q= Date: Thu, 4 Jun 2015 05:45:34 +0000 Message-ID: <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPKsWRmVeSWpSXmKPExsUixCmqrcv5LD/U4OR1XYumz32MFhtb3rFZ bFg9hcXiTowDi8eSJT+ZPFp3/GX3OPbhK5vHk/0zWQJYorhsUlJzMstSi/TtErgydq1+zVyw lrdiw9yVLA2Mn7m6GDk5JARMJF5tuskEYYtJXLi3nq2LkYtDSGAxk8Ty0/9ZIZz9jBKf7zxl hHCOMUp0fjjEDuFsY5S4+LkBylnFKDH93AtGkGFsAjoST1sXMYPYIgK6EvtaDoLNYhaYyiix 7dEmsISwgL7E3nezGCGKDCT+tOxigrD9JJZNWA1mswioSPydeZIVxOYVsJKYt2Ia1B0rmCR2 TtgIVsQpkChx49U1sKGMQG98P7UGLM4sIC5x68l8qPcEJRbN3sMM8+q/XQ/ZIGr0JG5MnQJl a0ssW/iaGWKZoMTJmU9YJjBKzEIyahaSlllIWmYhaVnAyLKKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI11wvN7NELzWldBMjKF7ZXVR2MDYfUjrEKMDBqMTDa3EsP1SINbGsuDL3EKMkB5OSKK/R A6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV6/00A53pTEyqrUonyYlDQHi5I476YffCFCAumJ JanZqakFqUUwWRkODiUJ3ownQI2CRanpqRVpmTklCGkmDk6Q4TxAwy+C1PAWFyTmFmemQ+RP MSpKifPuA0kIgCQySvPgemHp9BWjONArwryKIFU8wFQM1/0KaDAT0OB2gRyQwSWJCCmpBkYW bn6Nu6cvvG5ednrmlB3qd3dKVxbXy151LmNLUNm6M3f2ukDHv0fXdbwz2LTEX4H7j+nWhfWt T9tOmT78oVemG1amrsj/2WuRsp1IQN+T8zvnT/W9bnzlvMLy/LNnJOXK6idpvutKPH9OT9j0 4upwwaw4B7ELv1V1fuV7/vultPeyvO+jk4xKLMUZiYZazEXFiQBbWM6wggMAAA== Archived-At: Cc: Brian Trammell , =?iso-8859-1?Q?Mirja_K=FChlewind?= , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 05:45:50 -0000 In my presentation in Dallas I had suggested adding RTP (and even HTTP) bec= ause as both Mirja and Christian mention some 'applications' are requesting= functionalities that are got given elsewhere. Marie-Jos=E9 Montpetit marie@mjmontpetit.com mariejo@mit.edu On Jun 3, 2015, at 20:44, Christian Huitema wrote: >> Actually I think I don't agree here. Yes, it's tied closer to the applic= ation but I >> think for taps this is a (good) example where the interface is at a much= higher >> level and therefore might have a value to discuss it. However... (see be= low) >=20 > I don't quite agree either. >=20 > RTP is an extreme example of the split between "generic transport library= " and "application specific transport implementation." There are quite a fe= w RTP functions that are seldom found in other transports, but are worth co= nsidering: >=20 > 1) The use of timestamps. This is quite fundamental for "real time" appli= cations that need to synchronize the rendering of different media streams. >=20 > 2) The tolerance for losses. This requires alignment of transmission unit= s to "natural" media boundaries such as audio or video frames, or compressi= on units within video frames. >=20 > 3) The practice of FEC, including variable rate FEC. This is quite common= in video transmission. A given frame will be transmitted as N data packets= plus P redundancy packets, where N and P depend on size and importance of = the frame, e.g. anchor frame versus delta. >=20 > -- Christian Huitema >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 4 00:37:25 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E951ACDBB for ; Thu, 4 Jun 2015 00:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoyOEyTMD02Y for ; Thu, 4 Jun 2015 00:37:21 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B76E1A1A99 for ; Thu, 4 Jun 2015 00:37:20 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0PiF-0002CO-P3; Thu, 04 Jun 2015 09:37:15 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0PiF-0007JL-2w; Thu, 04 Jun 2015 09:37:15 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> Date: Thu, 4 Jun 2015 09:37:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 13 sum msgs/h 4 total rcpts 29776 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E9A5F7CD10AFAA8FF76AD75CFCF9D78B80EBAE36 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 7202 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Christian Huitema , "taps@ietf.org" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 07:37:23 -0000 Well... it's a typical engineering trade-off decision to make... > On 04 Jun 2015, at 07:45, Marie-Jose Montpetit = wrote: >=20 > In my presentation in Dallas I had suggested adding RTP (and even = HTTP) because as both Mirja and Christian mention some 'applications' = are requesting functionalities that are got given elsewhere. >=20 > Marie-Jos=E9 Montpetit > marie@mjmontpetit.com > mariejo@mit.edu >=20 > On Jun 3, 2015, at 20:44, Christian Huitema = wrote: >=20 >>> Actually I think I don't agree here. Yes, it's tied closer to the = application but I >>> think for taps this is a (good) example where the interface is at a = much higher >>> level and therefore might have a value to discuss it. However... = (see below) >>=20 >> I don't quite agree either. >>=20 >> RTP is an extreme example of the split between "generic transport = library" and "application specific transport implementation." There are = quite a few RTP functions that are seldom found in other transports, but = are worth considering: >>=20 >> 1) The use of timestamps. This is quite fundamental for "real time" = applications that need to synchronize the rendering of different media = streams. >>=20 >> 2) The tolerance for losses. This requires alignment of transmission = units to "natural" media boundaries such as audio or video frames, or = compression units within video frames. >>=20 >> 3) The practice of FEC, including variable rate FEC. This is quite = common in video transmission. A given frame will be transmitted as N = data packets plus P redundancy packets, where N and P depend on size and = importance of the frame, e.g. anchor frame versus delta. >>=20 >> -- Christian Huitema >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 4 01:33:08 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCEE1ACDBB for ; Thu, 4 Jun 2015 01:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbkA9geQkieA for ; Thu, 4 Jun 2015 01:33:04 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 77A991A92EA for ; Thu, 4 Jun 2015 01:33:04 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 6547F1A0244; Thu, 4 Jun 2015 10:32:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FE02081A-5DC8-48D8-B51C-07240A365098"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Brian Trammell In-Reply-To: Date: Thu, 4 Jun 2015 10:32:32 +0200 Message-Id: References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> To: Michael Welzl , Varun Singh X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Christian Huitema , "taps@ietf.org" , Marie-Jose Montpetit , =?utf-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 08:33:07 -0000 --Apple-Mail=_FE02081A-5DC8-48D8-B51C-07240A365098 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sounds to me like we know we want to cover some of the unique = features/components of RTP without having to go to the trouble of = wedging a full description of the protocol (as in the other section) = into the doc, a task complicated by the fact that RTP assumes a more = fluid separation of responsibility among itself, its undertransport(s), = and its specific application than is the case with other protocols. So I would suggest the following: we have an abbreviated RTP section in = this document that (1) points out this difference as potentially = architecturally interesting (which itself might be input to the third = charter item) and (2) enumerates only those features which are unique to = RTP among protocols treated in the document. (Varun, as current pen-holder on the RTP section, does this make sense = to you?) Cheers, Brian Sent from my iPhone > On 04 Jun 2015, at 09:37, Michael Welzl wrote: >=20 > Well... it's a typical engineering trade-off decision to make... >=20 >=20 >> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit = wrote: >>=20 >> In my presentation in Dallas I had suggested adding RTP (and even = HTTP) because as both Mirja and Christian mention some 'applications' = are requesting functionalities that are got given elsewhere. >>=20 >> Marie-Jos=C3=A9 Montpetit >> marie@mjmontpetit.com >> mariejo@mit.edu >>=20 >> On Jun 3, 2015, at 20:44, Christian Huitema = wrote: >>=20 >>>> Actually I think I don't agree here. Yes, it's tied closer to the = application but I >>>> think for taps this is a (good) example where the interface is at a = much higher >>>> level and therefore might have a value to discuss it. However... = (see below) >>>=20 >>> I don't quite agree either. >>>=20 >>> RTP is an extreme example of the split between "generic transport = library" and "application specific transport implementation." There are = quite a few RTP functions that are seldom found in other transports, but = are worth considering: >>>=20 >>> 1) The use of timestamps. This is quite fundamental for "real time" = applications that need to synchronize the rendering of different media = streams. >>>=20 >>> 2) The tolerance for losses. This requires alignment of transmission = units to "natural" media boundaries such as audio or video frames, or = compression units within video frames. >>>=20 >>> 3) The practice of FEC, including variable rate FEC. This is quite = common in video transmission. A given frame will be transmitted as N = data packets plus P redundancy packets, where N and P depend on size and = importance of the frame, e.g. anchor frame versus delta. >>>=20 >>> -- Christian Huitema >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail=_FE02081A-5DC8-48D8-B51C-07240A365098 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 iQEcBAEBCgAGBQJVcA0gAAoJENt3nsOmbNJcl58IAJ4PT16AL2/S8nqI+vmqhnte VeCw3uKPXbMVGEKQ71TKZFvxC3dl8vvjGu/wBs3F/VHITAaMC6YmLmM5Bn5pmvEs nj/szmFn1UG1GMYBNRinltBrK42gg0ninuapTiBzmcZRBMfHgA7hoHqeuD4lzhb5 DEo6FmO9UkZCTTU3Y69zjZ8EDhUZkUzCAlFwSEpt/DEtd1EuK8XjcF3I38HKNyv1 2oN7ERJici61kTBkCW8s7Qurh1PthpDbfDc8PKflVxIuyhvt4fIQaank3ZhUQZbs FY15+hS8Z4RSBrKl/7cJG8AWxxALP7i8aSGPSFzBsgUHPHH3IBwIJo0EMA018ao= =5W1/ -----END PGP SIGNATURE----- --Apple-Mail=_FE02081A-5DC8-48D8-B51C-07240A365098-- From nobody Thu Jun 4 02:51:11 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327711B324D for ; Thu, 4 Jun 2015 02:51:10 -0700 (PDT) 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 GqU20nqly5ok for ; Thu, 4 Jun 2015 02:51:08 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A021B3255 for ; Thu, 4 Jun 2015 02:51:06 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-bf-55701f88b0b6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id E2.4C.03325.88F10755; Thu, 4 Jun 2015 05:51:04 -0400 (EDT) Received: from outgoing-exchange-1.mit.edu (outgoing-exchange-1.mit.edu [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t549p3nq020607; Thu, 4 Jun 2015 05:51:04 -0400 Received: from OC11EXEDGE3.EXCHANGE.MIT.EDU (oc11exedge3.exchange.mit.edu [18.9.3.21]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t549p1xN027272; Thu, 4 Jun 2015 05:51:02 -0400 Received: from W92EXHUB14.exchange.mit.edu (18.7.73.25) by OC11EXEDGE3.EXCHANGE.MIT.EDU (18.9.3.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Jun 2015 05:50:51 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.162]) by W92EXHUB14.exchange.mit.edu ([18.7.73.25]) with mapi id 14.03.0158.001; Thu, 4 Jun 2015 05:51:01 -0400 From: Marie-Jose Montpetit To: Michael Welzl Thread-Topic: [Taps] A proposal to throw out RTP Thread-Index: AQHQngDl/9vgiWyJhkSTMiyQ20ZM452bH7+AgAAEZACAAA8XgIAALl+AgAB1v2SAAGI/gIAAJWEA Date: Thu, 4 Jun 2015 09:51:00 +0000 Message-ID: References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [149.154.221.88] Content-Type: multipart/signed; boundary="Apple-Mail=_0A2123F9-32B2-4228-A71D-92CD60A86BF2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02TWUwTURiFvTPT6VAYMy1orwVcxoZEBEHUWKsSNT70ReODPEgUHO2FNrbT plNQ3AJUE7dAjRihiYKKCxQRNRogEksTCEtkiXGJoqaEvmBiUIKIS+NMR5S38+d85/z5k3sp XPOY1FFW3o1cPGdjSRWhUWbr088sceZkejtWG8onK4DhwanPpOH78zaFocVfRRhG9m5RmOrr ZzCT3x/CTadbfytN3RNTpGnsWQ2xS5Gr2mRGNmsxcmVk71dZBj72ks7hlCN1V5sVpWCIPQdi KMishU8vvAayXgiHPtwnJa1hbmLQV0OcAypRPwNwsL+DlIduAC+UXcHl4QmAX8s9QB4aASx7 +wqT8iSTBsOnb+CSTmBSYM8df7QXZ94AeO29UdLxTAbs+OwDMpMJf51qx2SdC0f8FdEswejh aO90lKEZIwx1hjF5WSUOR297o1AMkw2HH7RGISAeMd3XhMnLtPDtWC0mH5cAQ8P95OyhkfbQ X83C6RdVSqkUZ6oAnPjQi8nb1LC3ZozwAuib0+Wby/nmcDK0Et6+/gmXdSYMnx1XyHod/NT1 Bch6I6z+0UnKehmsOh9S1gGqESSb7UfT7ZzVJqCD6cJBjueRK339KrvVvQqZix6C6IvYrm8F niAbBAwF2Dja0O3I0Si4YqHEHgSLKIxdQG9TOXM08w84zCUWTrDku4psSAgCvbhrtMU/BHQE 7+ARm0DrkkWONnMlR5HLMYslUgSrpR9+n79bwxRybnQIISdyzbpJFMVC+sxiMah2oUJ0pMBq c/+3MSomCCAVJ5ZfkxhacHJ2wVoo+31gmU5LQ8lgJMNSxP/Lzr72caAVz4qnt0hUnPgX/qXH xWJMLH6tiBa7uf+WrhQodjZ0WZuq8+b9DFQnPkot8+TtCLwk9ElGY9fFhs0DsVPT5aGvlqyZ FdqZeZUnmYy7xycHi83m5gq1kdnjdx/rKUxuu9UVCbyo94T5e7Xt3jRkWjORFwmrXuqyNqgP xw4EFucHCza8W8pc9lVPWnPZxH3flp8INivR4ZGtlyIsIVi41am4S+D+ALnH6Q7IAwAA Archived-At: Cc: Christian Huitema , "taps@ietf.org" , =?Windows-1252?Q?Mirja_K=FChlewind?= , Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 09:51:10 -0000 --Apple-Mail=_0A2123F9-32B2-4228-A71D-92CD60A86BF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 =46rom the discussion in Dallas I think we may also need to define what = an =93application=94 is=85 Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Jun 4, 2015, at 9:37 AM, Michael Welzl wrote: >=20 > Well... it's a typical engineering trade-off decision to make... >=20 >=20 >> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit = wrote: >>=20 >> In my presentation in Dallas I had suggested adding RTP (and even = HTTP) because as both Mirja and Christian mention some 'applications' = are requesting functionalities that are got given elsewhere. >>=20 >> Marie-Jos=E9 Montpetit >> marie@mjmontpetit.com >> mariejo@mit.edu >>=20 >> On Jun 3, 2015, at 20:44, Christian Huitema = wrote: >>=20 >>>> Actually I think I don't agree here. Yes, it's tied closer to the = application but I >>>> think for taps this is a (good) example where the interface is at a = much higher >>>> level and therefore might have a value to discuss it. However... = (see below) >>>=20 >>> I don't quite agree either. >>>=20 >>> RTP is an extreme example of the split between "generic transport = library" and "application specific transport implementation." There are = quite a few RTP functions that are seldom found in other transports, but = are worth considering: >>>=20 >>> 1) The use of timestamps. This is quite fundamental for "real time" = applications that need to synchronize the rendering of different media = streams. >>>=20 >>> 2) The tolerance for losses. This requires alignment of transmission = units to "natural" media boundaries such as audio or video frames, or = compression units within video frames. >>>=20 >>> 3) The practice of FEC, including variable rate FEC. This is quite = common in video transmission. A given frame will be transmitted as N = data packets plus P redundancy packets, where N and P depend on size and = importance of the frame, e.g. anchor frame versus delta. >>>=20 >>> -- Christian Huitema >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail=_0A2123F9-32B2-4228-A71D-92CD60A86BF2 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDRDCCA0Aw ggKpoAMCAQICEQDvxXGV9K8f4AQSxWSxJJPrMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0 ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTQwNzAyMTM1MzUyWhcN MTUwNzMwMTM1MzUyWjCBqzELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs aWVudCBDQSB2MTEdMBsGA1UEAxMUTWFyaWUtSm9zZSBNb250cGV0aXQxHjAcBgkqhkiG9w0BCQEW D21hcmllam9ATUlULkVEVTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMWfBmhCuS6ol1Q/ KWrhtk0nMP3xU6T6R7Q7y/VnbE6BtYxFaRQ09PzHiv9B58UDhbhNN5y59BVPWWfevOImFitx4PY0 c6wMYGxC6aR0l9VySQ0VNavkRRKujyPxxjz+GRb64mAWzP0xqutz6SaZ2Fi0lxgccRheH/d0OLTg agUCAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBRCoWStx3OeBP0pszhPjQgj z28cdDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRjbGllbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBAHdNroykei2WKB4gO19mPUIyPMBFZrw5f87upM40csBB5HBBtZO4 op6JqoMxs93UrS+KO2+UK8c4zL/lRBRfbmQ7/r+gbJn0YqMb93eEHXR2u07xiRxHrI8oaC9RGhzc NMjbuAPbxlfY55CEPA2LLT/3nibZfvy+UPV/Xdkbg71gMYICtTCCArECAQEwgYEwbDELMAkGA1UE BhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5z dGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/FcZX0rx/gBBLF ZLEkk+swCQYFKw4DAhoFAKCCAYkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNjA0MDk1MTAwWjAjBgkqhkiG9w0BCQQxFgQUL3xtJTAgiRh6eBJP1sJpbOWKF6ww gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYA69t/HyO0FtkiYBlny8PUjKfLFCSBHzsfv 2yb7zsN2UOhVqTSj1d6kw256cWa2C20ME/EmTz5b1eSXtMOVsOh7esnmv0XnTfEULIITxfd9YWgO hQRzns9qfpcqcvKNBOBvFdNSw5i6ueYtNuAQj9UeYFP/09MD1sn3L8ZXauD59wAAAAAAAA== --Apple-Mail=_0A2123F9-32B2-4228-A71D-92CD60A86BF2-- From nobody Thu Jun 4 03:34:35 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AEA1A885C for ; Thu, 4 Jun 2015 03:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXA7LlOXV478 for ; Thu, 4 Jun 2015 03:34:31 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB3B1A00CC for ; Thu, 4 Jun 2015 03:34:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 54B93D9310; Thu, 4 Jun 2015 12:34:29 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KMaClD7W+QKI; Thu, 4 Jun 2015 12:34:29 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1FD82D930B; Thu, 4 Jun 2015 12:34:29 +0200 (MEST) Message-ID: <557029B4.9030001@tik.ee.ethz.ch> Date: Thu, 04 Jun 2015 12:34:28 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Marie-Jose Montpetit References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 10:34:34 -0000 It's in the doc: "Application: an entity that uses the transport layer for end-to-end delivery data across the network (this may also be an upper layer protocol or tunnel encapsulation)." Mirja On 04.06.2015 11:51, Marie-Jose Montpetit wrote: > From the discussion in Dallas I think we may also need to define what an “application” is… > > > Marie-Jose Montpetit, Ph.D. > mariejo@mit.edu > @SocialTVMIT > >> On Jun 4, 2015, at 9:37 AM, Michael Welzl wrote: >> >> Well... it's a typical engineering trade-off decision to make... >> >> >>> On 04 Jun 2015, at 07:45, Marie-Jose Montpetit wrote: >>> >>> In my presentation in Dallas I had suggested adding RTP (and even HTTP) because as both Mirja and Christian mention some 'applications' are requesting functionalities that are got given elsewhere. >>> >>> Marie-José Montpetit >>> marie@mjmontpetit.com >>> mariejo@mit.edu >>> >>> On Jun 3, 2015, at 20:44, Christian Huitema wrote: >>> >>>>> Actually I think I don't agree here. Yes, it's tied closer to the application but I >>>>> think for taps this is a (good) example where the interface is at a much higher >>>>> level and therefore might have a value to discuss it. However... (see below) >>>> >>>> I don't quite agree either. >>>> >>>> RTP is an extreme example of the split between "generic transport library" and "application specific transport implementation." There are quite a few RTP functions that are seldom found in other transports, but are worth considering: >>>> >>>> 1) The use of timestamps. This is quite fundamental for "real time" applications that need to synchronize the rendering of different media streams. >>>> >>>> 2) The tolerance for losses. This requires alignment of transmission units to "natural" media boundaries such as audio or video frames, or compression units within video frames. >>>> >>>> 3) The practice of FEC, including variable rate FEC. This is quite common in video transmission. A given frame will be transmitted as N data packets plus P redundancy packets, where N and P depend on size and importance of the frame, e.g. anchor frame versus delta. >>>> >>>> -- Christian Huitema >>>> >>>> _______________________________________________ >>>> 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 >> > -- ------------------------------------------ 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 Thu Jun 4 03:48:05 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280ED1A88E0 for ; Thu, 4 Jun 2015 03:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Phj-OY4AwJXS for ; Thu, 4 Jun 2015 03:48:03 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDC71A00CF for ; Thu, 4 Jun 2015 03:48:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=596; q=dns/txt; s=iport; t=1433414883; x=1434624483; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WilZWJ42HjyPW7LqAiY3W3LfFCZBW0xfFu/3qdX8noo=; b=OykcvL5au7fEEt00og52ivMMTm9NVFaTpJlEJnD7G2Ly1ggJP07WDtrr uf5Ac9oIvTl9VLmzN2Ubh51anc/rBrybs0VoVN4z/36O3N0SbIYBHEohj PcUHdwoZt2er7M48ksFX7dnCIZskx653N5+DuKh3H9Lmek1HaZRuxBua0 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaBQBzLHBV/4MNJK1bgxCBOIMYuy2Hb4EbOhIBAQEBAQEBgQqEKSMRVwEiAiYCBDAVEgSIQKctj1+jbQEBAQEBBQEBAQEBAQEBGoEhkhcvgRYFkxqLJJdQJGGDFoI1gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,552,1427760000"; d="scan'208";a="156360809" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP; 04 Jun 2015 10:48:01 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t54Am1f4011194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Jun 2015 10:48:01 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.183]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 05:48:01 -0500 From: "Pal Martinsen (palmarti)" To: "taps@ietf.org" Thread-Topic: TAPS Transports and ICMP Thread-Index: AQHQnrPtkK68ApcbdEG/b2ediao1lg== Date: Thu, 4 Jun 2015 10:48:01 +0000 Message-ID: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.232] Content-Type: text/plain; charset="utf-8" Content-ID: <4DA52AFB6534334CA08AD31F6DBED547@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Taps] TAPS Transports and ICMP 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 Jun 2015 10:48:04 -0000 SGksDQoNCkkgd2FzIHdvbmRlcmluZ+KApg0KDQpUb2RheSBhcHAgZGV2ZWxvcGVycyBhY3RpdmVs eSBuZWVkIHRvIGxpc3RlbiBmb3IgSUNNUCBtZXNzYWdlcyBhbmQgZG8gc21hcnQgdGhpbmdzICh0 bSkgaWYgdGhleSByZWNlaXZlIHRoZW0uIElDTVAgYWxzbyBvZmZlcnMgYSBuaWNlIHNldCBvZiB0 b29scyB0byBkbyBhIGZldyBuZWF0IHRyaWNrcy4gQXBwbGljYXRpb24gZGV2ZWxvcGVycyByYXJl bHkgYm90aGVycyB0byBjYXJlIGFib3V0IHRoYXQuIA0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2UgZm9y IHRoZSBUQVBTIHRyYW5zcG9ydHMgZHJhZnQgdG8gYWRkIElDTVA/IElDTVAgZmVlZGJhY2sgY2Fu IHBvc3NpYmx5IGluZmx1ZW5jZSBob3cgdGhlIG90aGVyIHRyYW5zcG9ydCBwcm90b2NvbHMgaW4g dGhlIGRyYWZ0IGJlaGF2ZS4NCg0KIC4tLg0KUMOlbC1Fcmlr From nobody Thu Jun 4 08:43:58 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77FB1A8A68 for ; Thu, 4 Jun 2015 08:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-09INeG5CX0 for ; Thu, 4 Jun 2015 08:43:56 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203021A8A65 for ; Thu, 4 Jun 2015 08:43:56 -0700 (PDT) Received: from [192.168.1.5] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t54FhEdh020520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 08:43:24 -0700 (PDT) Message-ID: <55707211.8010609@isi.edu> Date: Thu, 04 Jun 2015 08:43:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , "taps@ietf.org" References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> In-Reply-To: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t54FhEdh020520 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 15:43:57 -0000 On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote: ... > Does it make sense for the TAPS transports draft to add ICMP? ICMP is not a transport protocol. The ways in which transport protocols either terminate or pass-through ICMP messages is part of the transport protocol abstract API. E.g., for UDP and TCP see RFC1122. UDP passes all ICMP messages to the app. TCP passes only dest unreachable types 0, 1, and 5, time exceeded and parameter problem. All others it interprets or ignores internally and it's not clear it should pass up to the app. Joe From nobody Thu Jun 4 11:15:44 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D5F1A874D for ; Thu, 4 Jun 2015 11:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 uVD-CDUaFaph for ; Thu, 4 Jun 2015 11:15:41 -0700 (PDT) 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 BB3711A8778 for ; Thu, 4 Jun 2015 11:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6234; q=dns/txt; s=iport; t=1433441741; x=1434651341; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=97Cy1BfmhvS75eHWDm61Z4WcBOc2gzagEQew/bRELLo=; b=EgnfVQBvneWLaklEmv0D0Ces3ernumDck89t9DwK55Pd/0sjXyLbk1XP SAEYAlgUgKqURu+hNCjyGjvg0rBnwybWNC9CapN72KehxBo34As76QiPa SFEwxiA4vEwNcM9q0pJ76/kSIY+rEPTnK8GJKvscbNItHlr4YRBmLMV5f 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BACPlHBV/4UNJK1bDoMCVF4Ggxi7KwmBXIV1AhyBHTgUAQEBAQEBAYEKhCMBAQQjVhACAQgEOwMCAgIwFBECBA4FiC0Nt1ikBAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0OEJF4EB4JoL4EWBZMahDyGaJdQJGGCWD5vAYEDQoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,554,1427760000"; d="scan'208,217";a="843409" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jun 2015 18:15:40 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t54IFe3L028976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 18:15:40 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.183]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 13:15:40 -0500 From: "Pal Martinsen (palmarti)" To: Joe Touch Thread-Topic: [Taps] TAPS Transports and ICMP Thread-Index: AQHQnrPt38kKNK6QP0icmFYJs5spRZ2c0L6AgAAqlgA= Date: Thu, 4 Jun 2015 18:15:39 +0000 Message-ID: <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> In-Reply-To: <55707211.8010609@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.232] Content-Type: multipart/alternative; boundary="_000_26B9DE0B4D38430DA9A1921CD0067C70ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 18:15:43 -0000 --_000_26B9DE0B4D38430DA9A1921CD0067C70ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAwNCBKdW4gMjAxNSwgYXQgMTc6NDMsIEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdTxtYWls dG86dG91Y2hAaXNpLmVkdT4+IHdyb3RlOg0KDQoNCg0KT24gNi80LzIwMTUgMzo0OCBBTSwgUGFs IE1hcnRpbnNlbiAocGFsbWFydGkpIHdyb3RlOg0KLi4uDQpEb2VzIGl0IG1ha2Ugc2Vuc2UgZm9y IHRoZSBUQVBTIHRyYW5zcG9ydHMgZHJhZnQgdG8gYWRkIElDTVA/DQoNCklDTVAgaXMgbm90IGEg dHJhbnNwb3J0IHByb3RvY29sLg0KDQpTdXJlLiBBbmQgSSBhZ3JlZS4gQnV0IGl0IGhhcyB0aGUg cG90ZW50aWFsIHRvIGluZmx1ZW5jZSBob3cgdGhlIHZhcmlvdXMgdHJhbnNwb3J0IHByb3RvY29s cyBiZWhhdmUuIFRoYXQgaW50ZXJhY3Rpb24gbWlnaHQgYmUgbmljZSB0byBoYXZlIGRlc2NyaWJl ZCBpbiB0aGUgdHJhbnNwb3J0cyBkcmFmdC4NCg0KDQpUaGUgd2F5cyBpbiB3aGljaCB0cmFuc3Bv cnQgcHJvdG9jb2xzIGVpdGhlciB0ZXJtaW5hdGUgb3IgcGFzcy10aHJvdWdoDQpJQ01QIG1lc3Nh Z2VzIGlzIHBhcnQgb2YgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCBhYnN0cmFjdCBBUEkuDQoNCkUu Zy4sIGZvciBVRFAgYW5kIFRDUCBzZWUgUkZDMTEyMi4NCg0KVURQIHBhc3NlcyBhbGwgSUNNUCBt ZXNzYWdlcyB0byB0aGUgYXBwLg0KDQpOby4gTm90IHVubGVzcyB0aGUgYXBwbGljYXRpb24gc3Bl Y2lmaWNhbGx5IGxpc3RlbnMgZm9yIGl0LiBVbmZvcnR1bmF0ZWx5IGhvdyB0byBkbyB0aGlzIHZh cmllcyBmcm9tIE9TIHRvIE9TOg0KU2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UtMDEjYXBwZW5kaXgtQS4yIGZvciBleGFtcGxlcy4N Cg0KTGlzdGVuaW5nIGZvciBwb3J0IHVucmVhY2hhYmxlIGNhbiBiZSBuaWNlIHRvIGF2b2lkIHNw YW1taW5nIGEgaG9zdCBvciBhcHBsaWNhdGlvbiB0aGF0IHJlY2VudGx5IGNyYXNoZWQuIERldGVj dGluZyBmcmFnbWVudGF0aW9uIG9yIG1heCBNVFUgaXMgYWxzbyBhIG5pY2UgZmVhdHVyZSBlc3Bl Y2lhbGx5IFZvSVAgYXBwbGljYXRpb25zIHNlbmRpbmcgdmlkZW8gY2FuIHV0aWxpc2UgdG8gb3B0 aW1pc2UgdGhlaXIgcGFja2V0IHNpemVzLg0KDQoNClRDUCBwYXNzZXMgb25seSBkZXN0IHVucmVh Y2hhYmxlIHR5cGVzIDAsIDEsIGFuZCA1LCB0aW1lIGV4Y2VlZGVkIGFuZA0KcGFyYW1ldGVyIHBy b2JsZW0uIEFsbCBvdGhlcnMgaXQgaW50ZXJwcmV0cyBvciBpZ25vcmVzIGludGVybmFsbHkgYW5k DQppdOKAmXMgbm90IGNsZWFyIGl0IHNob3VsZCBwYXNzIHVwIHRvIHRoZSBhcHAuDQoNClRoYXQg aXMgZXhhY3RseSB0aGF0IGtpbmQgb2YgaW5mb3JtYXRpb24gSSB3b3VsZCBmaW5kIHVzZWZ1bCBp biB0aGUgdHJhbnNwb3J0cyBkcmFmdC4NCg0KQW55IHBpdGZhbGxzIHdpdGggSUNNUCB3aGVuIGRv aW5nIFNDVFA/DQoNCi4tLg0KUMOlbC1FcmlrDQoNCg0KSm9lDQoNCg== --_000_26B9DE0B4D38430DA9A1921CD0067C70ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAwNCBK dW4gMjAxNSwgYXQgMTc6NDMsIEpvZSBUb3VjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvdWNoQGlz aS5lZHUiIGNsYXNzPSIiPnRvdWNoQGlzaS5lZHU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDYvNC8yMDE1IDM6NDggQU0sIFBhbCBNYXJ0aW5zZW4g KHBhbG1hcnRpKSB3cm90ZTo8YnIgY2xhc3M9IiI+DQouLi48YnIgY2xhc3M9IiI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Eb2VzIGl0IG1ha2Ugc2Vuc2UgZm9yIHRoZSBUQVBT IHRyYW5zcG9ydHMgZHJhZnQgdG8gYWRkIElDTVA/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3Rl Pg0KPGJyIGNsYXNzPSIiPg0KSUNNUCBpcyBub3QgYSB0cmFuc3BvcnQgcHJvdG9jb2wuPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KU3VyZS4gQW5kIEkgYWdyZWUuIEJ1dCBpdCBoYXMgdGhlIHBvdGVudGlhbCB0byBpbmZsdWVu Y2UgaG93IHRoZSB2YXJpb3VzIHRyYW5zcG9ydCBwcm90b2NvbHMgYmVoYXZlLiBUaGF0IGludGVy YWN0aW9uIG1pZ2h0IGJlIG5pY2UgdG8gaGF2ZSBkZXNjcmliZWQgaW4gdGhlIHRyYW5zcG9ydHMg ZHJhZnQuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpUaGUgd2F5cyBpbiB3aGlj aCB0cmFuc3BvcnQgcHJvdG9jb2xzIGVpdGhlciB0ZXJtaW5hdGUgb3IgcGFzcy10aHJvdWdoPGJy IGNsYXNzPSIiPg0KSUNNUCBtZXNzYWdlcyBpcyBwYXJ0IG9mIHRoZSB0cmFuc3BvcnQgcHJvdG9j b2wgYWJzdHJhY3QgQVBJLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkUuZy4sIGZvciBV RFAgYW5kIFRDUCBzZWUgUkZDMTEyMi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpVRFAg cGFzc2VzIGFsbCBJQ01QIG1lc3NhZ2VzIHRvIHRoZSBhcHAuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pk5vLiBOb3QgdW5sZXNzIHRoZSBh cHBsaWNhdGlvbiBzcGVjaWZpY2FsbHkgbGlzdGVucyBmb3IgaXQuIFVuZm9ydHVuYXRlbHkgaG93 IHRvIGRvIHRoaXMgdmFyaWVzIGZyb20gT1MgdG8gT1M6PC9kaXY+DQo8ZGl2PlNlZSZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1z dHVudHJhY2UtMDEjYXBwZW5kaXgtQS4yIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1bnRyYWNlLTAxI2FwcGVuZGl4LUEuMjwvYT4m bmJzcDtmb3IgZXhhbXBsZXMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj5MaXN0ZW5pbmcgZm9yIHBvcnQgdW5yZWFjaGFibGUgY2FuIGJlIG5pY2UgdG8gYXZvaWQgc3Bh bW1pbmcgYSBob3N0IG9yIGFwcGxpY2F0aW9uIHRoYXQgcmVjZW50bHkgY3Jhc2hlZC4gRGV0ZWN0 aW5nIGZyYWdtZW50YXRpb24gb3IgbWF4IE1UVSBpcyBhbHNvIGEgbmljZSBmZWF0dXJlIGVzcGVj aWFsbHkgVm9JUCBhcHBsaWNhdGlvbnMgc2VuZGluZyB2aWRlbyBjYW4gdXRpbGlzZSB0byBvcHRp bWlzZSB0aGVpciBwYWNrZXQgc2l6ZXMuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPlRDUCBwYXNzZXMgb25seSBkZXN0IHVucmVhY2hhYmxlIHR5cGVzIDAs IDEsIGFuZCA1LCB0aW1lIGV4Y2VlZGVkIGFuZDxiciBjbGFzcz0iIj4NCnBhcmFtZXRlciBwcm9i bGVtLiBBbGwgb3RoZXJzIGl0IGludGVycHJldHMgb3IgaWdub3JlcyBpbnRlcm5hbGx5IGFuZDxi ciBjbGFzcz0iIj4NCml04oCZcyBub3QgY2xlYXIgaXQgc2hvdWxkIHBhc3MgdXAgdG8gdGhlIGFw cC48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2PlRoYXQgaXMgZXhhY3RseSB0aGF0IGtpbmQgb2YgaW5mb3JtYXRpb24g SSB3b3VsZCBmaW5kIHVzZWZ1bCBpbiB0aGUgdHJhbnNwb3J0cyBkcmFmdC48L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkFueSBwaXRmYWxscyB3aXRoIElDTVAgd2hlbiBk b2luZyBTQ1RQPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Li0uPC9k aXY+DQo8ZGl2PlDDpWwtRXJpazwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCkpvZTxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_26B9DE0B4D38430DA9A1921CD0067C70ciscocom_-- From nobody Thu Jun 4 11:28:08 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379171A8855 for ; Thu, 4 Jun 2015 11:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stD8PDPdzwfP for ; Thu, 4 Jun 2015 11:28:03 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378081A8840 for ; Thu, 4 Jun 2015 11:28:03 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t54IRNOw003660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 11:27:23 -0700 (PDT) Message-ID: <5570988A.6040208@isi.edu> Date: Thu, 04 Jun 2015 11:27:22 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> In-Reply-To: <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t54IRNOw003660 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 18:28:07 -0000 On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote: > >> On 04 Jun 2015, at 17:43, Joe Touch > > wrote: >> >> >> >> On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote: >> ... >>> Does it make sense for the TAPS transports draft to add ICMP? >> >> ICMP is not a transport protocol. > > Sure. And I agree. But it has the potential to influence how the various > transport protocols behave. That interaction might be nice to have > described in the transports draft. Abstract APIs need to be described. These are part of that description. >> The ways in which transport protocols either terminate or pass-through >> ICMP messages is part of the transport protocol abstract API. >> >> E.g., for UDP and TCP see RFC1122. >> >> UDP passes all ICMP messages to the app. >> > No. Not unless the application specifically listens for it. UDP passes all ICMP messages to the app. If the app doesn't listen for it, that's the app's decision. > Unfortunately how to do this varies from OS to OS: > See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 for > examples. You are confusing the OS and language-dependent implementation of the API with the abstract API. RFC1122 requires that UDP implementations make the ICMP signals available to the application. It does not indicate by what mechanism. > Listening for port unreachable can be nice to avoid spamming a host or > application that recently crashed. Detecting fragmentation or max MTU is > also a nice feature especially VoIP applications sending video can > utilise to optimise their packet sizes. UDP is required to pass ALL ICMP messages to the app layer, as per RFC 1122. >> TCP passes only dest unreachable types 0, 1, and 5, time exceeded and >> parameter problem. All others it interprets or ignores internally and >> it’s not clear it should pass up to the app. > > That is exactly that kind of information I would find useful in the > transports draft. Well, yes - IMO, that's because it's part of the abstract API. > Any pitfalls with ICMP when doing SCTP? In many ways, SCTP subsumes similar requirements as TCP, but that's probably buried in the SCTP docs. Joe From nobody Thu Jun 4 12:08:40 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8681A88BD for ; Thu, 4 Jun 2015 12:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 g-_ibplQHd2B for ; Thu, 4 Jun 2015 12:08:31 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5151A8900 for ; Thu, 4 Jun 2015 12:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4676; q=dns/txt; s=iport; t=1433444906; x=1434654506; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v/hX0IoviNvzElEvslttGyDPleqESIBjBJO4I4i7QgY=; b=GJNgXJ61Dxof4OV8L5tled+dlUdvAWtdhOuKq5Q/Ou1tHjHMgwNp5iqZ b3QlRcCnrgt4S3uG/yEZnV9mIFX+fgM/aMW7kBUjmmjhQqOyHNDldkWBb 4xEHEqSjbTosjnREm0gqhfeaC5/117ZzF83rwaZGWHYhuDpEYxwSEX3pP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBQBmoXBV/5xdJa1bDoMCVF4Ggxi9EYV1AhyBHkwBAQEBAQGBC4QiAQEBAwEjEUUFCwIBCBgCAiMDAgICMBQBEAIEDgUWA4gMCA23V6QNAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoihCRHGweCaC+BFgWTGoQ8hmiXUCRhglg+bwGBA0KBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,554,1427760000"; d="scan'208";a="17549356" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 04 Jun 2015 19:08:25 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t54J8PZd017326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 19:08:25 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.183]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 14:08:25 -0500 From: "Pal Martinsen (palmarti)" To: Joe Touch Thread-Topic: [Taps] TAPS Transports and ICMP Thread-Index: AQHQnrPt38kKNK6QP0icmFYJs5spRZ2c0L6AgAAqlgCAAANHAIAAC3cA Date: Thu, 4 Jun 2015 19:08:24 +0000 Message-ID: <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> In-Reply-To: <5570988A.6040208@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.232] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 19:08:39 -0000 DQo+IE9uIDA0IEp1biAyMDE1LCBhdCAyMDoyNywgSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PiB3 cm90ZToNCj4gDQo+IA0KPiANCj4gT24gNi80LzIwMTUgMTE6MTUgQU0sIFBhbCBNYXJ0aW5zZW4g KHBhbG1hcnRpKSB3cm90ZToNCj4+IA0KPj4+IE9uIDA0IEp1biAyMDE1LCBhdCAxNzo0MywgSm9l IFRvdWNoIDx0b3VjaEBpc2kuZWR1DQo+Pj4gPG1haWx0bzp0b3VjaEBpc2kuZWR1Pj4gd3JvdGU6 DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gT24gNi80LzIwMTUgMzo0OCBBTSwgUGFsIE1hcnRpbnNl biAocGFsbWFydGkpIHdyb3RlOg0KPj4+IC4uLg0KPj4+PiBEb2VzIGl0IG1ha2Ugc2Vuc2UgZm9y IHRoZSBUQVBTIHRyYW5zcG9ydHMgZHJhZnQgdG8gYWRkIElDTVA/DQo+Pj4gDQo+Pj4gSUNNUCBp cyBub3QgYSB0cmFuc3BvcnQgcHJvdG9jb2wuDQo+PiANCj4+IFN1cmUuIEFuZCBJIGFncmVlLiBC dXQgaXQgaGFzIHRoZSBwb3RlbnRpYWwgdG8gaW5mbHVlbmNlIGhvdyB0aGUgdmFyaW91cw0KPj4g dHJhbnNwb3J0IHByb3RvY29scyBiZWhhdmUuIFRoYXQgaW50ZXJhY3Rpb24gbWlnaHQgYmUgbmlj ZSB0byBoYXZlDQo+PiBkZXNjcmliZWQgaW4gdGhlIHRyYW5zcG9ydHMgZHJhZnQuDQo+IA0KPiBB YnN0cmFjdCBBUElzIG5lZWQgdG8gYmUgZGVzY3JpYmVkLiBUaGVzZSBhcmUgcGFydCBvZiB0aGF0 IGRlc2NyaXB0aW9uLg0KPiANCj4+PiBUaGUgd2F5cyBpbiB3aGljaCB0cmFuc3BvcnQgcHJvdG9j b2xzIGVpdGhlciB0ZXJtaW5hdGUgb3IgcGFzcy10aHJvdWdoDQo+Pj4gSUNNUCBtZXNzYWdlcyBp cyBwYXJ0IG9mIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgYWJzdHJhY3QgQVBJLg0KPj4+IA0KPj4+ IEUuZy4sIGZvciBVRFAgYW5kIFRDUCBzZWUgUkZDMTEyMi4NCj4+PiANCj4+PiBVRFAgcGFzc2Vz IGFsbCBJQ01QIG1lc3NhZ2VzIHRvIHRoZSBhcHAuDQo+Pj4gDQo+PiBOby4gTm90IHVubGVzcyB0 aGUgYXBwbGljYXRpb24gc3BlY2lmaWNhbGx5IGxpc3RlbnMgZm9yIGl0Lg0KPiANCj4gVURQIHBh c3NlcyBhbGwgSUNNUCBtZXNzYWdlcyB0byB0aGUgYXBwLiBJZiB0aGUgYXBwIGRvZXNuJ3QgbGlz dGVuIGZvcg0KPiBpdCwgdGhhdOKAmXMgdGhlIGFwcCdzIGRlY2lzaW9uLg0KPiANClRoZW4gdGhl cmUgaXMgYSBsb3QgVURQIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgb3V0IHRoZXJlIHRoYXQgZG9l cyBub3QgY2FyZS4gDQoNCklsbCBndWVzcyB3aGF0IEkgYW0gYXNraW5nIGlmIHdlIHNob3VsZCBt YWtlIGxpZmUgZWFzaWVyIGZvciB0aGVtLg0KDQo+PiBVbmZvcnR1bmF0ZWx5IGhvdyB0byBkbyB0 aGlzIHZhcmllcyBmcm9tIE9TIHRvIE9TOg0KPj4gU2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UtMDEjYXBwZW5kaXgtQS4yIGZvcg0K Pj4gZXhhbXBsZXMuDQo+IA0KPiBZb3UgYXJlIGNvbmZ1c2luZyB0aGUgT1MgYW5kIGxhbmd1YWdl LWRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUNCj4gQVBJIHdpdGggdGhlIGFic3RyYWN0 IEFQSS4NCj4gDQpPbiBwdXJwb3NlLiBJIGhhdGUgaXQgd2hlbiBhIGZlYXR1cmUgc2hvdWxkIHdv cmsgYmVjYXVzZSBpdCBzYXlzIHNvIGluIGEgUkZDLCBidXQgdGhlIGltcGxlbWVudGF0aW9ucyBv ZiBpdCBpcyBzbyB2YXN0bHkgZGlmZmVyZW50IHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGdl dCB0aGUgdGhpbmcgdG8gd29yayBzbyB0aGUgYXBwIGRldmVsb3BlciBqdXN0IGNob3NlIHRvIGln bm9yZSBpdC4NCg0KSWYgVEFQUyBlbmRzIHVwIGxpa2UgdGhlIElDTVAgYWJzdHJhY3QgaW50ZXJm YWNlcyBpdCB3b3VsZCBtYWtlIGxpZmUgZXZlbiBoYXJkZXIgZm9yIHRoZSBhcHAgZGV2ZWxvcGVy cyB0cnlpbmcgdG8gZ2V0IHRoaW5ncyB3b3JraW5nIG9uIHZhcmlvdXMgcGxhdGZvcm1zLg0KDQo+ IFJGQzExMjIgcmVxdWlyZXMgdGhhdCBVRFAgaW1wbGVtZW50YXRpb25zIG1ha2UgdGhlIElDTVAg c2lnbmFscw0KPiBhdmFpbGFibGUgdG8gdGhlIGFwcGxpY2F0aW9uLiBJdCBkb2VzIG5vdCBpbmRp Y2F0ZSBieSB3aGF0IG1lY2hhbmlzbS4NCj4gDQo+PiBMaXN0ZW5pbmcgZm9yIHBvcnQgdW5yZWFj aGFibGUgY2FuIGJlIG5pY2UgdG8gYXZvaWQgc3BhbW1pbmcgYSBob3N0IG9yDQo+PiBhcHBsaWNh dGlvbiB0aGF0IHJlY2VudGx5IGNyYXNoZWQuIERldGVjdGluZyBmcmFnbWVudGF0aW9uIG9yIG1h eCBNVFUgaXMNCj4+IGFsc28gYSBuaWNlIGZlYXR1cmUgZXNwZWNpYWxseSBWb0lQIGFwcGxpY2F0 aW9ucyBzZW5kaW5nIHZpZGVvIGNhbg0KPj4gdXRpbGlzZSB0byBvcHRpbWlzZSB0aGVpciBwYWNr ZXQgc2l6ZXMuIA0KPiANCj4gVURQIGlzIHJlcXVpcmVkIHRvIHBhc3MgQUxMIElDTVAgbWVzc2Fn ZXMgdG8gdGhlIGFwcCBsYXllciwgYXMgcGVyIFJGQyAxMTIyLg0KDQpUaGF0IGlzIGFub3RoZXIg cHJvYmxlbS4gQW4gYXBwIHVzaW5nIHBvcnQgNTU1NSB3aWxsIHJlY2VpdmUgYWxsIElDTVAgbWVz c2FnZXMgYWxzbyBnZW5lcmF0ZWQgYnkgb3RoZXIgYXBwcyBydW5uaW5nIG9uIG90aGVyIHBvcnRz LiBUcml2aWFsIHRvIGZpbmQgdGhlIG9uZXMgdGhhdCBiZWxvbmdzIHRvIHlvdSBpZiB5b3Uga25v dyBob3cuIA0KDQpTbyB0aGlzIGJvaWxzIGRvd24gYmV0dGVyIGVkdWNhdGlvbiBvZiB0aGUgYXBw IGRldmVsb3BlcnM/DQoNCj4gDQo+Pj4gVENQIHBhc3NlcyBvbmx5IGRlc3QgdW5yZWFjaGFibGUg dHlwZXMgMCwgMSwgYW5kIDUsIHRpbWUgZXhjZWVkZWQgYW5kDQo+Pj4gcGFyYW1ldGVyIHByb2Js ZW0uIEFsbCBvdGhlcnMgaXQgaW50ZXJwcmV0cyBvciBpZ25vcmVzIGludGVybmFsbHkgYW5kDQo+ Pj4gaXTigJlzIG5vdCBjbGVhciBpdCBzaG91bGQgcGFzcyB1cCB0byB0aGUgYXBwLg0KPj4gDQo+ PiBUaGF0IGlzIGV4YWN0bHkgdGhhdCBraW5kIG9mIGluZm9ybWF0aW9uIEkgd291bGQgZmluZCB1 c2VmdWwgaW4gdGhlDQo+PiB0cmFuc3BvcnRzIGRyYWZ0Lg0KPiANCj4gV2VsbCwgeWVzIC0gSU1P LCB0aGF04oCZcyBiZWNhdXNlIGl0J3MgcGFydCBvZiB0aGUgYWJzdHJhY3QgQVBJLg0KPiANCkNh biB0aGV5IGF0IGxlYXN0IGNpdGUgUkZDIDExMjIgdGhlbj8NCg0KPj4gQW55IHBpdGZhbGxzIHdp dGggSUNNUCB3aGVuIGRvaW5nIFNDVFA/DQo+IA0KPiBJbiBtYW55IHdheXMsIFNDVFAgc3Vic3Vt ZXMgc2ltaWxhciByZXF1aXJlbWVudHMgYXMgVENQLCBidXQgdGhhdCdzDQo+IHByb2JhYmx5IGJ1 cmllZCBpbiB0aGUgU0NUUCBkb2NzLg0KPiANCg0KVGhhbmtzLiBVc2VmdWwgZGlzY3Vzc2lvbiBm b3IgbWUuIE5vdCBzbyBzdXJlIGlmIGl0IHdhcyB1c2VmdWwgZm9yIHJlc3Qgb2YgdGhlIFRBUFMg bGlzdC4gU29ycnkgYWJvdXQgdGhhdC4NCg0KLi0uDQpQw6VsLUVyaWsNCg0KPiBKb2UNCg0K From nobody Thu Jun 4 12:12:21 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3776F1A8906 for ; Thu, 4 Jun 2015 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWhcF0YRIZ7b for ; Thu, 4 Jun 2015 12:12:19 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2161A88F7 for ; Thu, 4 Jun 2015 12:12:19 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t54JBHS0010439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 12:11:17 -0700 (PDT) Message-ID: <5570A2D4.4040005@isi.edu> Date: Thu, 04 Jun 2015 12:11:16 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Mirja_K=FChlewind?= , Marie-Jose Montpetit References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <557029B4.9030001@tik.ee.ethz.ch> In-Reply-To: <557029B4.9030001@tik.ee.ethz.ch> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t54JBHS0010439 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 19:12:20 -0000 On 6/4/2015 3:34 AM, Mirja Kühlewind wrote: > It's in the doc: > > "Application: an entity that uses the transport layer for end-to-end > delivery data across the network (this may also be an upper layer > protocol or tunnel encapsulation)." "End to end" is *defined* as the endpoints of the transport association. So, basically: "Application: an entity that uses the transport layer for delivery of data between the transport endpoints." However, *every* protocol is trivially defined as: A mechanism between two or more parties to exchange data (information) between those parties. I.e., as a result, an app is defined EXACTLY and ONLY by the following: Application: an entity that *uses* a transport layer. Every other part of the definition is irrelevant, IMO. Joe From nobody Thu Jun 4 12:17:58 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040461A8930 for ; Thu, 4 Jun 2015 12:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWk7M6kUuQZB for ; Thu, 4 Jun 2015 12:17:55 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8340E1A892A for ; Thu, 4 Jun 2015 12:17:55 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t54JHdKr011615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 12:17:39 -0700 (PDT) Message-ID: <5570A452.8090209@isi.edu> Date: Thu, 04 Jun 2015 12:17:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> In-Reply-To: <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t54JHdKr011615 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 19:17:57 -0000 On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote: ... >> UDP passes all ICMP messages to the app. If the app doesn't listen for >> it, that’s the app's decision. >> > Then there is a lot UDP application developers out there that does not care. > > Ill guess what I am asking if we should make life easier for them. Again, FIRST this doc needs to explain the current abstract APIs for transport protocols. THEN we can decide whether that set either needs to be augmented, diminished, or translated to be more useful for "applications". >>> Unfortunately how to do this varies from OS to OS: >>> See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 for >>> examples. >> >> You are confusing the OS and language-dependent implementation of the >> API with the abstract API. >> > On purpose. I hate it when a feature should work because it says so > in a RFC, but the implementations of it is so vastly different that > it is not possible to get the thing to work so the app developer just > chose to ignore it. The IETF standardizes protocols and abstract APIs. If you are concerned with differences in the implementations of those abstract APIs, you need to address them in other organizations (e.g., POSIX, etc.). ... >> RFC1122 requires that UDP implementations make the ICMP signals >> available to the application. It does not indicate by what mechanism. >> >>> Listening for port unreachable can be nice to avoid spamming a host or >>> application that recently crashed. Detecting fragmentation or max MTU is >>> also a nice feature especially VoIP applications sending video can >>> utilise to optimise their packet sizes. >> >> UDP is required to pass ALL ICMP messages to the app layer, as per RFC 1122. > > That is another problem. An app using port 5555 will receive all > ICMP messages also generated by other apps running on other ports. That's an incorrect implementation. See RFC1122 Section 4.1.3.3. ... > So this boils down better education of the app developers? No, in that case you have a bug. The only thing the UDP app has to worry about are ICMPs from other apps using the same port. >>>> TCP passes only dest unreachable types 0, 1, and 5, time exceeded and >>>> parameter problem. All others it interprets or ignores internally and >>>> it’s not clear it should pass up to the app. >>> >>> That is exactly that kind of information I would find useful in the >>> transports draft. >> >> Well, yes - IMO, that’s because it's part of the abstract API. >> > Can they at least cite RFC 1122 then? I would hope so. Joe From nobody Thu Jun 4 12:20:07 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9BB1A894C for ; Thu, 4 Jun 2015 12:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 Zr7DMo071Lv9 for ; Thu, 4 Jun 2015 12:20:04 -0700 (PDT) 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 692571A894F for ; Thu, 4 Jun 2015 12:20:04 -0700 (PDT) Received: from [192.168.1.200] (p508F138D.dip0.t-ipconnect.de [80.143.19.141]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 39DD81C104358; Thu, 4 Jun 2015 21:20:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Tuexen In-Reply-To: <5570988A.6040208@isi.edu> Date: Thu, 4 Jun 2015 21:19:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97FD8853-7345-40E9-A523-8AF53FB2303B@lurchi.franken.de> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 19:20:06 -0000 > On 04 Jun 2015, at 20:27, Joe Touch wrote: >=20 >=20 >=20 > On 6/4/2015 11:15 AM, Pal Martinsen (palmarti) wrote: >>=20 >>> On 04 Jun 2015, at 17:43, Joe Touch >> > wrote: >>>=20 >>>=20 >>>=20 >>> On 6/4/2015 3:48 AM, Pal Martinsen (palmarti) wrote: >>> ... >>>> Does it make sense for the TAPS transports draft to add ICMP? >>>=20 >>> ICMP is not a transport protocol. >>=20 >> Sure. And I agree. But it has the potential to influence how the = various >> transport protocols behave. That interaction might be nice to have >> described in the transports draft. >=20 > Abstract APIs need to be described. These are part of that = description. >=20 >>> The ways in which transport protocols either terminate or = pass-through >>> ICMP messages is part of the transport protocol abstract API. >>>=20 >>> E.g., for UDP and TCP see RFC1122. >>>=20 >>> UDP passes all ICMP messages to the app. >>>=20 >> No. Not unless the application specifically listens for it. >=20 > UDP passes all ICMP messages to the app. If the app doesn't listen for > it, that's the app's decision. >=20 >> Unfortunately how to do this varies from OS to OS: >> See = https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2= for >> examples. >=20 > You are confusing the OS and language-dependent implementation of the > API with the abstract API. >=20 > RFC1122 requires that UDP implementations make the ICMP signals > available to the application. It does not indicate by what mechanism. >=20 >> Listening for port unreachable can be nice to avoid spamming a host = or >> application that recently crashed. Detecting fragmentation or max MTU = is >> also a nice feature especially VoIP applications sending video can >> utilise to optimise their packet sizes.=20 >=20 > UDP is required to pass ALL ICMP messages to the app layer, as per RFC = 1122. >=20 >>> TCP passes only dest unreachable types 0, 1, and 5, time exceeded = and >>> parameter problem. All others it interprets or ignores internally = and >>> it=E2=80=99s not clear it should pass up to the app. >>=20 >> That is exactly that kind of information I would find useful in the >> transports draft. >=20 > Well, yes - IMO, that's because it's part of the abstract API. >=20 >> Any pitfalls with ICMP when doing SCTP? >=20 > In many ways, SCTP subsumes similar requirements as TCP, but that's > probably buried in the SCTP docs. It is. See https://tools.ietf.org/html/rfc4960#appendix-C Best regards Michael >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 4 12:51:59 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F101A8F49 for ; Thu, 4 Jun 2015 12:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 u3M_9-_5aOHb for ; Thu, 4 Jun 2015 12:51:56 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24AD1A8F41 for ; Thu, 4 Jun 2015 12:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5634; q=dns/txt; s=iport; t=1433447517; x=1434657117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ofcf1ofsm0GPQwo562uk0ZP6OJYd5IOPWjs7hgOWXlk=; b=dftAODRbbCg4C9VbJTBOIphqiliibZfHvwucS38+88UE4l1OnByLz+/i IvTZvClD0DV863b70WUCne3siAABS00ubq5tBCxOuIFO2C4oU9lH2ObHx Zt8CdejwWw3z4ALSKe/gkf/4fYfiNvlfGYYlYfh4E2czr3+rplmHt4kxr M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A3BAC6q3BV/4UNJK1bDoMCVF4Ggxi7LgmBXIV1AhyBHzgUAQEBAQEBAYEKhCIBAQEDASMRRQULAgEIGAICJgICAjAVEAIEDgUWA4gMCA23daQUAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYoihCQvGBsHgmgvgRYFhUqNUIQ8YYYHgS+WISRhglg+bwGBA0KBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,554,1427760000"; d="scan'208";a="4596057" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jun 2015 19:51:56 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t54JptgJ031079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Jun 2015 19:51:55 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.183]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 4 Jun 2015 14:51:55 -0500 From: "Pal Martinsen (palmarti)" To: Joe Touch Thread-Topic: [Taps] TAPS Transports and ICMP Thread-Index: AQHQnrPt38kKNK6QP0icmFYJs5spRZ2c0L6AgAAqlgCAAANHAIAAC3cAgAAClACAAAmTAA== Date: Thu, 4 Jun 2015 19:51:55 +0000 Message-ID: <43C5480A-904D-4A7E-A181-08EBA709BC2A@cisco.com> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> <5570A452.8090209@isi.edu> In-Reply-To: <5570A452.8090209@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.232] Content-Type: text/plain; charset="utf-8" Content-ID: <3A3559D0408C9A40A34891E8EE7D1FC6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 19:51:58 -0000 DQo+IE9uIDA0IEp1biAyMDE1LCBhdCAyMToxNywgSm9lIFRvdWNoIDx0b3VjaEBpc2kuZWR1PiB3 cm90ZToNCj4gDQo+IA0KPiANCj4gT24gNi80LzIwMTUgMTI6MDggUE0sIFBhbCBNYXJ0aW5zZW4g KHBhbG1hcnRpKSB3cm90ZToNCj4gLi4uDQo+Pj4gVURQIHBhc3NlcyBhbGwgSUNNUCBtZXNzYWdl cyB0byB0aGUgYXBwLiBJZiB0aGUgYXBwIGRvZXNuJ3QgbGlzdGVuIGZvcg0KPj4+IGl0LCB0aGF0 4oCZcyB0aGUgYXBwJ3MgZGVjaXNpb24uDQo+Pj4gDQo+PiBUaGVuIHRoZXJlIGlzIGEgbG90IFVE UCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIG91dCB0aGVyZSB0aGF0IGRvZXMgbm90IGNhcmUuIA0K Pj4gDQo+PiBJbGwgZ3Vlc3Mgd2hhdCBJIGFtIGFza2luZyBpZiB3ZSBzaG91bGQgbWFrZSBsaWZl IGVhc2llciBmb3IgdGhlbS4NCj4gDQo+IEFnYWluLCBGSVJTVCB0aGlzIGRvYyBuZWVkcyB0byBl eHBsYWluIHRoZSBjdXJyZW50IGFic3RyYWN0IEFQSXMgZm9yDQo+IHRyYW5zcG9ydCBwcm90b2Nv bHMuDQo+IA0KPiBUSEVOIHdlIGNhbiBkZWNpZGUgd2hldGhlciB0aGF0IHNldCBlaXRoZXIgbmVl ZHMgdG8gYmUgYXVnbWVudGVkLA0KPiBkaW1pbmlzaGVkLCBvciB0cmFuc2xhdGVkIHRvIGJlIG1v cmUgdXNlZnVsIGZvciDigJxhcHBsaWNhdGlvbnMiLg0KDQoNCg0KSGVoLi4gSSBzdGlsbCBkbyBu b3QgZ2V0IHRoYXQuLg0KDQpGcm9tIHRoZSBBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHNlcnZpY2VzIHByb3ZpZGVkIGJ5IGV4aXN0aW5nIElFVEYgcHJvdG9jb2xzDQphbmQgY29u Z2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXMuICBJdCBpcyBkZXNpZ25lZCB0byBoZWxwDQphcHBs aWNhdGlvbiBhbmQgbmV0d29yayBzdGFjayBwcm9ncmFtbWVycyBhbmQgdG8gaW5mb3JtIHRoZSB3 b3JrIG9mDQp0aGUgSUVURiBUQVBTIFdvcmtpbmcgR3JvdXAuDQoNCg0KSGF2aW5nIGEgZGVzY3Jp cHRpb24gb2cgaG93IElDTVAgd29ya3MuIEJvdGggaW4gdGhlb3J5IChhYnN0cmFjdCBBUElzKSBh bmQgaW4gcHJhY3RpY2Ugd291bGQgaGVscCBhcHAgZGV2ZWxvcGVycy4NCg0KPiANCj4+Pj4gVW5m b3J0dW5hdGVseSBob3cgdG8gZG8gdGhpcyB2YXJpZXMgZnJvbSBPUyB0byBPUzoNCj4+Pj4gU2Vl IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJh Y2UtMDEjYXBwZW5kaXgtQS4yIGZvcg0KPj4+PiBleGFtcGxlcy4NCj4+PiANCj4+PiBZb3UgYXJl IGNvbmZ1c2luZyB0aGUgT1MgYW5kIGxhbmd1YWdlLWRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbiBv ZiB0aGUNCj4+PiBBUEkgd2l0aCB0aGUgYWJzdHJhY3QgQVBJLg0KPj4+IA0KPj4gT24gcHVycG9z ZS4gSSBoYXRlIGl0IHdoZW4gYSBmZWF0dXJlIHNob3VsZCB3b3JrIGJlY2F1c2UgaXQgc2F5cyBz byANCj4+IGluIGEgUkZDLCBidXQgdGhlIGltcGxlbWVudGF0aW9ucyBvZiBpdCBpcyBzbyB2YXN0 bHkgZGlmZmVyZW50IHRoYXQNCj4+IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBnZXQgdGhlIHRoaW5n IHRvIHdvcmsgc28gdGhlIGFwcCBkZXZlbG9wZXIganVzdA0KPj4gY2hvc2UgdG8gaWdub3JlIGl0 Lg0KPiANCj4gVGhlIElFVEYgc3RhbmRhcmRpemVzIHByb3RvY29scyBhbmQgYWJzdHJhY3QgQVBJ cy4NCj4gDQo+IElmIHlvdSBhcmUgY29uY2VybmVkIHdpdGggZGlmZmVyZW5jZXMgaW4gdGhlIGlt cGxlbWVudGF0aW9ucyBvZiB0aG9zZQ0KPiBhYnN0cmFjdCBBUElzLCB5b3UgbmVlZCB0byBhZGRy ZXNzIHRoZW0gaW4gb3RoZXIgb3JnYW5pemF0aW9ucyAoZS5nLiwNCj4gUE9TSVgsIGV0Yy4pLg0K PiANCg0KVGhhdCBzZWVtcyBsaWtlIGEgZnVuIHRhc2suLiAoU28gd2hvIGlzIG9uIHRoZSBsaXN0 OiBBcHBsZSwgTWljcm9zb2Z0LCBHb29nbGUoYW5kcm9pZCksIExpbnV4LCBCU0TigKYpDQoNCg0K PiAuLi4NCj4+PiBSRkMxMTIyIHJlcXVpcmVzIHRoYXQgVURQIGltcGxlbWVudGF0aW9ucyBtYWtl IHRoZSBJQ01QIHNpZ25hbHMNCj4+PiBhdmFpbGFibGUgdG8gdGhlIGFwcGxpY2F0aW9uLiBJdCBk b2VzIG5vdCBpbmRpY2F0ZSBieSB3aGF0IG1lY2hhbmlzbS4NCj4+PiANCj4+Pj4gTGlzdGVuaW5n IGZvciBwb3J0IHVucmVhY2hhYmxlIGNhbiBiZSBuaWNlIHRvIGF2b2lkIHNwYW1taW5nIGEgaG9z dCBvcg0KPj4+PiBhcHBsaWNhdGlvbiB0aGF0IHJlY2VudGx5IGNyYXNoZWQuIERldGVjdGluZyBm cmFnbWVudGF0aW9uIG9yIG1heCBNVFUgaXMNCj4+Pj4gYWxzbyBhIG5pY2UgZmVhdHVyZSBlc3Bl Y2lhbGx5IFZvSVAgYXBwbGljYXRpb25zIHNlbmRpbmcgdmlkZW8gY2FuDQo+Pj4+IHV0aWxpc2Ug dG8gb3B0aW1pc2UgdGhlaXIgcGFja2V0IHNpemVzLiANCj4+PiANCj4+PiBVRFAgaXMgcmVxdWly ZWQgdG8gcGFzcyBBTEwgSUNNUCBtZXNzYWdlcyB0byB0aGUgYXBwIGxheWVyLCBhcyBwZXIgUkZD IDExMjIuDQo+PiANCj4+IFRoYXQgaXMgYW5vdGhlciBwcm9ibGVtLiBBbiBhcHAgdXNpbmcgcG9y dCA1NTU1IHdpbGwgcmVjZWl2ZSBhbGwNCj4+IElDTVAgbWVzc2FnZXMgYWxzbyBnZW5lcmF0ZWQg Ynkgb3RoZXIgYXBwcyBydW5uaW5nIG9uIG90aGVyIHBvcnRzLg0KPiANCj4gVGhhdCdzIGFuIGlu Y29ycmVjdCBpbXBsZW1lbnRhdGlvbi4gU2VlIFJGQzExMjIgU2VjdGlvbiA0LjEuMy4zLg0KPiAN ClRoZSBzZWN0aW9uIHNheXM6DQpVRFAgTVVTVCBwYXNzIHRvIHRoZSBhcHBsaWNhdGlvbiBsYXll ciBhbGwgSUNNUCBlcnJvcg0KbWVzc2FnZXMgdGhhdCBpdCByZWNlaXZlcyBmcm9tIHRoZSBJUCBs YXllci4gIENvbmNlcHR1YWxseQ0KYXQgbGVhc3QsIHRoaXMgbWF5IGJlIGFjY29tcGxpc2hlZCB3 aXRoIGFuIHVwY2FsbCB0byB0aGUNCkVSUk9SX1JFUE9SVCByb3V0aW5lIChzZWUgDQpTZWN0aW9u IDQuMi40LjEpLg0KDQpMb29rcyBsaWtlIG5vbmUgdGhlIGltcGxlbWVudGVycyBkbyBzZW5kIGFu eSBJQ01QIG1lc3NhZ2VzIHRvIHRoZSBVRFAgbGF5ZXIuIFNvIHRlY2huaWNhbGx5IHRoZXkgYXJl IG5vdCB2aW9sYXRpbmcgdGhpcyBwYXJ0IG9mIHRoZSBzcGVjLiANCg0KDQo+IC4uLg0KPj4gU28g dGhpcyBib2lscyBkb3duIGJldHRlciBlZHVjYXRpb24gb2YgdGhlIGFwcCBkZXZlbG9wZXJzPw0K PiANCj4gTm8sIGluIHRoYXQgY2FzZSB5b3UgaGF2ZSBhIGJ1Zy4gVGhlIG9ubHkgdGhpbmcgdGhl IFVEUCBhcHAgaGFzIHRvIHdvcnJ5DQo+IGFib3V0IGFyZSBJQ01QcyBmcm9tIG90aGVyIGFwcHMg dXNpbmcgdGhlIHNhbWUgcG9ydC4NCg0KRG8geW91IGhhdmUgYW55IHJlYWwgY29kZSB0byBzaG93 IHRoYXQgdGhpcyBhY3R1YWxseSB3b3JrIGFzIGRlc2NyaWJlZCBvbiBhbnkgcGxhdGZvcm0/DQoN CklmIG5vYm9keSBhY3R1YWxseSBmb2xsb3dzIGl0IEkgd291bGQgY29uc2lkZXIgaXQgYSBkZWFk IHNwZWMuIEkgdGhvdWdodCBpbiB0aGUgZ29vZCBvbGQgZGF5cyB0d28gdmFyaW91cyBpbXBsZW1l bnRhdGlvbnMgd2FzIG5lZWRlZCB0byBnZXQgdGhlIFJGQyB0aHJvdWdoPw0KSSByZWFsbHkgaG9w ZSB3ZSBjYW4gZ2V0IG1vcmUgcnVubmluZyBjb2RlIGluIFRBUFMgYW5kIG5vdCBoaWRlIGJlaGlu ZCB2aXJ0dWFsIGludGVyZmFjZXMuIA0KDQouLS4NClDDpWwtRXJpaw0KDQoNCj4gDQo+Pj4+PiBU Q1AgcGFzc2VzIG9ubHkgZGVzdCB1bnJlYWNoYWJsZSB0eXBlcyAwLCAxLCBhbmQgNSwgdGltZSBl eGNlZWRlZCBhbmQNCj4+Pj4+IHBhcmFtZXRlciBwcm9ibGVtLiBBbGwgb3RoZXJzIGl0IGludGVy cHJldHMgb3IgaWdub3JlcyBpbnRlcm5hbGx5IGFuZA0KPj4+Pj4gaXTigJlzIG5vdCBjbGVhciBp dCBzaG91bGQgcGFzcyB1cCB0byB0aGUgYXBwLg0KPj4+PiANCj4+Pj4gVGhhdCBpcyBleGFjdGx5 IHRoYXQga2luZCBvZiBpbmZvcm1hdGlvbiBJIHdvdWxkIGZpbmQgdXNlZnVsIGluIHRoZQ0KPj4+ PiB0cmFuc3BvcnRzIGRyYWZ0Lg0KPj4+IA0KPj4+IFdlbGwsIHllcyAtIElNTywgdGhhdOKAmXMg YmVjYXVzZSBpdCdzIHBhcnQgb2YgdGhlIGFic3RyYWN0IEFQSS4NCj4+PiANCj4+IENhbiB0aGV5 IGF0IGxlYXN0IGNpdGUgUkZDIDExMjIgdGhlbj8NCj4gDQo+IEkgd291bGQgaG9wZSBzby4NCj4g DQo+IEpvZQ0KDQo= From nobody Thu Jun 4 13:56:37 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AC1ABD3F for ; Thu, 4 Jun 2015 13:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8cMsfC9_u6c for ; Thu, 4 Jun 2015 13:56:33 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B697E1ABD3E for ; Thu, 4 Jun 2015 13:56:33 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t54KuDWS028502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 13:56:13 -0700 (PDT) Message-ID: <5570BB6C.2070905@isi.edu> Date: Thu, 04 Jun 2015 13:56:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> <5570A452.8090209@isi.edu> <43C5480A-904D-4A7E-A181-08EBA709BC2A@cisco.com> In-Reply-To: <43C5480A-904D-4A7E-A181-08EBA709BC2A@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t54KuDWS028502 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 20:56:36 -0000 On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote: > >> On 04 Jun 2015, at 21:17, Joe Touch wrote: >> >> >> >> On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote: >> ... >>>> UDP passes all ICMP messages to the app. If the app doesn't listen for >>>> it, that’s the app's decision. >>>> >>> Then there is a lot UDP application developers out there that does not care. >>> >>> Ill guess what I am asking if we should make life easier for them. >> >> Again, FIRST this doc needs to explain the current abstract APIs for >> transport protocols. >> >> THEN we can decide whether that set either needs to be augmented, >> diminished, or translated to be more useful for “applications". > > Heh.. I still do not get that.. > >>From the Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. *existing* That means we need to document WHAT IS before deciding to pursue WHAT SHOULD BE. > It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. > > > Having a description of how ICMP works. Both in theory (abstract > APIs) and in practice would help app developers. In theory, it behaves like RFC 792 and RFC 1122 specify. In practice, we can measure whether those capabilities are supported or not (but that's not particularly the scope of TAPS). However, that does not necessarily require documenting the Java interface to TCP on Linux CentOS v7. That what man pages are for. >>>>> Unfortunately how to do this varies from OS to OS: >>>>> See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 for >>>>> examples. >>>> >>>> You are confusing the OS and language-dependent implementation of the >>>> API with the abstract API. >>>> >>> On purpose. I hate it when a feature should work because it says so >>> in a RFC, but the implementations of it is so vastly different that >>> it is not possible to get the thing to work so the app developer just >>> chose to ignore it. >> >> The IETF standardizes protocols and abstract APIs. >> >> If you are concerned with differences in the implementations of those >> abstract APIs, you need to address them in other organizations (e.g., >> POSIX, etc.). >> > > That seems like a fun task.. (So who is on the list: Apple, > Microsoft, Google(android), Linux, BSD…) POSIX is maintained by the IEEE, and defines the common API across various OS implementations - and yes, some of those orgs participate. That's far outside the scope of the IETF, though. >> ... >>>> RFC1122 requires that UDP implementations make the ICMP signals >>>> available to the application. It does not indicate by what mechanism. >>>> >>>>> Listening for port unreachable can be nice to avoid spamming a host or >>>>> application that recently crashed. Detecting fragmentation or max MTU is >>>>> also a nice feature especially VoIP applications sending video can >>>>> utilise to optimise their packet sizes. >>>> >>>> UDP is required to pass ALL ICMP messages to the app layer, as per RFC 1122. >>> >>> That is another problem. An app using port 5555 will receive all >>> ICMP messages also generated by other apps running on other ports. >> >> That's an incorrect implementation. See RFC1122 Section 4.1.3.3. >> > The section says: > UDP MUST pass to the application layer all ICMP error > messages that it receives from the IP layer. Conceptually > at least, this may be accomplished with an upcall to the > ERROR_REPORT routine (see > Section 4.2.4.1). > > Looks like none the implementers do send any ICMP messages to the > UDP layer. Here's an example of how an app can get errors in response to a call: http://stackoverflow.com/questions/4888285/send-an-udp-packet-and-receive-an-icmp-response-from-router-in-c The app can get async errors (i.e., not in response to a given sendmsg or recvmsg call) by using a connect() to the socket - i.e., creating a handle by which the OS can signal the app. See the book excerpt here: https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA249&lpg=PA249&dq=socket+errors+icmp&source=bl&ots=Ks3APlbjQs&sig=aBvReFfOYShEGtJtvEheG-8HpnI&hl=en&sa=X&ei=lLpwVdLHJZSZoQSxtYKwCw&ved=0CDMQ6AEwAg#v=onepage&q=socket%20errors%20icmp&f=false AFAICT, this is widely supported. >> ... >>> So this boils down better education of the app developers? >> >> No, in that case you have a bug. The only thing the UDP app has to worry >> about are ICMPs from other apps using the same port. > > Do you have any real code to show that this actually work as described on any platform? See above. Joe From nobody Thu Jun 4 14:04:20 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D469E1AC3B8 for ; Thu, 4 Jun 2015 14:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 6krnNtN3JfAF for ; Thu, 4 Jun 2015 14:04:18 -0700 (PDT) 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 6401F1AC3B6 for ; Thu, 4 Jun 2015 14:04:18 -0700 (PDT) Received: from [192.168.1.200] (p508F1FC0.dip0.t-ipconnect.de [80.143.31.192]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C1F041C104358; Thu, 4 Jun 2015 23:04:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Tuexen In-Reply-To: <5570A452.8090209@isi.edu> Date: Thu, 4 Jun 2015 23:04:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <96579AAB-7E0E-46E3-8C8F-D33CBE5EFAE4@lurchi.franken.de> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> <5570A452.8090209@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Pal Martinsen \(palmarti\)" , "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 21:04:20 -0000 > On 04 Jun 2015, at 21:17, Joe Touch wrote: >=20 >=20 >=20 > On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote: > ... >>> UDP passes all ICMP messages to the app. If the app doesn't listen = for >>> it, that=E2=80=99s the app's decision. >>>=20 >> Then there is a lot UDP application developers out there that does = not care.=20 >>=20 >> Ill guess what I am asking if we should make life easier for them. >=20 > Again, FIRST this doc needs to explain the current abstract APIs for > transport protocols. >=20 > THEN we can decide whether that set either needs to be augmented, > diminished, or translated to be more useful for "applications". >=20 >>>> Unfortunately how to do this varies from OS to OS: >>>> See = https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2= for >>>> examples. >>>=20 >>> You are confusing the OS and language-dependent implementation of = the >>> API with the abstract API. >>>=20 >> On purpose. I hate it when a feature should work because it says so=20= >> in a RFC, but the implementations of it is so vastly different that >> it is not possible to get the thing to work so the app developer just >> chose to ignore it. >=20 > The IETF standardizes protocols and abstract APIs. In the case of SCTP, the IETF also specifies an extension to the socket API covering SCTP. See https://tools.ietf.org/html/rfc6458 and corresponding "Socket API Consideration" sections in SCTP = specifications. An abstract API is specified in https://tools.ietf.org/html/rfc4960#section-10 However, this doesn't help for writing portable application. Therefore, having RFC 6458 has helped to guide the SCTP implementations in FreeBSD, Linux and Solaris to provide implementations for which you can write programs for. Best regards Michael >=20 > If you are concerned with differences in the implementations of those > abstract APIs, you need to address them in other organizations (e.g., > POSIX, etc.). >=20 > ... >>> RFC1122 requires that UDP implementations make the ICMP signals >>> available to the application. It does not indicate by what = mechanism. >>>=20 >>>> Listening for port unreachable can be nice to avoid spamming a host = or >>>> application that recently crashed. Detecting fragmentation or max = MTU is >>>> also a nice feature especially VoIP applications sending video can >>>> utilise to optimise their packet sizes.=20 >>>=20 >>> UDP is required to pass ALL ICMP messages to the app layer, as per = RFC 1122. >>=20 >> That is another problem. An app using port 5555 will receive all >> ICMP messages also generated by other apps running on other ports. >=20 > That's an incorrect implementation. See RFC1122 Section 4.1.3.3. >=20 > ... >> So this boils down better education of the app developers? >=20 > No, in that case you have a bug. The only thing the UDP app has to = worry > about are ICMPs from other apps using the same port. >=20 >>>>> TCP passes only dest unreachable types 0, 1, and 5, time exceeded = and >>>>> parameter problem. All others it interprets or ignores internally = and >>>>> it=E2=80=99s not clear it should pass up to the app. >>>>=20 >>>> That is exactly that kind of information I would find useful in the >>>> transports draft. >>>=20 >>> Well, yes - IMO, that=E2=80=99s because it's part of the abstract = API. >>>=20 >> Can they at least cite RFC 1122 then? >=20 > I would hope so. >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 4 14:12:58 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E765E1AC3D6 for ; Thu, 4 Jun 2015 14:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP8Eo0nYjJss for ; Thu, 4 Jun 2015 14:12:56 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D7901A1B8D for ; Thu, 4 Jun 2015 14:12:56 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t54LCMgi000818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 14:12:22 -0700 (PDT) Message-ID: <5570BF35.7000707@isi.edu> Date: Thu, 04 Jun 2015 14:12:21 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mohamed Oulmahdi , Michael Welzl References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t54LCMgi000818 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Christian Huitema , Brian Trammell , =?windows-1252?Q?Mirja_K=FChlewind?= , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 21:12:57 -0000 On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote: > I think that speaking specifically about any protocol in this document > will not be in the sens of an "abstract" interface for the Transport > layer, because abstraction means that application will no longer be > aware of who or what Transport services are really offered. We need to be more clear in what we are discussing. E.g., an "abstract API" (as I've been calling it) is described as in RFC 793: OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS That's abstract only in the sense that it does NOT specify an implementation in Linux, for example. It is not so abstract that it applies to all transports - it's indicated for TCP only. What you're proposing is a "universal interface", whether abstract (described as above, using words to describe app-level actions and events) or instantiated (e.g., using Unix socket(), connect(), accept(), listen(), etc.). Joe From nobody Thu Jun 4 14:23:02 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D851AC3F5 for ; Thu, 4 Jun 2015 14:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAwIZQVm2WBx for ; Thu, 4 Jun 2015 14:22:59 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD141AC3F0 for ; Thu, 4 Jun 2015 14:22:59 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t54LKcR4001787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2015 14:20:38 -0700 (PDT) Message-ID: <5570C125.1000903@isi.edu> Date: Thu, 04 Jun 2015 14:20:37 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Marie-Jose Montpetit , Christian Huitema References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch>, <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> In-Reply-To: <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t54LKcR4001787 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , =?windows-1252?Q?Mirja_K=FChlewi?= =?windows-1252?Q?nd?= , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 21:23:01 -0000 On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote: > In my presentation in Dallas I had suggested adding RTP (and even > HTTP) because as both Mirja and Christian mention some 'applications' > are requesting functionalities that are got given elsewhere. The core of this issue is "what is a transport protocol". To the user, "transport" is the entire stack between their program and the network (IP) layer - sometimes even including that (e.g., IPsec). To typical transport protocols (e.g., UDP, TCP), everything that accesses a transport protocol is the "application" layer. >From the document: Transport Service: a set of transport service features, without an association to any given framing protocol, which provides a complete service to an application. Transport Protocol: an implementation that provides one or more different transport services using a specific framing and header format on the wire. By those definitions, EVERYTHING between the user program and the link layer is arguably part of the services an app sees, which include "shim" services and layers such as: IPsec, TLS, and RTP. I would argue that HTTP is the application that uses TCP (or TLS/TCP), but not a separate service, but that's true only for conventional web service. There are many services built on top of HTTP, at which point HTTP is just another part of what this document calls a "transport service". As a result, unless you'll be describing every possible stack between the user program and the link layer, this document cannot proceed with the current definitions. Joe From nobody Fri Jun 5 00:25:21 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1C71B2CFA for ; Fri, 5 Jun 2015 00:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 Up4nLKXAoWgf for ; Fri, 5 Jun 2015 00:25:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F971B2CC9 for ; Fri, 5 Jun 2015 00:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=53612; q=dns/txt; s=iport; t=1433489116; x=1434698716; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EpSX9I2xmI1ld6cUgvzEKymfPvR2H6/W41+SoS9sj9U=; b=h5czXxW8vvakkbouxdQ11FowQip0QBlkguL+NJOs0ceCRKw5d2/4oZZr PuQhMLo1ROiWfzgVeKuur65aOgcxNY3vB1cnkGmhviX/vGPCi6MY9a8cx EBI09o1B3fVmv101Wra/gkxlqL6DmWN526KqC6pBSFqQLzHjK7CPvbbT6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C2AAC6TXFV/4wNJK1bDoI3S1ReBoMYrQiPKQVthXoCHIEUTAEBAQEBAYELhCMBAQQjVhACAQgtCwEGAwICAjAUEQIEDgUWA4gUDbdGpBgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0OEaxcEBwqCXi+BFgWFS4sUgkCEP2GBMYRWgS8+hjmPLyRhgSgcgRQ+bwGBRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,557,1427760000"; d="scan'208,217";a="425504410" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jun 2015 07:25:15 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t557PFdT027775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 07:25:15 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.183]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 02:25:14 -0500 From: "Pal Martinsen (palmarti)" To: Joe Touch Thread-Topic: [Taps] TAPS Transports and ICMP Thread-Index: AQHQnrPt38kKNK6QP0icmFYJs5spRZ2c0L6AgAAqlgCAAANHAIAAC3cAgAAClACAAAmTAIAAEfcAgACvvgA= Date: Fri, 5 Jun 2015 07:25:13 +0000 Message-ID: <9288CE6B-2BEE-4E11-AD79-9C7601AFB27B@cisco.com> References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> <5570A452.8090209@isi.edu> <43C5480A-904D-4A7E-A181-08EBA709BC2A@cisco.com> <5570BB6C.2070905@isi.edu> In-Reply-To: <5570BB6C.2070905@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.72.232] Content-Type: multipart/alternative; boundary="_000_9288CE6B2BEE4E11AD799C7601AFB27Bciscocom_" MIME-Version: 1.0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 07:25:19 -0000 --_000_9288CE6B2BEE4E11AD799C7601AFB27Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiAwNCBKdW4gMjAxNSwgYXQgMjI6NTYsIEpvZSBUb3VjaCA8dG91Y2hAaXNpLmVkdTxtYWls dG86dG91Y2hAaXNpLmVkdT4+IHdyb3RlOg0KDQoNCg0KT24gNi80LzIwMTUgMTI6NTEgUE0sIFBh bCBNYXJ0aW5zZW4gKHBhbG1hcnRpKSB3cm90ZToNCg0KT24gMDQgSnVuIDIwMTUsIGF0IDIxOjE3 LCBKb2UgVG91Y2ggPHRvdWNoQGlzaS5lZHU8bWFpbHRvOnRvdWNoQGlzaS5lZHU+PiB3cm90ZToN Cg0KDQoNCk9uIDYvNC8yMDE1IDEyOjA4IFBNLCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgd3Jv dGU6DQouLi4NClVEUCBwYXNzZXMgYWxsIElDTVAgbWVzc2FnZXMgdG8gdGhlIGFwcC4gSWYgdGhl IGFwcCBkb2Vzbid0IGxpc3RlbiBmb3INCml0LCB0aGF04oCZcyB0aGUgYXBwJ3MgZGVjaXNpb24u DQoNClRoZW4gdGhlcmUgaXMgYSBsb3QgVURQIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgb3V0IHRo ZXJlIHRoYXQgZG9lcyBub3QgY2FyZS4NCg0KSWxsIGd1ZXNzIHdoYXQgSSBhbSBhc2tpbmcgaWYg d2Ugc2hvdWxkIG1ha2UgbGlmZSBlYXNpZXIgZm9yIHRoZW0uDQoNCkFnYWluLCBGSVJTVCB0aGlz IGRvYyBuZWVkcyB0byBleHBsYWluIHRoZSBjdXJyZW50IGFic3RyYWN0IEFQSXMgZm9yDQp0cmFu c3BvcnQgcHJvdG9jb2xzLg0KDQpUSEVOIHdlIGNhbiBkZWNpZGUgd2hldGhlciB0aGF0IHNldCBl aXRoZXIgbmVlZHMgdG8gYmUgYXVnbWVudGVkLA0KZGltaW5pc2hlZCwgb3IgdHJhbnNsYXRlZCB0 byBiZSBtb3JlIHVzZWZ1bCBmb3Ig4oCcYXBwbGljYXRpb25zIi4NCg0KSGVoLi4gSSBzdGlsbCBk byBub3QgZ2V0IHRoYXQuLg0KDQpGcm9tIHRoZSBBYnN0cmFjdDoNClRoaXMgZG9jdW1lbnQgZGVz Y3JpYmVzIHNlcnZpY2VzIHByb3ZpZGVkIGJ5IGV4aXN0aW5nIElFVEYgcHJvdG9jb2xzDQphbmQg Y29uZ2VzdGlvbiBjb250cm9sIG1lY2hhbmlzbXMuDQoNCipleGlzdGluZyoNCg0KVGhhdCBtZWFu cyB3ZSBuZWVkIHRvIGRvY3VtZW50IFdIQVQgSVMgYmVmb3JlIGRlY2lkaW5nIHRvIHB1cnN1ZSBX SEFUDQpTSE9VTEQgQkUuDQoNCklDTVAgaXMgYW4gKmV4aXN0aW5nKiBwcm90b2NvbC4gTm90IGEg dHJhbnNwb3J0IHByb3RvY29sLCBidXQgYSBzZXJ2aWNlKD8pIHRoYXQgYWZmZWN0cyBob3cgdGhl IG90aGVyIHByb3RvY29scyBiZWhhdmVzLg0KDQpBbGwgSSBhbSBvYnNlcnZpbmcgaXMgdGhhdCB0 aGlzIGlzIHNvbWV0aGluZyBhcHAgZGV2ZWxvcGVycyByYXJlbHkgY2FyZXMgYWJvdXQsIGFuZCBo YXZpbmcgc2VjdGlvbnMgaW4gdGhlIFRBUFMgdHJhbnNwb3J0cyBkcmFmdCBkZXNjcmliaW5nIGl0 IG1pZ2h0IGhlbHAuIFdoeSBhcmUgdGhlcmUgc2VjdGlvbnMgZGVzY3JpYmluZyBUQ1AsIHRoZXkg Y291bGQganVzdCByZWFkIFJGQyA3OTM/DQoNCg0KSXQgaXMgZGVzaWduZWQgdG8gaGVscA0KYXBw bGljYXRpb24gYW5kIG5ldHdvcmsgc3RhY2sgcHJvZ3JhbW1lcnMgYW5kIHRvIGluZm9ybSB0aGUg d29yayBvZg0KdGhlIElFVEYgVEFQUyBXb3JraW5nIEdyb3VwLg0KDQoNCkhhdmluZyBhIGRlc2Ny aXB0aW9uIG9mIGhvdyBJQ01QIHdvcmtzLiBCb3RoIGluIHRoZW9yeSAoYWJzdHJhY3QNCkFQSXMp IGFuZCBpbiBwcmFjdGljZSB3b3VsZCBoZWxwIGFwcCBkZXZlbG9wZXJzLg0KDQpJbiB0aGVvcnks IGl0IGJlaGF2ZXMgbGlrZSBSRkMgNzkyIGFuZCBSRkMgMTEyMiBzcGVjaWZ5Lg0KDQpJbiBwcmFj dGljZSwgd2UgY2FuIG1lYXN1cmUgd2hldGhlciB0aG9zZSBjYXBhYmlsaXRpZXMgYXJlIHN1cHBv cnRlZCBvcg0Kbm90IChidXQgdGhhdCdzIG5vdCBwYXJ0aWN1bGFybHkgdGhlIHNjb3BlIG9mIFRB UFMpLg0KDQpIb3dldmVyLCB0aGF0IGRvZXMgbm90IG5lY2Vzc2FyaWx5IHJlcXVpcmUgZG9jdW1l bnRpbmcgdGhlIEphdmENCmludGVyZmFjZSB0byBUQ1Agb24gTGludXggQ2VudE9TIHY3LiBUaGF0 IHdoYXQgbWFuIHBhZ2VzIGFyZSBmb3IuDQoNCg0KTm8sIGJ1dCBwb2ludGluZyBvdXQgdGhhdCB0 aGVyZSBhcmUgZGlmZmVyZW5jZXMgb3V0IHRoZXJlIGFuZCBhcHAgZGV2ZWxvcGVycyBzaG91bGQg dGFrZSBjYXJlIGFuZCBpbnZlc3RpZ2F0ZSBpcyBhIHVzZWZ1bCBoaW50Lg0KDQpVbmZvcnR1bmF0 ZWx5IGhvdyB0byBkbyB0aGlzIHZhcmllcyBmcm9tIE9TIHRvIE9TOg0KU2VlIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UtMDEjYXBwZW5k aXgtQS4yIGZvcg0KZXhhbXBsZXMuDQoNCllvdSBhcmUgY29uZnVzaW5nIHRoZSBPUyBhbmQgbGFu Z3VhZ2UtZGVwZW5kZW50IGltcGxlbWVudGF0aW9uIG9mIHRoZQ0KQVBJIHdpdGggdGhlIGFic3Ry YWN0IEFQSS4NCg0KT24gcHVycG9zZS4gSSBoYXRlIGl0IHdoZW4gYSBmZWF0dXJlIHNob3VsZCB3 b3JrIGJlY2F1c2UgaXQgc2F5cyBzbw0KaW4gYSBSRkMsIGJ1dCB0aGUgaW1wbGVtZW50YXRpb25z IG9mIGl0IGlzIHNvIHZhc3RseSBkaWZmZXJlbnQgdGhhdA0KaXQgaXMgbm90IHBvc3NpYmxlIHRv IGdldCB0aGUgdGhpbmcgdG8gd29yayBzbyB0aGUgYXBwIGRldmVsb3BlciBqdXN0DQpjaG9zZSB0 byBpZ25vcmUgaXQuDQoNClRoZSBJRVRGIHN0YW5kYXJkaXplcyBwcm90b2NvbHMgYW5kIGFic3Ry YWN0IEFQSXMuDQoNCklmIHlvdSBhcmUgY29uY2VybmVkIHdpdGggZGlmZmVyZW5jZXMgaW4gdGhl IGltcGxlbWVudGF0aW9ucyBvZiB0aG9zZQ0KYWJzdHJhY3QgQVBJcywgeW91IG5lZWQgdG8gYWRk cmVzcyB0aGVtIGluIG90aGVyIG9yZ2FuaXphdGlvbnMgKGUuZy4sDQpQT1NJWCwgZXRjLikuDQoN Cg0KVGhhdCBzZWVtcyBsaWtlIGEgZnVuIHRhc2suLiAoU28gd2hvIGlzIG9uIHRoZSBsaXN0OiBB cHBsZSwNCk1pY3Jvc29mdCwgR29vZ2xlKGFuZHJvaWQpLCBMaW51eCwgQlNE4oCmKQ0KDQpQT1NJ WCBpcyBtYWludGFpbmVkIGJ5IHRoZSBJRUVFLCBhbmQgZGVmaW5lcyB0aGUgY29tbW9uIEFQSSBh Y3Jvc3MNCnZhcmlvdXMgT1MgaW1wbGVtZW50YXRpb25zIC0gYW5kIHllcywgc29tZSBvZiB0aG9z ZSBvcmdzIHBhcnRpY2lwYXRlLg0KDQpUaGF04oCZcyBmYXIgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhlIElFVEYsIHRob3VnaC4NCg0KDQpUaGF0IEkgYWdyZWUgb24uIFRoZSBkaXNjdXNzaW9uIGlz IHByb2JhYmx5IGJldHRlciBoYWQgb3ZlciBhIGJlZXIuIEkgZG8gZmVlbCB0aGF0IGl0IGlzIGlt cG9ydGFudCB0aGF0IElFVEYgZG8gdGFrZSBpbnRvIGFjY291bnQgd2hhdCBpcyBhY3R1YWxseSB1 c2VkIGluIHRoZSB3aWxkLg0KDQoNCi4uLg0KUkZDMTEyMiByZXF1aXJlcyB0aGF0IFVEUCBpbXBs ZW1lbnRhdGlvbnMgbWFrZSB0aGUgSUNNUCBzaWduYWxzDQphdmFpbGFibGUgdG8gdGhlIGFwcGxp Y2F0aW9uLiBJdCBkb2VzIG5vdCBpbmRpY2F0ZSBieSB3aGF0IG1lY2hhbmlzbS4NCg0KTGlzdGVu aW5nIGZvciBwb3J0IHVucmVhY2hhYmxlIGNhbiBiZSBuaWNlIHRvIGF2b2lkIHNwYW1taW5nIGEg aG9zdCBvcg0KYXBwbGljYXRpb24gdGhhdCByZWNlbnRseSBjcmFzaGVkLiBEZXRlY3RpbmcgZnJh Z21lbnRhdGlvbiBvciBtYXggTVRVIGlzDQphbHNvIGEgbmljZSBmZWF0dXJlIGVzcGVjaWFsbHkg Vm9JUCBhcHBsaWNhdGlvbnMgc2VuZGluZyB2aWRlbyBjYW4NCnV0aWxpc2UgdG8gb3B0aW1pc2Ug dGhlaXIgcGFja2V0IHNpemVzLg0KDQpVRFAgaXMgcmVxdWlyZWQgdG8gcGFzcyBBTEwgSUNNUCBt ZXNzYWdlcyB0byB0aGUgYXBwIGxheWVyLCBhcyBwZXIgUkZDIDExMjIuDQoNClRoYXQgaXMgYW5v dGhlciBwcm9ibGVtLiBBbiBhcHAgdXNpbmcgcG9ydCA1NTU1IHdpbGwgcmVjZWl2ZSBhbGwNCklD TVAgbWVzc2FnZXMgYWxzbyBnZW5lcmF0ZWQgYnkgb3RoZXIgYXBwcyBydW5uaW5nIG9uIG90aGVy IHBvcnRzLg0KDQpUaGF0J3MgYW4gaW5jb3JyZWN0IGltcGxlbWVudGF0aW9uLiBTZWUgUkZDMTEy MiBTZWN0aW9uIDQuMS4zLjMuDQoNClRoZSBzZWN0aW9uIHNheXM6DQpVRFAgTVVTVCBwYXNzIHRv IHRoZSBhcHBsaWNhdGlvbiBsYXllciBhbGwgSUNNUCBlcnJvcg0KbWVzc2FnZXMgdGhhdCBpdCBy ZWNlaXZlcyBmcm9tIHRoZSBJUCBsYXllci4gIENvbmNlcHR1YWxseQ0KYXQgbGVhc3QsIHRoaXMg bWF5IGJlIGFjY29tcGxpc2hlZCB3aXRoIGFuIHVwY2FsbCB0byB0aGUNCkVSUk9SX1JFUE9SVCBy b3V0aW5lIChzZWUNClNlY3Rpb24gNC4yLjQuMSkuDQoNCkxvb2tzIGxpa2Ugbm9uZSB0aGUgaW1w bGVtZW50ZXJzIGRvIHNlbmQgYW55IElDTVAgbWVzc2FnZXMgdG8gdGhlDQpVRFAgbGF5ZXIuDQoN CkhlcmUncyBhbiBleGFtcGxlIG9mIGhvdyBhbiBhcHAgY2FuIGdldCBlcnJvcnMgaW4gcmVzcG9u c2UgdG8gYSBjYWxsOg0KaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL3F1ZXN0aW9ucy80ODg4Mjg1 L3NlbmQtYW4tdWRwLXBhY2tldC1hbmQtcmVjZWl2ZS1hbi1pY21wLXJlc3BvbnNlLWZyb20tcm91 dGVyLWluLWMNCg0KWWVzLCBJIGNpdGVkIGNvZGUgZXhhbXBsZSBlYXJsaWVyLg0KDQpUaGUgYWJv dmUgY29kZSBkb2VzIG5vdCBmbHkgc28gd2VsbCB1bmxlc3MgeW91IGhhdmUgYWRtaW5pc3RyYXRp dmUgcHJpdmlsZWdlcy4NCg0KSSBkaWQgYSBzZXJpZXMgb2YgdGVzdHMgYSB3aGlsZSBiYWNrLiBD b2RlIHRoYXQgd29ya3Mgb24gT1MtWCwgTGludXggYW5kIElPUyBjYW4gYmUgZm91bmQgaGVyZToN Cmh0dHBzOi8vZ2l0aHViLmNvbS9wYWxlcmlrbS9JQ01QVGVzdA0KDQpIYXZlIGNvZGUgZm9yIHdp bmRvd3MgYXMgd2VsbCwgYnV0IHRoYXQgYWRkcyBhbm90aGVyIGxheWVyIG9mIGNvbXBsZXhpdHkg YW5kIHdlaXJkbmVzcy4NCg0KVGhlIGFwcCBjYW4gZ2V0IGFzeW5jIGVycm9ycyAoaS5lLiwgbm90 IGluIHJlc3BvbnNlIHRvIGEgZ2l2ZW4gc2VuZG1zZw0Kb3IgcmVjdm1zZyBjYWxsKSBieSB1c2lu ZyBhIGNvbm5lY3QoKSB0byB0aGUgc29ja2V0IC0gaS5lLiwgY3JlYXRpbmcgYQ0KaGFuZGxlIGJ5 IHdoaWNoIHRoZSBPUyBjYW4gc2lnbmFsIHRoZSBhcHAuDQoNClNlZSB0aGUgYm9vayBleGNlcnB0 IGhlcmU6DQpodHRwczovL2Jvb2tzLmdvb2dsZS5jb20vYm9va3M/aWQ9cHRTQzRMcHdHQTBDJnBn PVBBMjQ5JmxwZz1QQTI0OSZkcT1zb2NrZXQrZXJyb3JzK2ljbXAmc291cmNlPWJsJm90cz1LczNB UGxialFzJnNpZz1hQnZSZUZmT1lTaEVHdEp0dkVoZUctOEhwbkkmaGw9ZW4mc2E9WCZlaT1sTHB3 VmRMSEpaU1pvUVN4dFlLd0N3JnZlZD0wQ0RNUTZBRXdBZyN2PW9uZXBhZ2UmcT1zb2NrZXQlMjBl cnJvcnMlMjBpY21wJmY9ZmFsc2UNCg0KQUZBSUNULCB0aGlzIGlzIHdpZGVseSBzdXBwb3J0ZWQu DQoNCldlIGFwcGFyZW50bHkgbGl2ZSBpbiB0d28gZGlmZmVyZW50IHJlYWxpdGllcy4gRmlndXJp bmcgb3V0IGhvdyB0aGlzIHdvcmsgYW5kIGltcGxlbWVudGluZyBjcm9zcyBwbGF0Zm9ybSBhcHBs aWNhdGlvbiBjb2RlIHRoYXQgZG9lcyB0aGlzIGlzIG5vdCB0cml2aWFsLg0KDQpUaGUgYWJvdmUg Ym9vayBkb2VzIG5vdCBkZXNjcmliZSBob3cgcmVjZW50IGxpbnV4IGtlcm5lbHMgaGFuZGxlcyBJ Q01QLg0KDQoNCi4tLg0KUMOlbC1FcmlrDQoNCi4uLg0KU28gdGhpcyBib2lscyBkb3duIGJldHRl ciBlZHVjYXRpb24gb2YgdGhlIGFwcCBkZXZlbG9wZXJzPw0KDQpObywgaW4gdGhhdCBjYXNlIHlv dSBoYXZlIGEgYnVnLiBUaGUgb25seSB0aGluZyB0aGUgVURQIGFwcCBoYXMgdG8gd29ycnkNCmFi b3V0IGFyZSBJQ01QcyBmcm9tIG90aGVyIGFwcHMgdXNpbmcgdGhlIHNhbWUgcG9ydC4NCg0KRG8g eW91IGhhdmUgYW55IHJlYWwgY29kZSB0byBzaG93IHRoYXQgdGhpcyBhY3R1YWxseSB3b3JrIGFz IGRlc2NyaWJlZCBvbiBhbnkgcGxhdGZvcm0/DQoNClNlZSBhYm92ZS4NCg0KSm9lDQoNCg== --_000_9288CE6B2BEE4E11AD799C7601AFB27Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <866BFDB856564842A2291116EAE162EC@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAwNCBK dW4gMjAxNSwgYXQgMjI6NTYsIEpvZSBUb3VjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvdWNoQGlz aS5lZHUiIGNsYXNzPSIiPnRvdWNoQGlzaS5lZHU8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9 IiI+T24NCiA2LzQvMjAxNSAxMjo1MSBQTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIHdyb3Rl Ojwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5P biAwNCBKdW4gMjAxNSwgYXQgMjE6MTcsIEpvZSBUb3VjaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRv dWNoQGlzaS5lZHUiIGNsYXNzPSIiPnRvdWNoQGlzaS5lZHU8L2E+Jmd0OyB3cm90ZTo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiA2 LzQvMjAxNSAxMjowOCBQTSwgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpIHdyb3RlOjxiciBjbGFz cz0iIj4NCi4uLjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+VURQIHBhc3NlcyBhbGwgSUNNUCBt ZXNzYWdlcyB0byB0aGUgYXBwLiBJZiB0aGUgYXBwIGRvZXNuJ3QgbGlzdGVuIGZvcjxiciBjbGFz cz0iIj4NCml0LCB0aGF04oCZcyB0aGUgYXBwJ3MgZGVjaXNpb24uPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhlbiB0aGVyZSBpcyBhIGxvdCBVRFAgYXBwbGlj YXRpb24gZGV2ZWxvcGVycyBvdXQgdGhlcmUgdGhhdCBkb2VzIG5vdCBjYXJlLjxzcGFuIGNsYXNz PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpJbGwgZ3Vlc3Mgd2hhdCBJIGFtIGFza2luZyBpZiB3ZSBzaG91bGQgbWFrZSBs aWZlIGVhc2llciBmb3IgdGhlbS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQpBZ2FpbiwgRklSU1QgdGhpcyBkb2MgbmVlZHMgdG8gZXhwbGFpbiB0aGUgY3VycmVu dCBhYnN0cmFjdCBBUElzIGZvcjxiciBjbGFzcz0iIj4NCnRyYW5zcG9ydCBwcm90b2NvbHMuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVEhFTiB3ZSBjYW4gZGVjaWRlIHdoZXRoZXIgdGhh dCBzZXQgZWl0aGVyIG5lZWRzIHRvIGJlIGF1Z21lbnRlZCw8YnIgY2xhc3M9IiI+DQpkaW1pbmlz aGVkLCBvciB0cmFuc2xhdGVkIHRvIGJlIG1vcmUgdXNlZnVsIGZvciDigJxhcHBsaWNhdGlvbnMm cXVvdDsuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSGVoLi4g SSBzdGlsbCBkbyBub3QgZ2V0IHRoYXQuLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkZyb20gdGhlIEFic3RyYWN0OjxiciBjbGFz cz0iIj4NCjwvYmxvY2txdW90ZT4NClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHNlcnZpY2VzIHBy b3ZpZGVkIGJ5IGV4aXN0aW5nIElFVEYgcHJvdG9jb2xzPGJyIGNsYXNzPSIiPg0KYW5kIGNvbmdl c3Rpb24gY29udHJvbCBtZWNoYW5pc21zLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPipleGlzdGluZyo8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGF0DQogbWVh bnMgd2UgbmVlZCB0byBkb2N1bWVudCBXSEFUIElTIGJlZm9yZSBkZWNpZGluZyB0byBwdXJzdWUg V0hBVDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5TSE9VTEQNCiBCRS48L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj5JQ01QIGlzIGFuICpleGlzdGluZyogcHJvdG9jb2wuIE5vdCBhIHRyYW5zcG9ydCBwcm90b2Nv bCwgYnV0IGEgc2VydmljZSg/KSB0aGF0IGFmZmVjdHMgaG93IHRoZSBvdGhlciBwcm90b2NvbHMg YmVoYXZlcy48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkFsbCBJIGFt IG9ic2VydmluZyBpcyB0aGF0IHRoaXMgaXMgc29tZXRoaW5nIGFwcCBkZXZlbG9wZXJzIHJhcmVs eSBjYXJlcyBhYm91dCwgYW5kIGhhdmluZyBzZWN0aW9ucyBpbiB0aGUgVEFQUyB0cmFuc3BvcnRz IGRyYWZ0IGRlc2NyaWJpbmcgaXQgbWlnaHQgaGVscC4gV2h5IGFyZSB0aGVyZSBzZWN0aW9ucyBk ZXNjcmliaW5nIFRDUCwgdGhleSBjb3VsZCBqdXN0IHJlYWQgUkZDIDc5Mz88L2Rpdj4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KSXQgaXMgZGVzaWduZWQg dG8gaGVscDxiciBjbGFzcz0iIj4NCmFwcGxpY2F0aW9uIGFuZCBuZXR3b3JrIHN0YWNrIHByb2dy YW1tZXJzIGFuZCB0byBpbmZvcm0gdGhlIHdvcmsgb2Y8YnIgY2xhc3M9IiI+DQp0aGUgSUVURiBU QVBTIFdvcmtpbmcgR3JvdXAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KSGF2aW5nIGEgZGVzY3JpcHRpb24gb2YgaG93IElDTVAgd29ya3MuIEJvdGggaW4gdGhl b3J5IChhYnN0cmFjdDxiciBjbGFzcz0iIj4NCkFQSXMpIGFuZCBpbiBwcmFjdGljZSB3b3VsZCBo ZWxwIGFwcCBkZXZlbG9wZXJzLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPkluDQogdGhlb3J5LCBpdCBiZWhhdmVzIGxpa2UgUkZDIDc5MiBhbmQgUkZD IDExMjIgc3BlY2lmeS48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Jbg0KIHByYWN0aWNlLCB3ZSBjYW4gbWVh c3VyZSB3aGV0aGVyIHRob3NlIGNhcGFiaWxpdGllcyBhcmUgc3VwcG9ydGVkIG9yPC9zcGFuPjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPm5vdA0KIChidXQgdGhhdCdzIG5vdCBwYXJ0aWN1bGFybHkgdGhl IHNjb3BlIG9mIFRBUFMpLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkhvd2V2ZXIsDQogdGhhdCBkb2VzIG5v dCBuZWNlc3NhcmlseSByZXF1aXJlIGRvY3VtZW50aW5nIHRoZSBKYXZhPC9zcGFuPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPmludGVyZmFjZQ0KIHRvIFRDUCBvbiBMaW51eCBDZW50T1MgdjcuIFRoYXQg d2hhdCBtYW4gcGFnZXMgYXJlIGZvci48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1 dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXY+Tm8sIGJ1dCBwb2ludGluZyBvdXQgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMg b3V0IHRoZXJlIGFuZCBhcHAgZGV2ZWxvcGVycyBzaG91bGQgdGFrZSBjYXJlIGFuZCBpbnZlc3Rp Z2F0ZSBpcyBhIHVzZWZ1bCBoaW50LiZuYnNwOzwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3Jw aGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPlVuZm9ydHVuYXRlbHkgaG93IHRvIGRvIHRoaXMgdmFyaWVz IGZyb20gT1MgdG8gT1M6PGJyIGNsYXNzPSIiPg0KU2VlPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tYXJ0aW5zZW4tdHJhbS1zdHVudHJhY2UtMDEjYXBwZW5kaXgtQS4yIiBjbGFz cz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tc3R1 bnRyYWNlLTAxI2FwcGVuZGl4LUEuMjwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+Zm9yPGJyIGNsYXNzPSIiPg0KZXhhbXBsZXMuPGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KWW91IGFyZSBjb25mdXNpbmcgdGhlIE9T IGFuZCBsYW5ndWFnZS1kZXBlbmRlbnQgaW1wbGVtZW50YXRpb24gb2YgdGhlPGJyIGNsYXNzPSIi Pg0KQVBJIHdpdGggdGhlIGFic3RyYWN0IEFQSS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8L2Jsb2NrcXVvdGU+DQpPbiBwdXJwb3NlLiBJIGhhdGUgaXQgd2hlbiBhIGZlYXR1cmUgc2hv dWxkIHdvcmsgYmVjYXVzZSBpdCBzYXlzIHNvPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCmluIGEgUkZDLCBidXQgdGhlIGltcGxl bWVudGF0aW9ucyBvZiBpdCBpcyBzbyB2YXN0bHkgZGlmZmVyZW50IHRoYXQ8YnIgY2xhc3M9IiI+ DQppdCBpcyBub3QgcG9zc2libGUgdG8gZ2V0IHRoZSB0aGluZyB0byB3b3JrIHNvIHRoZSBhcHAg ZGV2ZWxvcGVyIGp1c3Q8YnIgY2xhc3M9IiI+DQpjaG9zZSB0byBpZ25vcmUgaXQuPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgc3RhbmRhcmRpemVz IHByb3RvY29scyBhbmQgYWJzdHJhY3QgQVBJcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpJZiB5b3UgYXJlIGNvbmNlcm5lZCB3aXRoIGRpZmZlcmVuY2VzIGluIHRoZSBpbXBsZW1lbnRh dGlvbnMgb2YgdGhvc2U8YnIgY2xhc3M9IiI+DQphYnN0cmFjdCBBUElzLCB5b3UgbmVlZCB0byBh ZGRyZXNzIHRoZW0gaW4gb3RoZXIgb3JnYW5pemF0aW9ucyAoZS5nLiw8YnIgY2xhc3M9IiI+DQpQ T1NJWCwgZXRjLikuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0K PGJyIGNsYXNzPSIiPg0KVGhhdCBzZWVtcyBsaWtlIGEgZnVuIHRhc2suLiAoU28gd2hvIGlzIG9u IHRoZSBsaXN0OiBBcHBsZSw8YnIgY2xhc3M9IiI+DQpNaWNyb3NvZnQsIEdvb2dsZShhbmRyb2lk KSwgTGludXgsIEJTROKApik8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5QT1NJWA0KIGlzIG1haW50YWluZWQgYnkgdGhlIElFRUUsIGFuZCBkZWZpbmVz IHRoZSBjb21tb24gQVBJIGFjcm9zczwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj52YXJpb3Vz DQogT1MgaW1wbGVtZW50YXRpb25zIC0gYW5kIHllcywgc29tZSBvZiB0aG9zZSBvcmdzIHBhcnRp Y2lwYXRlLjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRoYXTigJlzDQogZmFyIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoZSBJRVRGLCB0aG91Z2guPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5l LWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NClRoYXQgSSBhZ3JlZSBvbi4g VGhlIGRpc2N1c3Npb24gaXMgcHJvYmFibHkgYmV0dGVyIGhhZCBvdmVyIGEgYmVlci4gSSBkbyBm ZWVsIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRoYXQgSUVURiBkbyB0YWtlIGludG8gYWNjb3VudCB3 aGF0IGlzIGFjdHVhbGx5IHVzZWQgaW4gdGhlIHdpbGQuJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4uLi48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPlJGQzExMjIgcmVxdWlyZXMgdGhhdCBVRFAgaW1wbGVtZW50YXRpb25zIG1ha2UgdGhl IElDTVAgc2lnbmFsczxiciBjbGFzcz0iIj4NCmF2YWlsYWJsZSB0byB0aGUgYXBwbGljYXRpb24u IEl0IGRvZXMgbm90IGluZGljYXRlIGJ5IHdoYXQgbWVjaGFuaXNtLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkxpc3RlbmluZyBm b3IgcG9ydCB1bnJlYWNoYWJsZSBjYW4gYmUgbmljZSB0byBhdm9pZCBzcGFtbWluZyBhIGhvc3Qg b3I8YnIgY2xhc3M9IiI+DQphcHBsaWNhdGlvbiB0aGF0IHJlY2VudGx5IGNyYXNoZWQuIERldGVj dGluZyBmcmFnbWVudGF0aW9uIG9yIG1heCBNVFUgaXM8YnIgY2xhc3M9IiI+DQphbHNvIGEgbmlj ZSBmZWF0dXJlIGVzcGVjaWFsbHkgVm9JUCBhcHBsaWNhdGlvbnMgc2VuZGluZyB2aWRlbyBjYW48 YnIgY2xhc3M9IiI+DQp1dGlsaXNlIHRvIG9wdGltaXNlIHRoZWlyIHBhY2tldCBzaXplcy48c3Bh biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KVURQIGlzIHJlcXVpcmVkIHRvIHBhc3Mg QUxMIElDTVAgbWVzc2FnZXMgdG8gdGhlIGFwcCBsYXllciwgYXMgcGVyIFJGQyAxMTIyLjxiciBj bGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRoYXQgaXMgYW5vdGhlciBw cm9ibGVtLiBBbiBhcHAgdXNpbmcgcG9ydCA1NTU1IHdpbGwgcmVjZWl2ZSBhbGw8YnIgY2xhc3M9 IiI+DQpJQ01QIG1lc3NhZ2VzIGFsc28gZ2VuZXJhdGVkIGJ5IG90aGVyIGFwcHMgcnVubmluZyBv biBvdGhlciBwb3J0cy48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQpUaGF0J3MgYW4gaW5jb3JyZWN0IGltcGxlbWVudGF0aW9uLiBTZWUgUkZDMTEyMiBTZWN0aW9u IDQuMS4zLjMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KVGhl IHNlY3Rpb24gc2F5czo8YnIgY2xhc3M9IiI+DQpVRFAgTVVTVCBwYXNzIHRvIHRoZSBhcHBsaWNh dGlvbiBsYXllciBhbGwgSUNNUCBlcnJvcjxiciBjbGFzcz0iIj4NCm1lc3NhZ2VzIHRoYXQgaXQg cmVjZWl2ZXMgZnJvbSB0aGUgSVAgbGF5ZXIuICZuYnNwO0NvbmNlcHR1YWxseTxiciBjbGFzcz0i Ij4NCmF0IGxlYXN0LCB0aGlzIG1heSBiZSBhY2NvbXBsaXNoZWQgd2l0aCBhbiB1cGNhbGwgdG8g dGhlPGJyIGNsYXNzPSIiPg0KRVJST1JfUkVQT1JUIHJvdXRpbmUgKHNlZTxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQpTZWN0aW9u IDQuMi40LjEpLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkxvb2tzIGxpa2Ugbm9uZSB0 aGUgaW1wbGVtZW50ZXJzIGRvIHNlbmQgYW55IElDTVAgbWVzc2FnZXMgdG8gdGhlPGJyIGNsYXNz PSIiPg0KVURQIGxheWVyLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPkhlcmUncw0KIGFuIGV4YW1wbGUgb2YgaG93IGFuIGFwcCBjYW4gZ2V0IGVycm9y cyBpbiByZXNwb25zZSB0byBhIGNhbGw6PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBs aW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL3F1 ZXN0aW9ucy80ODg4Mjg1L3NlbmQtYW4tdWRwLXBhY2tldC1hbmQtcmVjZWl2ZS1hbi1pY21wLXJl c3BvbnNlLWZyb20tcm91dGVyLWluLWMiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+aHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL3F1ZXN0aW9ucy80ODg4Mjg1L3NlbmQt YW4tdWRwLXBhY2tldC1hbmQtcmVjZWl2ZS1hbi1pY21wLXJlc3BvbnNlLWZyb20tcm91dGVyLWlu LWM8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIg c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj5ZZXMsIEkgY2l0ZWQgY29kZSBleGFtcGxlIGVhcmxpZXIuJm5ic3A7PC9k aXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGUgYWJvdmUgY29kZSBkb2Vz IG5vdCBmbHkgc28gd2VsbCB1bmxlc3MgeW91IGhhdmUgYWRtaW5pc3RyYXRpdmUgcHJpdmlsZWdl cy48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkkgZGlkIGEgc2VyaWVz IG9mIHRlc3RzIGEgd2hpbGUgYmFjay4gQ29kZSB0aGF0IHdvcmtzIG9uIE9TLVgsIExpbnV4IGFu ZCBJT1MgY2FuIGJlIGZvdW5kIGhlcmU6PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZ2l0 aHViLmNvbS9wYWxlcmlrbS9JQ01QVGVzdCIgY2xhc3M9IiI+aHR0cHM6Ly9naXRodWIuY29tL3Bh bGVyaWttL0lDTVBUZXN0PC9hPjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+SGF2ZSBjb2RlIGZvciB3aW5kb3dzIGFzIHdlbGwsIGJ1dCB0aGF0IGFkZHMgYW5vdGhlciBs YXllciBvZiBjb21wbGV4aXR5IGFuZCB3ZWlyZG5lc3MuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGUNCiBhcHAgY2FuIGdldCBhc3lu YyBlcnJvcnMgKGkuZS4sIG5vdCBpbiByZXNwb25zZSB0byBhIGdpdmVuIHNlbmRtc2c8L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyIgY2xhc3M9IiI+b3INCiByZWN2bXNnIGNhbGwpIGJ5IHVzaW5nIGEgY29ubmVj dCgpIHRvIHRoZSBzb2NrZXQgLSBpLmUuLCBjcmVhdGluZyBhPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPmhhbmRsZQ0KIGJ5IHdoaWNoIHRoZSBPUyBjYW4gc2lnbmFsIHRoZSBhcHAuPC9zcGFu PjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+U2VlDQogdGhlIGJvb2sgZXhjZXJwdCBoZXJlOjwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vYm9v a3MuZ29vZ2xlLmNvbS9ib29rcz9pZD1wdFNDNExwd0dBMEMmYW1wO3BnPVBBMjQ5JmFtcDtscGc9 UEEyNDkmYW1wO2RxPXNvY2tldCYjNDM7ZXJyb3JzJiM0MztpY21wJmFtcDtzb3VyY2U9YmwmYW1w O290cz1LczNBUGxialFzJmFtcDtzaWc9YUJ2UmVGZk9ZU2hFR3RKdHZFaGVHLThIcG5JJmFtcDto bD1lbiZhbXA7c2E9WCZhbXA7ZWk9bExwd1ZkTEhKWlNab1FTeHRZS3dDdyZhbXA7dmVkPTBDRE1R NkFFd0FnI3Y9b25lcGFnZSZhbXA7cT1zb2NrZXQgZXJyb3JzIGljbXAmYW1wO2Y9ZmFsc2UiIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly9ib29rcy5nb29n bGUuY29tL2Jvb2tzP2lkPXB0U0M0THB3R0EwQyZhbXA7cGc9UEEyNDkmYW1wO2xwZz1QQTI0OSZh bXA7ZHE9c29ja2V0JiM0MztlcnJvcnMmIzQzO2ljbXAmYW1wO3NvdXJjZT1ibCZhbXA7b3RzPUtz M0FQbGJqUXMmYW1wO3NpZz1hQnZSZUZmT1lTaEVHdEp0dkVoZUctOEhwbkkmYW1wO2hsPWVuJmFt cDtzYT1YJmFtcDtlaT1sTHB3VmRMSEpaU1pvUVN4dFlLd0N3JmFtcDt2ZWQ9MENETVE2QUV3QWcj dj1vbmVwYWdlJmFtcDtxPXNvY2tldCUyMGVycm9ycyUyMGljbXAmYW1wO2Y9ZmFsc2U8L2E+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5BRkFJQ1QsDQogdGhpcyBpcyB3aWRlbHkgc3VwcG9ydGVkLjwvc3Bhbj48YnIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PldlIGFwcGFyZW50bHkgbGl2ZSBpbiB0d28gZGlmZmVyZW50IHJlYWxpdGllcy4gRmlndXJpbmcg b3V0IGhvdyB0aGlzIHdvcmsgYW5kIGltcGxlbWVudGluZyBjcm9zcyBwbGF0Zm9ybSBhcHBsaWNh dGlvbiBjb2RlIHRoYXQgZG9lcyB0aGlzIGlzIG5vdCB0cml2aWFsLiZuYnNwOzwvZGl2Pg0KPGRp dj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhlIGFib3ZlIGJvb2sgZG9lcyBub3QgZGVz Y3JpYmUgaG93IHJlY2VudCBsaW51eCBrZXJuZWxzIGhhbmRsZXMgSUNNUC4mbmJzcDs8L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdj4uLS48L2Rpdj4NCjxkaXY+UMOlbC1FcmlrPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPi4uLjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPlNvIHRoaXMgYm9pbHMgZG93 biBiZXR0ZXIgZWR1Y2F0aW9uIG9mIHRoZSBhcHAgZGV2ZWxvcGVycz88YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpObywgaW4gdGhhdCBjYXNlIHlvdSBoYXZlIGEg YnVnLiBUaGUgb25seSB0aGluZyB0aGUgVURQIGFwcCBoYXMgdG8gd29ycnk8YnIgY2xhc3M9IiI+ DQphYm91dCBhcmUgSUNNUHMgZnJvbSBvdGhlciBhcHBzIHVzaW5nIHRoZSBzYW1lIHBvcnQuPGJy IGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KRG8geW91IGhhdmUgYW55 IHJlYWwgY29kZSB0byBzaG93IHRoYXQgdGhpcyBhY3R1YWxseSB3b3JrIGFzIGRlc2NyaWJlZCBv biBhbnkgcGxhdGZvcm0/PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+U2VlDQogYWJvdmUuPC9zcGFuPiZuYnNwOzwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPkpvZTwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9288CE6B2BEE4E11AD799C7601AFB27Bciscocom_-- From nobody Fri Jun 5 01:12:59 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DEA1B2D60 for ; Fri, 5 Jun 2015 01:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 BQUxilJ53hm3 for ; Fri, 5 Jun 2015 01:12:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710561B2D6B for ; Fri, 5 Jun 2015 01:12:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 108BDD9320; Fri, 5 Jun 2015 10:12:52 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dJCF9PJSqnHy; Fri, 5 Jun 2015 10:12:51 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id D57D1D9314; Fri, 5 Jun 2015 10:12:51 +0200 (MEST) Message-ID: <55715A02.4020203@tik.ee.ethz.ch> Date: Fri, 05 Jun 2015 10:12:50 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl , "taps@ietf.org" , Joe Touch References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> In-Reply-To: <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 08:12:58 -0000 Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). Mirja On 01.06.2015 21:12, Michael Welzl wrote: > About one bit in particular: > > >> That’s to bad. Maybe we should state this more explicitly in the intro…? According to our charter, while taps itself is chartered to describe "an (abstract) interface for applications >> to make use of Transport Services“, this first document is only used to "identifying the >> [components] provided by existing IETF protocols“ as a starting point. Further we would like to add some discussion in section 4 which of the identified components should/can be exposed as a transport feature that the app should see. [Note that the terminology changed and whenever services is written in the charter it should basically be component.] > > This confuses me. > > draft-ietf-taps-transports-04 defines a "Transport Protocol Component" as "an implementation of a transport service feature within a protocol." > I'm fine with that definition but I can't see why this should replace "service" in the charter. The first document should list the services provided by existing IETF protocols, that's how to get started. Additionally listing components is probably fine if that helps explaining how services are constructed, but the focus is on what transports provide - services. > > Cheers, > Michael > From nobody Fri Jun 5 02:06:29 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795AB1A90A8 for ; Fri, 5 Jun 2015 02:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBZ4Z4KFDLyB for ; Fri, 5 Jun 2015 02:06:23 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E451A90FE for ; Fri, 5 Jun 2015 02:05:07 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0nYn-0001wj-80; Fri, 05 Jun 2015 11:05:05 +0200 Received: from 1x-193-157-212-189.uio.no ([193.157.212.189]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0nYm-0005mI-Cs; Fri, 05 Jun 2015 11:05:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <55715A02.4020203@tik.ee.ethz.ch> Date: Fri, 5 Jun 2015 11:05:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 12 sum msgs/h 5 total rcpts 29838 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C3A097436DD5AD261B6C24363B9CE477BC264819 X-UiO-SPAM-Test: remote_host: 193.157.212.189 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Joe Touch , "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 09:06:25 -0000 > On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >=20 > Okay, just to quickly clarify. In the charter only the word service is = used. We defined later on the words component and feature which are = currently not reflected in the charter. The part I've cited below, I = think, it should say components. However, it does not really matter = because we will in the current document first identify components and = then discuss features. In any case this document will not define a new = interface. I got that but I disagree about "it should say components" for the part = in the charter: from the definition, the component is an implementation, = not what is exposed to the application. I think the more important part = is to capture what's exposed to the application. For example: SCTP has a = component called "strong error detection (CRC32C)". TCP has a component = called "error detection (checksum)". This is probably not exposed to the = application as such by any of these protocols. I'll explain below why = this makes it less important in my opinion... > I'd also say that this is not the flag ship document (as stated by = Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). Well, this first document is no less important, everything hinges on it. So let's think of the future system we're envisioning here. Is it going = to provide "error detection" as a service? Is it going to provide = "strong error detection"? When making these decisions, I think we'd first need to go through the = list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? These are important decisions but I think they are secondary, whereas = what the protocols now explicitly offer is primary - because it would be = very strange not to offer what is being offered today. We can decide to = not expose "level of error protection" and give the TAPS more freedom in = choosing the protocol; given that the goal is to stop connection = applications to specific protocols, we CAN do that. That's why I think the service is more important than the component, and = that's why I'm on Joe's side here. Cheers, Michael From nobody Fri Jun 5 02:19:32 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF8C1AC3DF for ; Fri, 5 Jun 2015 02:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MMgeclIo01A for ; Fri, 5 Jun 2015 02:19:30 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3E51A92F1 for ; Fri, 5 Jun 2015 02:19:29 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0nmh-00050l-Ni; Fri, 05 Jun 2015 11:19:27 +0200 Received: from 1x-193-157-212-189.uio.no ([193.157.212.189]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1Z0nmg-0008QM-Ta; Fri, 05 Jun 2015 11:19:27 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Fri, 5 Jun 2015 11:19:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 16 sum msgs/h 7 total rcpts 29842 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4DF473EF1D4B48AEBB971E6BEB70DEDC0402EFA7 X-UiO-SPAM-Test: remote_host: 193.157.212.189 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 9 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 09:19:31 -0000 Sorry for sending an extra email - I just had an extra thought and think = this is important to add: Below: > On 5. jun. 2015, at 11.05, Michael Welzl wrote: >=20 >=20 >> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>=20 >> Okay, just to quickly clarify. In the charter only the word service = is used. We defined later on the words component and feature which are = currently not reflected in the charter. The part I've cited below, I = think, it should say components. However, it does not really matter = because we will in the current document first identify components and = then discuss features. In any case this document will not define a new = interface. >=20 > I got that but I disagree about "it should say components" for the = part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >=20 >=20 >> I'd also say that this is not the flag ship document (as stated by = Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >=20 > Well, this first document is no less important, everything hinges on = it. >=20 > So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >=20 > When making these decisions, I think we'd first need to go through the = list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? >=20 > These are important decisions but I think they are secondary, whereas = what the protocols now explicitly offer is primary - because it would be = very strange not to offer what is being offered today. We can decide to = not expose "level of error protection" and give the TAPS more freedom in = choosing the protocol; given that the goal is to stop connection = applications to specific protocols, we CAN do that. as Brian pointed out in a previous email, a protocol comes with a series = of what he called "positive properties" and "negative properties". = Anyway, properties: your application may like some and hate some. It's = always a suite of properties - then, we probably can't expose them = individually - e.g. with today's protocols, you can't get MPTCP's usage = of multiple paths with coupled congestion control but at the same time = have SCTP's strong CRC. Sure, we can say the same about combinations of things that are = currently being offered in the abstract APIs of the protocols, but = still, things will get easier there: the list is shorter, it's clearer = what we need to include and what not (basically everything must be = included), and certain API elements will clearly dictate which = protocol(s) to use. Therefore I do believe that the job gets much easier = if we focus on the abstract APIs first. I'm not against listing the = components, it's about what matters more (and it should be reflected in = the document accordingly - maybe it could even be an idea to split the = document in two, one purely about the "abstract API" and one about = "components", and possibly merge them later?). Cheers, Michael From nobody Fri Jun 5 03:35:49 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9C71A0035 for ; Fri, 5 Jun 2015 03:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 cJrpYMChBsBA for ; Fri, 5 Jun 2015 03:35:45 -0700 (PDT) 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 18BE11A0004 for ; Fri, 5 Jun 2015 03:35:44 -0700 (PDT) Received: from [192.168.1.200] (p54819223.dip0.t-ipconnect.de [84.129.146.35]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 749D61CC4BFF7; Fri, 5 Jun 2015 12:35:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Tuexen In-Reply-To: Date: Fri, 5 Jun 2015 12:35:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B85C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 10:35:47 -0000 > On 05 Jun 2015, at 11:05, Michael Welzl wrote: >=20 >=20 >> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>=20 >> Okay, just to quickly clarify. In the charter only the word service = is used. We defined later on the words component and feature which are = currently not reflected in the charter. The part I've cited below, I = think, it should say components. However, it does not really matter = because we will in the current document first identify components and = then discuss features. In any case this document will not define a new = interface. >=20 > I got that but I disagree about "it should say components" for the = part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >=20 >=20 >> I'd also say that this is not the flag ship document (as stated by = Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >=20 > Well, this first document is no less important, everything hinges on = it. >=20 > So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >=20 > When making these decisions, I think we'd first need to go through the = list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? >=20 > These are important decisions but I think they are secondary, whereas = what the protocols now explicitly offer is primary - because it would be = very strange not to offer what is being offered today. We can decide to = not expose "level of error protection" and give the TAPS more freedom in = choosing the protocol; given that the goal is to stop connection = applications to specific protocols, we CAN do that. I consider "protecting against bit errors" a service. And I think the = level is important. I agree, TCP and SCTP provide a protocol dependent level of protection, so there is no need to expose = this in the API of the particular protocol, however, I do think someone wants a strong checksum or not, and that = will influence the choice of protocols. So we do have services which are not configurable via the API. Best regards Michael >=20 > That's why I think the service is more important than the component, = and that's why I'm on Joe's side here. >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 5 04:29:26 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328311B2EDE for ; Fri, 5 Jun 2015 04:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAv_M2YA0PWr for ; Fri, 5 Jun 2015 04:29:22 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C52A1B2EDD for ; Fri, 5 Jun 2015 04:29:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0D939D9320; Fri, 5 Jun 2015 13:29:21 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DHwbxZgHiVU8; Fri, 5 Jun 2015 13:29:20 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id CE4E0D931C; Fri, 5 Jun 2015 13:29:20 +0200 (MEST) Message-ID: <5571880F.70700@tik.ee.ethz.ch> Date: Fri, 05 Jun 2015 13:29:19 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl , "taps@ietf.org" , Joe Touch References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 11:29:25 -0000 Hi Michael, see below. On 05.06.2015 11:05, Michael Welzl wrote: > >> On 5. jun. 2015, at 10.12, Mirja Kühlewind wrote: >> >> Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. > > I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... I don't think that this decision is (in general) that easy. That's why we go through the exercise of decomposing existing protocols into their components and based on this information discuss what potentially could be exposed and further reason about what should be exposed (because there are implications for the application). From my point of view this process it independent of the interface (not matter if we talk about an abstract interface, a certain implementation or what we want to have in future). However, looking at current interfaces will probably help us to make the right decisions. > > >> I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). > > Well, this first document is no less important, everything hinges on it. > > So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? > > When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? > > These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. > > That's why I think the service is more important than the component, and that's why I'm on Joe's side here. I didn't say anything about the importance of anything. I think all three documents and and all kind of transport 'things' we talk about are important. And most important is the process of getting things 'decomposed' correctly and discussed in the right document at the right time. What I wanted to say is that people who later on read these docs (because they want to use taps), probably only read the third doc, maybe the second, and very likely will only read this document if they already have read the other two and would like have additional information. I do have the feeling that parts of what Joe wants to discuss should however be in the third doc. And therefore I think that the current first doc is not the taps flagship doc because for me a flagship doc (and we probably need to define this term ;-) ) is the doc that you point people to as the first thing to read after the work was finished...? All in all, I actually think that we are on the same side here (and right at this point we don't need too much further discussion). Brian and I are in the process of marking a better distinction on components and feature than what is given in the lists in the current version. I believe the current, very sloppy handing of these lists is where most on the confusion (and potentially disagreement) comes from and I hope that discussion can be more focused soon as we have submitted the next revision. Mirja > > Cheers, > Michael > -- ------------------------------------------ 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 Fri Jun 5 05:11:50 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CF41A0377 for ; Fri, 5 Jun 2015 05:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 wj8AXuQyt3Ht for ; Fri, 5 Jun 2015 05:11:46 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 ABF911A036E for ; Fri, 5 Jun 2015 05:11:45 -0700 (PDT) Received: from i72xhb.tm.uni-karlsruhe.de ([141.3.71.35]) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587 iface 141.3.10.81 id 1Z0qTD-0006MA-MB; Fri, 05 Jun 2015 14:11:31 +0200 Message-ID: <557191EF.8050404@kit.edu> Date: Fri, 05 Jun 2015 14:11:27 +0200 From: Helge Backhaus User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: taps@ietf.org, Joe Touch References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch>, <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <5570C125.1000903@isi.edu> In-Reply-To: <5570C125.1000903@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1433506291. Archived-At: Cc: Christian Huitema , Marie-Jose Montpetit , mirja.kuehlewind@tik.ee.ethz.ch Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 12:11:49 -0000 Am 04.06.2015 um 23:20 schrieb Joe Touch: > > > On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote: >> In my presentation in Dallas I had suggested adding RTP (and even HTTP) >> because as both Mirja and Christian mention some 'applications' are >> requesting functionalities that are got given elsewhere. > > The core of this issue is "what is a transport protocol". > > To the user, "transport" is the entire stack between their program and the > network (IP) layer - sometimes even including that (e.g., IPsec). > > To typical transport protocols (e.g., UDP, TCP), everything that accesses a > transport protocol is the "application" layer. > >> From the document: > Transport Service: a set of transport service features, without an > association to any given framing protocol, which provides a complete service > to an application. > > Transport Protocol: an implementation that provides one or more different > transport services using a specific framing and header format on the wire. > > By those definitions, EVERYTHING between the user program and the link layer > is arguably part of the services an app sees, which include "shim" services > and layers such as: IPsec, TLS, and RTP. > > I would argue that HTTP is the application that uses TCP (or TLS/TCP), but > not a separate service, but that's true only for conventional web service. > > There are many services built on top of HTTP, at which point HTTP is just > another part of what this document calls a "transport service". > > As a result, unless you'll be describing every possible stack between the > user program and the link layer, Shouldn't this ideally be the (long-term) goal of TAPS? Of course it will never be feasible to consider every conceivable existing or future stack in practice. Thankfully, since it has been stated multiple times that TAPS is not intended to replace everything that exists out there, it's maybe good enough to have a look at some stacks...? > this document cannot proceed with the current definitions. So could a possible way forward be to leave the definitions as they are and add a description of the considered stack(s) to the document? For now "just" TCP, UDP, SCTP, ... over IPv4/6 etc. At a later point that could be updated to services provided by the same stack with RTP and the likes on top and a third with HTTP over TCP(/TLS) ... the goal being to at least cover the "popular" stack (combinations) at some point. Wouldn't that help to simplify the discussion which protocols are in and out of scope as service providers at a given point in time a lot? > Joe Apologies for just barging in like that. Im a long-time TAPS lurker so to speak and genuinely interested in opinions regarding such an approach. Helge -- Karlsruhe Institute of Technology (KIT) Institut für Telematik Dipl.-Inform. Helge Backhaus research assistant Zirkel 2 Building 20.20 Room 352 D-76128 Karlsruhe phone: +49 721 608 46402 backhaus@kit.edu www.tm.kit.edu KIT – Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft From nobody Fri Jun 5 06:34:58 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21C61B2F7E for ; Fri, 5 Jun 2015 06:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPDnev4rD01f for ; Fri, 5 Jun 2015 06:34:54 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E89F1B2F7F for ; Fri, 5 Jun 2015 06:34:54 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0rls-0006Mb-1W; Fri, 05 Jun 2015 15:34:52 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0rlr-0003lW-Cf; Fri, 05 Jun 2015 15:34:51 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <5571880F.70700@tik.ee.ethz.ch> Date: Fri, 5 Jun 2015 15:34:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <557 1880F.70700@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 29847 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FD71A210408C394950C1670749E226125D183320 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7231 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Joe Touch , "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 13:34:57 -0000 > On 05 Jun 2015, at 13:29, Mirja K=C3=BChlewind = wrote: >=20 > Hi Michael, >=20 > see below. >=20 >=20 > On 05.06.2015 11:05, Michael Welzl wrote: >>=20 >>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>=20 >>> Okay, just to quickly clarify. In the charter only the word service = is used. We defined later on the words component and feature which are = currently not reflected in the charter. The part I've cited below, I = think, it should say components. However, it does not really matter = because we will in the current document first identify components and = then discuss features. In any case this document will not define a new = interface. >>=20 >> I got that but I disagree about "it should say components" for the = part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >=20 > I don't think that this decision is (in general) that easy. That's why = we go through the exercise of decomposing existing protocols into their = components and based on this information discuss what potentially could = be exposed and further reason about what should be exposed (because = there are implications for the application). >=20 > =46rom my point of view this process it independent of the interface = (not matter if we talk about an abstract interface, a certain = implementation or what we want to have in future). However, looking at = current interfaces will probably help us to make the right decisions. >=20 >>=20 >>=20 >>> I'd also say that this is not the flag ship document (as stated by = Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >>=20 >> Well, this first document is no less important, everything hinges on = it. >>=20 >> So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >>=20 >> When making these decisions, I think we'd first need to go through = the list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? >>=20 >> These are important decisions but I think they are secondary, whereas = what the protocols now explicitly offer is primary - because it would be = very strange not to offer what is being offered today. We can decide to = not expose "level of error protection" and give the TAPS more freedom in = choosing the protocol; given that the goal is to stop connection = applications to specific protocols, we CAN do that. >>=20 >> That's why I think the service is more important than the component, = and that's why I'm on Joe's side here. >=20 > I didn't say anything about the importance of anything. I think all = three documents and and all kind of transport 'things' we talk about are = important. And most important is the process of getting things = 'decomposed' correctly and discussed in the right document at the right = time. >=20 > What I wanted to say is that people who later on read these docs = (because they want to use taps), probably only read the third doc, maybe = the second, and very likely will only read this document if they already = have read the other two and would like have additional information. >=20 > I do have the feeling that parts of what Joe wants to discuss should = however be in the third doc. And therefore I think that the current = first doc is not the taps flagship doc because for me a flagship doc = (and we probably need to define this term ;-) ) is the doc that you = point people to as the first thing to read after the work was = finished...? >=20 > All in all, I actually think that we are on the same side here (and = right at this point we don't need too much further discussion). Brian = and I are in the process of marking a better distinction on components = and feature than what is given in the lists in the current version. I = believe the current, very sloppy handing of these lists is where most on = the confusion (and potentially disagreement) comes from and I hope that = discussion can be more focused soon as we have submitted the next = revision. Cool, thanks for the work you folks put into this! And have a nice = weekend, Michael From nobody Fri Jun 5 06:39:46 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBCF1B2F92 for ; Fri, 5 Jun 2015 06:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8VI0FAkXmUc for ; Fri, 5 Jun 2015 06:39:43 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C815A1B2F97 for ; Fri, 5 Jun 2015 06:39:42 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0rqW-00079O-1J; Fri, 05 Jun 2015 15:39:40 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0rqV-00030v-Do; Fri, 05 Jun 2015 15:39:39 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <5B85C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> Date: Fri, 5 Jun 2015 15:39:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 11 sum msgs/h 4 total rcpts 29851 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F0CBC04691D96055EF4AC86931F995F310FA2109 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 7232 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 13:39:45 -0000 > On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >=20 >> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >>=20 >>=20 >>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>=20 >>> Okay, just to quickly clarify. In the charter only the word service = is used. We defined later on the words component and feature which are = currently not reflected in the charter. The part I've cited below, I = think, it should say components. However, it does not really matter = because we will in the current document first identify components and = then discuss features. In any case this document will not define a new = interface. >>=20 >> I got that but I disagree about "it should say components" for the = part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>=20 >>=20 >>> I'd also say that this is not the flag ship document (as stated by = Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >>=20 >> Well, this first document is no less important, everything hinges on = it. >>=20 >> So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >>=20 >> When making these decisions, I think we'd first need to go through = the list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? >>=20 >> These are important decisions but I think they are secondary, whereas = what the protocols now explicitly offer is primary - because it would be = very strange not to offer what is being offered today. We can decide to = not expose "level of error protection" and give the TAPS more freedom in = choosing the protocol; given that the goal is to stop connection = applications to specific protocols, we CAN do that. > I consider "protecting against bit errors" a service. And I think the = level is important. I agree, TCP and SCTP provide > a protocol dependent level of protection, so there is no need to = expose this in the API of the particular protocol, > however, I do think someone wants a strong checksum or not, and that = will influence the choice of protocols. > So we do have services which are not configurable via the API. Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. Cheers, Michael From nobody Fri Jun 5 06:52:30 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320381B2FAF for ; Fri, 5 Jun 2015 06:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 Fmj56rTyu8mO for ; Fri, 5 Jun 2015 06:52:27 -0700 (PDT) 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 DCA6F1B2FAD for ; Fri, 5 Jun 2015 06:52:26 -0700 (PDT) Received: from [192.168.1.200] (p54819223.dip0.t-ipconnect.de [84.129.146.35]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 15AE11C021BE2; Fri, 5 Jun 2015 15:52:24 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Tuexen In-Reply-To: Date: Fri, 5 Jun 2015 15:52:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 13:52:29 -0000 > On 05 Jun 2015, at 15:39, Michael Welzl wrote: >=20 >=20 >> On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >>=20 >>> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >>>=20 >>>=20 >>>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>>=20 >>>> Okay, just to quickly clarify. In the charter only the word service = is used. We defined later on the words component and feature which are = currently not reflected in the charter. The part I've cited below, I = think, it should say components. However, it does not really matter = because we will in the current document first identify components and = then discuss features. In any case this document will not define a new = interface. >>>=20 >>> I got that but I disagree about "it should say components" for the = part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>>=20 >>>=20 >>>> I'd also say that this is not the flag ship document (as stated by = Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >>>=20 >>> Well, this first document is no less important, everything hinges on = it. >>>=20 >>> So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >>>=20 >>> When making these decisions, I think we'd first need to go through = the list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? >>>=20 >>> These are important decisions but I think they are secondary, = whereas what the protocols now explicitly offer is primary - because it = would be very strange not to offer what is being offered today. We can = decide to not expose "level of error protection" and give the TAPS more = freedom in choosing the protocol; given that the goal is to stop = connection applications to specific protocols, we CAN do that. >> I consider "protecting against bit errors" a service. And I think the = level is important. I agree, TCP and SCTP provide >> a protocol dependent level of protection, so there is no need to = expose this in the API of the particular protocol, >> however, I do think someone wants a strong checksum or not, and that = will influence the choice of protocols. >> So we do have services which are not configurable via the API. >=20 > Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. Such as "reliable" for TCP? Or "byte stream" for TCP? These properties = come with choosing TCP... Best regards Michael >=20 > Cheers, > Michael >=20 >=20 From nobody Fri Jun 5 07:04:50 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFF71B2FEC for ; Fri, 5 Jun 2015 07:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcGTuooWHYdN for ; Fri, 5 Jun 2015 07:04:45 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFBB1B2FF0 for ; Fri, 5 Jun 2015 07:03:48 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0sDq-0006V4-AF; Fri, 05 Jun 2015 16:03:46 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0sDp-0007W3-Kx; Fri, 05 Jun 2015 16:03:46 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: Date: Fri, 5 Jun 2015 16:03:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> To: Michael Tuexen X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 13 sum msgs/h 3 total rcpts 29862 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F181A89E86B817AB5BC363D7456DEA17427544DE X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7236 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 14:04:48 -0000 > On 05 Jun 2015, at 15:52, Michael Tuexen = wrote: >=20 >> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >>=20 >>=20 >>> On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >>>=20 >>>> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >>>>=20 >>>>=20 >>>>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>>>=20 >>>>> Okay, just to quickly clarify. In the charter only the word = service is used. We defined later on the words component and feature = which are currently not reflected in the charter. The part I've cited = below, I think, it should say components. However, it does not really = matter because we will in the current document first identify components = and then discuss features. In any case this document will not define a = new interface. >>>>=20 >>>> I got that but I disagree about "it should say components" for the = part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>>>=20 >>>>=20 >>>>> I'd also say that this is not the flag ship document (as stated by = Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >>>>=20 >>>> Well, this first document is no less important, everything hinges = on it. >>>>=20 >>>> So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >>>>=20 >>>> When making these decisions, I think we'd first need to go through = the list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? >>>>=20 >>>> These are important decisions but I think they are secondary, = whereas what the protocols now explicitly offer is primary - because it = would be very strange not to offer what is being offered today. We can = decide to not expose "level of error protection" and give the TAPS more = freedom in choosing the protocol; given that the goal is to stop = connection applications to specific protocols, we CAN do that. >>> I consider "protecting against bit errors" a service. And I think = the level is important. I agree, TCP and SCTP provide >>> a protocol dependent level of protection, so there is no need to = expose this in the API of the particular protocol, >>> however, I do think someone wants a strong checksum or not, and that = will influence the choice of protocols. >>> So we do have services which are not configurable via the API. >>=20 >> Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. > Such as "reliable" for TCP? Or "byte stream" for TCP? These properties = come with choosing TCP... Exactly. I meant "important" as "to be discussed first" (hm, maybe simply "listed = first in the doc"). I think it would make things easier and clearer to = first discuss the things that are exposed by the abstract APIs today. SCTP will help, then: it exposes "reliable". So if we'd go with that, = the first item in your list above for TCP would already disappear from = the discussion: it will eventually need to be exposed by a TAPS system = because of SCTP anyway, and thus belongs in the list. So if the document would, for instance, first list all the things that = the protocol's abstract API now expose, and then follow with static = properties that protocols have (and that a certain combination of chosen = services would entail), then that list of static properties gets shorter = - e.g., for TCP, from the two items above, only "byte stream" would be = left. My aim here is to try to simplify things so that we can gradually make = progress rather than beginning by discussing a long list where it's very = hard to argue for why one particular bit should be in the list or not. = If folks things I'm not making it easier but harder, please ignore me = :-) I'm only trying to help... Cheers, Michael From nobody Fri Jun 5 09:42:41 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798271A1BB1 for ; Fri, 5 Jun 2015 09:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7ICOqbUAwIY for ; Fri, 5 Jun 2015 09:42:38 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94BC1A1B44 for ; Fri, 5 Jun 2015 09:42:38 -0700 (PDT) Received: from [192.168.1.6] (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 t55Gg8MW013521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2015 09:42:17 -0700 (PDT) Message-ID: <5571D15E.3020002@isi.edu> Date: Fri, 05 Jun 2015 09:42:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <00597CB8-D128-408A-8F35-BA98CDF45A62@cisco.com> <55707211.8010609@isi.edu> <26B9DE0B-4D38-430D-A9A1-921CD0067C70@cisco.com> <5570988A.6040208@isi.edu> <554F884C-642C-42B1-A976-EECD0C32928B@cisco.com> <5570A452.8090209@isi.edu> <43C5480A-904D-4A7E-A181-08EBA709BC2A@cisco.com> <5570BB6C.2070905@isi.edu> <9288CE6B-2BEE-4E11-AD79-9C7601AFB27B@cisco.com> In-Reply-To: <9288CE6B-2BEE-4E11-AD79-9C7601AFB27B@cisco.com> 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: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS Transports and ICMP 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 Jun 2015 16:42:41 -0000 On 6/5/2015 12:25 AM, Pal Martinsen (palmarti) wrote: > >> On 04 Jun 2015, at 22:56, Joe Touch > > wrote: >> >> >> >> On 6/4/2015 12:51 PM, Pal Martinsen (palmarti) wrote: >>> >>>> On 04 Jun 2015, at 21:17, Joe Touch >>> > wrote: >>>> >>>> >>>> >>>> On 6/4/2015 12:08 PM, Pal Martinsen (palmarti) wrote: >>>> ... >>>>>> UDP passes all ICMP messages to the app. If the app doesn't listen for >>>>>> it, that’s the app's decision. >>>>>> >>>>> Then there is a lot UDP application developers out there that does >>>>> not care. >>>>> >>>>> Ill guess what I am asking if we should make life easier for them. >>>> >>>> Again, FIRST this doc needs to explain the current abstract APIs for >>>> transport protocols. >>>> >>>> THEN we can decide whether that set either needs to be augmented, >>>> diminished, or translated to be more useful for “applications". >>> >>> Heh.. I still do not get that.. >>> >>>> From the Abstract: >>> This document describes services provided by existing IETF protocols >>> and congestion control mechanisms. >> >> *existing* >> >> That means we need to document WHAT IS before deciding to pursue WHAT >> SHOULD BE. >> > ICMP is an *existing* protocol. Not a transport protocol, but a > service(?) that affects how the other protocols behaves. And it is part of the service provided by a transport - i.e., when an ICMP message is absorbed and acted on by TCP, it's a service *to* TCP, but when TCP relays ICMP messages to the application they become part of the TCP API. > All I am observing is that this is something app developers rarely cares > about, and having sections in the TAPS transports draft describing it > might help. Why are there sections describing TCP, they could just read > RFC 793? More like RFC1122, which already does for TCP and UDP basically what this doc is attempting to do. >>> It is designed to help >>> application and network stack programmers and to inform the work of >>> the IETF TAPS Working Group. >>> >>> >>> Having a description of how ICMP works. Both in theory (abstract >>> APIs) and in practice would help app developers. >> >> In theory, it behaves like RFC 792 and RFC 1122 specify. >> >> In practice, we can measure whether those capabilities are supported or >> not (but that's not particularly the scope of TAPS). >> >> However, that does not necessarily require documenting the Java >> interface to TCP on Linux CentOS v7. That what man pages are for. >> > > No, but pointing out that there are differences out there and app > developers should take care and investigate is a useful hint. One line: Implementations vary. What else is there to say? And do we really need to say that? >>>>>>> Unfortunately how to do this varies from OS to OS: >>>>>>> See https://tools.ietf.org/html/draft-martinsen-tram-stuntrace-01#appendix-A.2 for >>>>>>> examples. >>>>>> >>>>>> You are confusing the OS and language-dependent implementation of the >>>>>> API with the abstract API. >>>>>> >>>>> On purpose. I hate it when a feature should work because it says so >>>>> in a RFC, but the implementations of it is so vastly different that >>>>> it is not possible to get the thing to work so the app developer just >>>>> chose to ignore it. >>>> >>>> The IETF standardizes protocols and abstract APIs. >>>> >>>> If you are concerned with differences in the implementations of those >>>> abstract APIs, you need to address them in other organizations (e.g., >>>> POSIX, etc.). >>>> >>> >>> That seems like a fun task.. (So who is on the list: Apple, >>> Microsoft, Google(android), Linux, BSD…) >> >> POSIX is maintained by the IEEE, and defines the common API across >> various OS implementations - and yes, some of those orgs participate. >> >> That’s far outside the scope of the IETF, though. > > > That I agree on. The discussion is probably better had over a beer. I do > feel that it is important that IETF do take into account what is > actually used in the wild. That would require a survey, not merely anecdotal evidence. >>>> ... >>>>>> RFC1122 requires that UDP implementations make the ICMP signals >>>>>> available to the application. It does not indicate by what mechanism. >>>>>> >>>>>>> Listening for port unreachable can be nice to avoid spamming a >>>>>>> host or >>>>>>> application that recently crashed. Detecting fragmentation or max >>>>>>> MTU is >>>>>>> also a nice feature especially VoIP applications sending video can >>>>>>> utilise to optimise their packet sizes. >>>>>> >>>>>> UDP is required to pass ALL ICMP messages to the app layer, as per >>>>>> RFC 1122. >>>>> >>>>> That is another problem. An app using port 5555 will receive all >>>>> ICMP messages also generated by other apps running on other ports. >>>> >>>> That's an incorrect implementation. See RFC1122 Section 4.1.3.3. >>>> >>> The section says: >>> UDP MUST pass to the application layer all ICMP error >>> messages that it receives from the IP layer. Conceptually >>> at least, this may be accomplished with an upcall to the >>> ERROR_REPORT routine (see >>> Section 4.2.4.1). >>> >>> Looks like none the implementers do send any ICMP messages to the >>> UDP layer. >> >> Here's an example of how an app can get errors in response to a call: >> http://stackoverflow.com/questions/4888285/send-an-udp-packet-and-receive-an-icmp-response-from-router-in-c >> > Yes, I cited code example earlier. > > The above code does not fly so well unless you have administrative > privileges. That's an OS implementation issue. There's no such notion in our protocols, except for the concept of system vs. user ports, and even that is now somewhat deprecated as a distinction exactly because it isn't uniformly enforced. > I did a series of tests a while back. Code that works on OS-X, Linux and > IOS can be found here: > https://github.com/palerikm/ICMPTest > > Have code for windows as well, but that adds another layer of complexity > and weirdness. But that is a complaint against the implementation and/or user libraries. >> The app can get async errors (i.e., not in response to a given sendmsg >> or recvmsg call) by using a connect() to the socket - i.e., creating a >> handle by which the OS can signal the app. >> >> See the book excerpt here: >> https://books.google.com/books?id=ptSC4LpwGA0C&pg=PA249&lpg=PA249&dq=socket+errors+icmp&source=bl&ots=Ks3APlbjQs&sig=aBvReFfOYShEGtJtvEheG-8HpnI&hl=en&sa=X&ei=lLpwVdLHJZSZoQSxtYKwCw&ved=0CDMQ6AEwAg#v=onepage&q=socket%20errors%20icmp&f=false >> > errors icmp&f=false> >> >> AFAICT, this is widely supported. >> > We apparently live in two different realities. Figuring out how this > work and implementing cross platform application code that does this is > not trivial. Again, that's an issue for organizations like the IEEE and POSIX. > The above book does not describe how recent linux kernels handles ICMP. There are Linux books and manual pages for this. None of these are relevant to the IETF. Joe From nobody Fri Jun 5 09:45:45 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579671A1A06 for ; Fri, 5 Jun 2015 09:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VInJ-A-zGE7 for ; Fri, 5 Jun 2015 09:45:42 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82AB1A0169 for ; Fri, 5 Jun 2015 09:45:42 -0700 (PDT) Received: from [192.168.1.6] (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 t55GjFFH014313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2015 09:45:25 -0700 (PDT) Message-ID: <5571D21A.3090109@isi.edu> Date: Fri, 05 Jun 2015 09:45:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , Michael Welzl , "taps@ietf.org" References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5571880F.70700@tik.ee.ethz.ch> In-Reply-To: <5571880F.70700@tik.ee.ethz.ch> 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: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 16:45:43 -0000 On 6/5/2015 4:29 AM, Mirja Kühlewind wrote: > I do have the feeling that parts of what Joe wants to discuss should > however be in the third doc. And therefore I think that the current > first doc is not the taps flagship doc because for me a flagship doc > (and we probably need to define this term ;-) ) is the doc that you > point people to as the first thing to read after the work was finished...? Perhaps "flagship" isn't a useful word for either doc. IMO, this is a "foundation" doc, and as such needs to set the groundwork for other docs. As to what doc we'll point people at when this is done, that could be a BCP, it could be a new protocol (experimental, presumably), etc. But we're nowhere near understanding what that last doc will be if we can't agree on what a protocol or API is. Joe From nobody Fri Jun 5 09:51:04 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231D81A879F for ; Fri, 5 Jun 2015 09:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeAr7zy4h5k7 for ; Fri, 5 Jun 2015 09:51:02 -0700 (PDT) Received: from webspace.isi.edu (webspace.isi.edu [128.9.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 274331A8714 for ; Fri, 5 Jun 2015 09:51:02 -0700 (PDT) Received: from [192.168.1.6] (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 t55GnbLH015417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2015 09:49:47 -0700 (PDT) Message-ID: <5571D320.8060303@isi.edu> Date: Fri, 05 Jun 2015 09:49:36 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Helge Backhaus , taps@ietf.org References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch>, <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <5570C125.1000903@isi.edu> <557191EF.8050404@kit.edu> In-Reply-To: <557191EF.8050404@kit.edu> 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: Cc: Christian Huitema , Marie-Jose Montpetit , mirja.kuehlewind@tik.ee.ethz.ch Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 16:51:03 -0000 On 6/5/2015 5:11 AM, Helge Backhaus wrote: > Am 04.06.2015 um 23:20 schrieb Joe Touch: ... >> There are many services built on top of HTTP, at which point HTTP is just >> another part of what this document calls a "transport service". >> >> As a result, unless you'll be describing every possible stack between the >> user program and the link layer, > > Shouldn't this ideally be the (long-term) goal of TAPS? This would require an exponential number of service descriptions. IMO, it's better to describe them as a linear number of composable components and declare the composition rules. (that's not novel; that's what we do throughout the IETF) >> this document cannot proceed with the current definitions. > > So could a possible way forward be to leave the definitions as they are > and add a description of the considered stack(s) to the document? For > now "just" TCP, UDP, SCTP, ... over IPv4/6 etc. If you ignore the deficiency of the definitions, then it's impossible to move together on the remainder of the doc. Joe From nobody Fri Jun 5 10:33:40 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB4F1A92AC for ; Fri, 5 Jun 2015 10:33:39 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 1qo7yp_1tb-z for ; Fri, 5 Jun 2015 10:33:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0146.outbound.protection.outlook.com [207.46.100.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9DE1A92FE for ; Fri, 5 Jun 2015 10:31:05 -0700 (PDT) Received: from DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) by DM2PR0301MB0701.namprd03.prod.outlook.com (10.160.96.27) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 5 Jun 2015 17:31:05 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.184.17; Fri, 5 Jun 2015 17:31:04 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0172.012; Fri, 5 Jun 2015 17:31:04 +0000 From: Christian Huitema To: Michael Welzl , Michael Tuexen Thread-Topic: [Taps] I-D Action: draft-ietf-taps-transports-04.txt Thread-Index: AQHQl7FP9GBp176lGUaQe71Fj5gGO52OP4SAgACZ2gCAAPIVgIAAR+2AgAEDuQCAAJLJAIAACGwAgAADsACAABUJgIAA0fmAgAAGSwCAABGqgIAAhpWAgAE8R4CAAzd8gIAANfmAgAAC6wCAABysgIAACZiAgAWQ/ACAAA6TAIAAGVaAgAAzZQCAAD38cA== Date: Fri, 5 Jun 2015 17:31:04 +0000 Message-ID: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ifi.uio.no; dkim=none (message not signed) header.d=none; x-originating-ip: [131.107.159.254] x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 3://B2K43OacosdEvrRMpvpORKgTVeVj22MtzC29qDJJcYYvfN9WDtdTkFf9FT7iUdy7ecH592Q1o2vjgi7Marq0a+WVsM0hstE1zogWznEvjy/0ACFsuPihHHiEwIcLSCQrEJOMf5eaXCeDWb6dNtwA==; 10:90YPWWSg5Q739KfhU5U/osTZslvMLApmmFC+49f9t6FtMms5VHd/7eCevKy2jDfJ04hMjgnTSlnIXaBk3WbXzYE/6pS/kiWaY5gaMArBJP8=; 6:C9Fem7QAdTwFJzqZi+okkipyD+YGInPYsketUU+FyKsn2EwYOlCVOqajeTzfg/+z x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0701; x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520003)(5005006)(3002001); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(377454003)(76576001)(106116001)(92566002)(50986999)(99286002)(86612001)(46102003)(5001770100001)(2656002)(102836002)(66066001)(54356999)(2950100001)(87936001)(5001960100002)(5001920100001)(33656002)(74316001)(122556002)(93886004)(77096005)(76176999)(5002640100001)(77156002)(62966003)(230783001)(40100003)(189998001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2015 17:31:04.1584 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0701; 2:MWidtQOSYQ3v9ezAQC82M7mINBRV6RcZkdv08alVZCCk/ICUCBp2yJbPtkMDpFFe; 2:WYBEc81Q32Tx1mEGJ6+7a5m5PaLLIVLYCKtVJYiOmCNE0SASUFWHIOKaBR2QGpuJnkOn5OfXx5u5UBrZXS8NhvrsfoVZdgtNC9FaAsJO7MA6uHK88ZGc/9YBErxIHflPzXvDR+U3S2vQDHr8g5YSRA==; 9:18xuifjj4pCCi7YGe4+v31TpaRrRHEZAei9ZHdaLCrhb+oAM6cHjocwC+nB0y2coIxCjZQ6C6fb9LdmtjykPhi30w6wXbzc4rOrEzVh4Uptde4hhK1TCOvQxYatdIGf6yrTj5Iq9KkuMgL1elBsGyQ== X-OriginatorOrg: microsoft.com Archived-At: Cc: Joe Touch , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:33:39 -0000 T24gRnJpZGF5LCBKdW5lIDUsIDIwMTUgNjo0MCBBTSwgTWljaGFlbCBXZWx6bCB3cm90ZToNCj4N Cj4gLi4uIA0KPiBKdXN0IGZvciBjbGFyaWZpY2F0aW9uOiB0aGlzIHdhc24ndCBhYm91dCB3aGV0 aGVyIHRoZSBsZXZlbCBvZiAicHJvdGVjdGlvbiBhZ2FpbnN0DQo+IGJpdCBlcnJvcnMiIGFzIHN1 Y2ggaXMgaW1wb3J0YW50IG9yIG5vdDogSSB0aGluayB0aGUgbGV2ZWwgb2YgcHJvdGVjdGlvbiBp cyBhIGxlc3MNCj4gaW1wb3J0YW50IGl0ZW0gdG8gY292ZXIgaW4gdGhlIGZpcnN0IGRvY3VtZW50 IGJlY2F1c2UsIGdpdmVuIGN1cnJlbnQgcHJvdG9jb2xzDQo+ICh3aGF0IHRoaXMgZG9jIGlzIGFi b3V0KSwgeW91IGNhbid0IGp1c3Qgc3dpdGNoIGl0IG9uIG9yIG9mZiAtIGl0IGNvbWVzIHdpdGgg YSBjaG9pY2UNCj4gb2YgYSB3aG9sZSBwcm90b2NvbC4gU28gaXQncyBqdXN0IGEgcGFydCBvZiBh IHByb3RvY29sIGRlc2NyaXB0aW9uIC0gc3RhdGljIHByb3RvY29sDQo+IHByb3BlcnRpZXMgdGhh dCBjb21lIGFzIGEgd2hvbGUgd2hlbmV2ZXIgeW91IHBpY2sgdGhlIHByb3RvY29sLg0KDQpJIGRv bid0IHRoaW5rIHRoYXQgYXBwbGljYXRpb25zIGNhcmUgdmVyeSBtdWNoIGFib3V0IHRoZSBkaXN0 aW5jdGlvbiBiZXR3ZWVuIENSQzMyIGFuZCAxNiBiaXQgY2hlY2tzdW0uIFRoZSByZWFsIGRpc3Rp bmN0aW9uIGlzIGJldHdlZW4gInNvbWUgcHJvdGVjdGlvbiIgYW5kICJjcnlwdG9ncmFwaGljIHBy b3RlY3Rpb24sIiBhcyBnaXZlbiBmb3IgZXhhbXBsZSBieSBTU0wvVExTIG9uIHRvcCBvZiBUQ1Au IE9idmlvdXNseSB0aGUgMTYgYml0IGNoZWNrc3VtIDE2IHdpbGwgbGV0IHRocm91Z2ggbW9yZSB0 cmFuc21pc3Npb24gZXJyb3JzIHRoYW4gdGhlIDMyIGJpdCBDUkMsIGJ1dCBlcnJvcnMgY2FuIGFs c28gaGFwcGVuICJhYm92ZSIgdGhlIGNoZWNrc3VtLCBkdXJpbmcgdGhlIHZhcmlvdXMgZGF0YSBt YW5pcHVsYXRpb25zIHBlcmZvcm1lZCBieSB0aGUgdHJhbnNwb3J0IHByb3RvY29scy4gVGhleSBj YW4gYWxzbyBiZSBkdWUgdG8gb3ZlcmFjdGl2ZSBtaWRkbGVib3hlcyB0aGF0IHdpbGwgY2hhbmdl IHRoZSBkYXRhIGFuZCB0aGVuICJmaXgiIHRoZSBjaGVja3N1bS4gQXBwbGljYXRpb25zIHRoYXQg YXJlIGNvbmNlcm5lZCBlbm91Z2ggYWJvdXQgdGhlIGludGVncml0eSBvZiB0aGUgZGF0YSBhcmUg Z29pbmcgdG8gdXNlIGNyeXB0byBlbmQtdG8tZW5kLg0KDQpXaGljaCBpcyBhbiBhcmd1bWVudCBm b3IgdGFraW5nIGEgdmlldyBvZiBzZXJ2aWNlIGRlZmluaXRpb25zICJmcm9tIHRoZSBhcHBsaWNh dGlvbiwiIHJhdGhlciB0aGFuIG1lcmVseSBjYXRhbG9naW5nIHdoYXQgVENQIGFuZCBTQ1RQIGNh biBkbyB0b2RheS4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQo= From nobody Fri Jun 5 10:52:36 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0489E1A0040 for ; Fri, 5 Jun 2015 10:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 44FqDLz1GInG for ; Fri, 5 Jun 2015 10:52:20 -0700 (PDT) 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 D43C31A0033 for ; Fri, 5 Jun 2015 10:52:19 -0700 (PDT) Received: from [192.168.1.200] (p54819223.dip0.t-ipconnect.de [84.129.146.35]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 963AC1C104E94; Fri, 5 Jun 2015 19:52:17 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Tuexen In-Reply-To: <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> Date: Fri, 5 Jun 2015 19:52:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:52:22 -0000 > On 05 Jun 2015, at 16:03, Michael Welzl wrote: >=20 >=20 >> On 05 Jun 2015, at 15:52, Michael Tuexen = wrote: >>=20 >>> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >>>=20 >>>=20 >>>> On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >>>>=20 >>>>> On 05 Jun 2015, at 11:05, Michael Welzl = wrote: >>>>>=20 >>>>>=20 >>>>>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>>>>=20 >>>>>> Okay, just to quickly clarify. In the charter only the word = service is used. We defined later on the words component and feature = which are currently not reflected in the charter. The part I've cited = below, I think, it should say components. However, it does not really = matter because we will in the current document first identify components = and then discuss features. In any case this document will not define a = new interface. >>>>>=20 >>>>> I got that but I disagree about "it should say components" for the = part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>>>>=20 >>>>>=20 >>>>>> I'd also say that this is not the flag ship document (as stated = by Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >>>>>=20 >>>>> Well, this first document is no less important, everything hinges = on it. >>>>>=20 >>>>> So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >>>>>=20 >>>>> When making these decisions, I think we'd first need to go through = the list of things provided to applications by the protocols in what Joe = calls the abstract API. Probably we won't find it there: it's a static = property of the protocols AFAIK. So, next, we go through all the static = properties to figure out what we need to expose. Then, the question = becomes: should a TAPS system decide for or against SCTP based on the = level of error protection? Is this a basis for deciding for this or the = other protocol? >>>>>=20 >>>>> These are important decisions but I think they are secondary, = whereas what the protocols now explicitly offer is primary - because it = would be very strange not to offer what is being offered today. We can = decide to not expose "level of error protection" and give the TAPS more = freedom in choosing the protocol; given that the goal is to stop = connection applications to specific protocols, we CAN do that. >>>> I consider "protecting against bit errors" a service. And I think = the level is important. I agree, TCP and SCTP provide >>>> a protocol dependent level of protection, so there is no need to = expose this in the API of the particular protocol, >>>> however, I do think someone wants a strong checksum or not, and = that will influence the choice of protocols. >>>> So we do have services which are not configurable via the API. >>>=20 >>> Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. >> Such as "reliable" for TCP? Or "byte stream" for TCP? These = properties come with choosing TCP... >=20 > Exactly. >=20 > I meant "important" as "to be discussed first" (hm, maybe simply = "listed first in the doc"). I think it would make things easier and = clearer to first discuss the things that are exposed by the abstract = APIs today. > SCTP will help, then: it exposes "reliable". So if we'd go with that, = the first item in your list above for TCP would already disappear from = the discussion: it will eventually need to be exposed by a TAPS system = because of SCTP anyway, and thus belongs in the list. >=20 > So if the document would, for instance, first list all the things that = the protocol's abstract API now expose, and then follow with static = properties that protocols have (and that a certain combination of chosen = services would entail), then that list of static properties gets shorter = - e.g., for TCP, from the two items above, only "byte stream" would be = left. Structuring the things are a good idea. Which do you get "byte stream", = not "reliable byte stream"? >=20 > My aim here is to try to simplify things so that we can gradually make = progress rather than beginning by discussing a long list where it's very = hard to argue for why one particular bit should be in the list or not. = If folks things I'm not making it easier but harder, please ignore me = :-) I'm only trying to help... Great. Me too. Just trying to understand which things should be listed = in a coherent way... Best regards Michael >=20 > Cheers, > Michael >=20 >=20 From nobody Fri Jun 5 12:53:05 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A1B1A8906 for ; Fri, 5 Jun 2015 12:53:04 -0700 (PDT) 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 yfTABpNZsWD1 for ; Fri, 5 Jun 2015 12:53:02 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431FB1A8903 for ; Fri, 5 Jun 2015 12:53:02 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so64272800wgb.3 for ; Fri, 05 Jun 2015 12:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ou6p95ocHp7Pz83fW3bwRsil/x3RJMtGEop8TSvVwnY=; b=XDbeTK2TQhgcPjSkhZEgmpIcyLrtCWCcFq71qla3JdzOTZkbhZU3KRYN8tZcdmE7CP iQvlfoHAszZFu1Hgf2JwNAQJwr5XKAz3o83YJSQdAmpi2F5FSGsNT+quT+DToWfgqWaU 9aAFeNXme3JqbPQ8Xm29TAbi8wY6jCMttohdAwPrIyjO2Ycgn/rtOkUDg4z8KH3sS9v1 fw6bUEMaEJwRLuDzkRfo3x106knQswc1vZ2ICSM3VYhNB2ua6gcsL5Hidf7zkN5ypeet geO54YSQuLC+QNJNiNt3ohXB/mce7PHJvIKP6NVEEZvbMgEke205xMzAZmWHQ+L8p/r/ F2OA== MIME-Version: 1.0 X-Received: by 10.195.13.1 with SMTP id eu1mr9296764wjd.131.1433533981067; Fri, 05 Jun 2015 12:53:01 -0700 (PDT) Received: by 10.28.145.7 with HTTP; Fri, 5 Jun 2015 12:53:00 -0700 (PDT) In-Reply-To: <5570BF35.7000707@isi.edu> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> <5570BF35.7000707@isi.edu> Date: Fri, 5 Jun 2015 21:53:00 +0200 Message-ID: From: Mohamed Oulmahdi To: Joe Touch Content-Type: multipart/alternative; boundary=047d7bd9131ab710010517caa359 Archived-At: Cc: Christian Huitema , Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 19:53:04 -0000 --047d7bd9131ab710010517caa359 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch wrote: > > > On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote: > > I think that speaking specifically about any protocol in this document > > will not be in the sens of an "abstract" interface for the Transport > > layer, because abstraction means that application will no longer be > > aware of who or what Transport services are really offered. > > We need to be more clear in what we are discussing. > > E.g., an "abstract API" (as I've been calling it) is described as in RFC > 793: > > OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS > > That's abstract only in the sense that it does NOT specify an > implementation in Linux, for example. It is not so abstract that it > applies to all transports - it's indicated for TCP only. > This definition of 'abstract interface" is specific for a given protocol, but the aim in TAPS is a higher level (services). In other words, if this is the d=C3=A9finition of an abstract interface, and is already defined in = RFC 793, what will be the contribution of TAPS by defining its abstract interface? The objective of TAPS is to change the traditional way to use the Transport layer. In fact, traditionally, applications select the appropriate transport service by selecting a given transport protocol. The TAPS vision is to change this, so as applications will request only their desired services, via this abstract interface, and it is to the Transport layer to choose the appropriate protocol according to the application request. It is this level of abstraction that is aimed by TAPS. (see the charter, point 3 especially) > > What you're proposing is a "universal interface", whether abstract > (described as above, using words to describe app-level actions and > events) or instantiated (e.g., using Unix socket(), connect(), accept(), > listen(), etc.). > > Joe > --047d7bd9131ab710010517caa359 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch <touch@isi.edu> w= rote:


On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
> I think that speaking specifically about any protocol in this document=
> will not be in the sens of an "abstract" interface for the T= ransport
> layer, because abstraction means that application will no longer be > aware of who or what Transport services are really offered.

We need to be more clear in what we are discussing.

E.g., an "abstract API" (as I've been calling it) is describe= d as in RFC
793:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS
That's abstract only in the sense that it does NOT specify an
implementation in Linux, for example. It is not so abstract that it
applies to all transports - it's indicated for TCP only.

This definition of 'abstract interface"= is specific for a given protocol, but the aim in TAPS is a higher level (s= ervices). In other words, if this is the d=C3=A9finition of an abstract int= erface, and is already defined in RFC 793, what will be the contribution of= TAPS by defining its abstract interface?

The obje= ctive of TAPS is to change the traditional way to use the Transport layer. = In fact, traditionally, applications select the appropriate transport servi= ce by selecting a given transport protocol. The TAPS vision is to change th= is, so as applications will request only their desired services, via this a= bstract interface, and it is to the Transport layer to choose the appropria= te protocol according to the application request. It is this level of abstr= action that is aimed by TAPS. (see the charter, point 3 especially)

What you're proposing is a "universal interface", whether abs= tract
(described as above, using words to describe app-level actions and
events) or instantiated (e.g., using Unix socket(), connect(), accept(), listen(), etc.).

Joe

--047d7bd9131ab710010517caa359-- From nobody Fri Jun 5 13:17:53 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF0A1B319F for ; Fri, 5 Jun 2015 13:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2Rq7nox57cZ for ; Fri, 5 Jun 2015 13:17:50 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5AC1B319E for ; Fri, 5 Jun 2015 13:17:49 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z0y3n-0006O5-M1; Fri, 05 Jun 2015 22:17:47 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z0y3m-0006zV-SX; Fri, 05 Jun 2015 22:17:47 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Fri, 5 Jun 2015 22:17:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BD14996-27AA-4313-954E-C2CDC1BB8973@ifi.uio.no> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> To: Michael Tuexen X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 29866 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B0C014A919DE5C1D898441253379FD9417848748 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1151 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 20:17:53 -0000 > On 5. jun. 2015, at 19.52, Michael Tuexen = wrote: >=20 >> On 05 Jun 2015, at 16:03, Michael Welzl wrote: >>=20 >>=20 >>> On 05 Jun 2015, at 15:52, Michael Tuexen = wrote: >>>=20 >>>> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >>>>=20 >>>>=20 >>>>> On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >>>>>=20 >>>>>> On 05 Jun 2015, at 11:05, Michael Welzl = wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>>>>>=20 >>>>>>> Okay, just to quickly clarify. In the charter only the word = service is used. We defined later on the words component and feature = which are currently not reflected in the charter. The part I've cited = below, I think, it should say components. However, it does not really = matter because we will in the current document first identify components = and then discuss features. In any case this document will not define a = new interface. >>>>>>=20 >>>>>> I got that but I disagree about "it should say components" for = the part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>>>>>=20 >>>>>>=20 >>>>>>> I'd also say that this is not the flag ship document (as stated = by Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >>>>>>=20 >>>>>> Well, this first document is no less important, everything hinges = on it. >>>>>>=20 >>>>>> So let's think of the future system we're envisioning here. Is it = going to provide "error detection" as a service? Is it going to provide = "strong error detection"? >>>>>>=20 >>>>>> When making these decisions, I think we'd first need to go = through the list of things provided to applications by the protocols in = what Joe calls the abstract API. Probably we won't find it there: it's a = static property of the protocols AFAIK. So, next, we go through all the = static properties to figure out what we need to expose. Then, the = question becomes: should a TAPS system decide for or against SCTP based = on the level of error protection? Is this a basis for deciding for this = or the other protocol? >>>>>>=20 >>>>>> These are important decisions but I think they are secondary, = whereas what the protocols now explicitly offer is primary - because it = would be very strange not to offer what is being offered today. We can = decide to not expose "level of error protection" and give the TAPS more = freedom in choosing the protocol; given that the goal is to stop = connection applications to specific protocols, we CAN do that. >>>>> I consider "protecting against bit errors" a service. And I think = the level is important. I agree, TCP and SCTP provide >>>>> a protocol dependent level of protection, so there is no need to = expose this in the API of the particular protocol, >>>>> however, I do think someone wants a strong checksum or not, and = that will influence the choice of protocols. >>>>> So we do have services which are not configurable via the API. >>>>=20 >>>> Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. >>> Such as "reliable" for TCP? Or "byte stream" for TCP? These = properties come with choosing TCP... >>=20 >> Exactly. >>=20 >> I meant "important" as "to be discussed first" (hm, maybe simply = "listed first in the doc"). I think it would make things easier and = clearer to first discuss the things that are exposed by the abstract = APIs today. >> SCTP will help, then: it exposes "reliable". So if we'd go with that, = the first item in your list above for TCP would already disappear from = the discussion: it will eventually need to be exposed by a TAPS system = because of SCTP anyway, and thus belongs in the list. >>=20 >> So if the document would, for instance, first list all the things = that the protocol's abstract API now expose, and then follow with static = properties that protocols have (and that a certain combination of chosen = services would entail), then that list of static properties gets shorter = - e.g., for TCP, from the two items above, only "byte stream" would be = left. > Structuring the things are a good idea. Which do you get "byte = stream", not "reliable byte stream"? Only "byte stream" because you don't need to talk about reliability = anymore when you have it covered by going through the abstract APIs. Then, of course, things are tied to certain protocols ... after all TCP = *IS* reliable so when you pick it e.g. for the byte stream (or perhaps = MPTCP's functions) you always get reliability with it. But then, certain = mechanisms are semantically compatible in a best effort world - e.g. an = application asking for unreliable data transfer will not break if it = gets reliability (it's just slower). This kind of match-making between = the services and protocols might become easier if we first have a list = of what protocols provide to upper layers, and then have the static = properties per protocol MINUS the things in the first list. That's all = I'm suggesting. Cheers, Michael From nobody Fri Jun 5 13:23:11 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C131B31E1 for ; Fri, 5 Jun 2015 13:23:10 -0700 (PDT) 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 65PRc2_wxaT1 for ; Fri, 5 Jun 2015 13:23:09 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A431B31E7 for ; Fri, 5 Jun 2015 13:22:55 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-202.lsanca.dsl-w.verizon.net [71.103.148.202]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t55KLXGQ012219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2015 13:21:42 -0700 (PDT) Message-ID: <557204CC.8060609@isi.edu> Date: Fri, 05 Jun 2015 13:21:32 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mohamed Oulmahdi References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> <5570BF35.7000707@isi.edu> 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: Cc: Christian Huitema , Brian Trammell , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 20:23:10 -0000 On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote: > > > On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch > wrote: > > > > On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote: > > I think that speaking specifically about any protocol in this document > > will not be in the sens of an "abstract" interface for the Transport > > layer, because abstraction means that application will no longer be > > aware of who or what Transport services are really offered. > > We need to be more clear in what we are discussing. > > E.g., an "abstract API" (as I've been calling it) is described as in RFC > 793: > > OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS > > That's abstract only in the sense that it does NOT specify an > implementation in Linux, for example. It is not so abstract that it > applies to all transports - it's indicated for TCP only. > > This definition of 'abstract interface" is specific for a given > protocol, but the aim in TAPS is a higher level (services). In other > words, if this is the définition of an abstract interface, and is > already defined in RFC 793, what will be the contribution of TAPS by > defining its abstract interface? The first step towards a universal abstract interface is to understand the current specific abstract interfaces. That's what the current document is focused on. > The objective of TAPS is to change the traditional way to use the > Transport layer. In fact, traditionally, applications select the > appropriate transport service by selecting a given transport protocol. > The TAPS vision is to change this, so as applications will request only > their desired services, via this abstract interface, and it is to the > Transport layer to choose the appropriate protocol according to the > application request. It is this level of abstraction that is aimed by > TAPS. (see the charter, point 3 especially) In order to unify or further abstract the API, the current API needs to be understood - but the discussion on the list indicates a lot of disagreement on this. Joe From nobody Fri Jun 5 13:37:38 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8311B31F5 for ; Fri, 5 Jun 2015 13:37:37 -0700 (PDT) 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 bbza8vHR-9hb for ; Fri, 5 Jun 2015 13:37:35 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BB01B31F4 for ; Fri, 5 Jun 2015 13:37:34 -0700 (PDT) Received: by wgme6 with SMTP id e6so64884832wgm.2 for ; Fri, 05 Jun 2015 13:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bIH9tkdpMglxZZd/JrqSKSZW6UuYZynIf2Du0pYUlj8=; b=vTJ7mpDIe4QcEvbgh5WLsCtq2Y8sKOU5/iqo1Uc2EpgTgGzO2LeUbryUQlWhxRYfwZ WxrD5MpzD9aTVLc+YZvVlIU9p+LfaH2WOJeLW/IYItjRHkZTPivRAdOdhPNLuiIc799C ZDH1YN3Q80ocwRiWfwGkn5LuL5OB9Uuai6TUDtPEpCjxsfTpa28d+Zone3idelFFDs5N aBXtHK1rAawjEcKKfk6IE+ZadX1cWyNQoSI1MCGztuLe6mjnMqS4T1M2dnaVEgvE6a0b D4nYIyuAUhPWgxPnThG5HKXalre46lB7pEGhgUPMwSLJR5amcfm2IpxB6JnSHKu6VXIO Tu2g== MIME-Version: 1.0 X-Received: by 10.180.73.10 with SMTP id h10mr104803wiv.21.1433536653673; Fri, 05 Jun 2015 13:37:33 -0700 (PDT) Received: by 10.28.145.7 with HTTP; Fri, 5 Jun 2015 13:37:33 -0700 (PDT) In-Reply-To: <557204CC.8060609@isi.edu> References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <400281DA-6C27-4BFB-9F9B-9E5D09FE9305@ifi.uio.no> <5570BF35.7000707@isi.edu> <557204CC.8060609@isi.edu> Date: Fri, 5 Jun 2015 22:37:33 +0200 Message-ID: From: Mohamed Oulmahdi To: Joe Touch Content-Type: multipart/alternative; boundary=f46d043c7f1e03cb5c0517cb434f Archived-At: Cc: Christian Huitema , Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] A proposal to throw out RTP 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 Jun 2015 20:37:37 -0000 --f46d043c7f1e03cb5c0517cb434f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree, the discussion should be better structured ... On Fri, Jun 5, 2015 at 10:21 PM, Joe Touch wrote: > > > On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote: > > > > > > On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch > > wrote: > > > > > > > > On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote: > > > I think that speaking specifically about any protocol in this > document > > > will not be in the sens of an "abstract" interface for the > Transport > > > layer, because abstraction means that application will no longer = be > > > aware of who or what Transport services are really offered. > > > > We need to be more clear in what we are discussing. > > > > E.g., an "abstract API" (as I've been calling it) is described as i= n > RFC > > 793: > > > > OPEN, SEND, RECEIVE, CLOSE, ABORT, and STATUS > > > > That's abstract only in the sense that it does NOT specify an > > implementation in Linux, for example. It is not so abstract that it > > applies to all transports - it's indicated for TCP only. > > > > This definition of 'abstract interface" is specific for a given > > protocol, but the aim in TAPS is a higher level (services). In other > > words, if this is the d=C3=A9finition of an abstract interface, and is > > already defined in RFC 793, what will be the contribution of TAPS by > > defining its abstract interface? > > The first step towards a universal abstract interface is to understand > the current specific abstract interfaces. That's what the current > document is focused on. > > > The objective of TAPS is to change the traditional way to use the > > Transport layer. In fact, traditionally, applications select the > > appropriate transport service by selecting a given transport protocol. > > The TAPS vision is to change this, so as applications will request only > > their desired services, via this abstract interface, and it is to the > > Transport layer to choose the appropriate protocol according to the > > application request. It is this level of abstraction that is aimed by > > TAPS. (see the charter, point 3 especially) > > In order to unify or further abstract the API, the current API needs to > be understood - but the discussion on the list indicates a lot of > disagreement on this. > > Joe > --f46d043c7f1e03cb5c0517cb434f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree, the discussion should be better =C2=A0structured = ...

On Fri, = Jun 5, 2015 at 10:21 PM, Joe Touch <touch@isi.edu> wrote:


On 6/5/2015 12:53 PM, Mohamed Oulmahdi wrote:
>
>
> On Thu, Jun 4, 2015 at 11:12 PM, Joe Touch <touch@isi.edu
> <mailto:to= uch@isi.edu>> wrote:
>
>
>
>=C2=A0 =C2=A0 =C2=A0On 6/3/2015 2:26 PM, Mohamed Oulmahdi wrote:
>=C2=A0 =C2=A0 =C2=A0> I think that speaking specifically about any p= rotocol in this document
>=C2=A0 =C2=A0 =C2=A0> will not be in the sens of an "abstract&q= uot; interface for the Transport
>=C2=A0 =C2=A0 =C2=A0> layer, because abstraction means that applicat= ion will no longer be
>=C2=A0 =C2=A0 =C2=A0> aware of who or what Transport services are re= ally offered.
>
>=C2=A0 =C2=A0 =C2=A0We need to be more clear in what we are discussing.=
>
>=C2=A0 =C2=A0 =C2=A0E.g., an "abstract API" (as I've been= calling it) is described as in RFC
>=C2=A0 =C2=A0 =C2=A0793:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OPEN, SEND, RECEIVE, CL= OSE, ABORT, and STATUS
>
>=C2=A0 =C2=A0 =C2=A0That's abstract only in the sense that it does = NOT specify an
>=C2=A0 =C2=A0 =C2=A0implementation in Linux, for example. It is not so = abstract that it
>=C2=A0 =C2=A0 =C2=A0applies to all transports - it's indicated for = TCP only.
>
> This definition of 'abstract interface" is specific for a giv= en
> protocol, but the aim in TAPS is a higher level (services). In other > words, if this is the d=C3=A9finition of an abstract interface, and is=
> already defined in RFC 793, what will be the contribution of TAPS by > defining its abstract interface?

The first step towards a universal abstract interface is to understa= nd
the current specific abstract interfaces. That's what the current
document is focused on.

> The objective of TAPS is to change the traditional way to use the
> Transport layer. In fact, traditionally, applications select the
> appropriate transport service by selecting a given transport protocol.=
> The TAPS vision is to change this, so as applications will request onl= y
> their desired services, via this abstract interface, and it is to the<= br> > Transport layer to choose the appropriate protocol according to the > application request. It is this level of abstraction that is aimed by<= br> > TAPS. (see the charter, point 3 especially)

In order to unify or further abstract the API, the current API needs= to
be understood - but the discussion on the list indicates a lot of
disagreement on this.

Joe

--f46d043c7f1e03cb5c0517cb434f-- From nobody Fri Jun 5 13:39:13 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767301B31FC for ; Fri, 5 Jun 2015 13:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 rvuZmT2K27Ru for ; Fri, 5 Jun 2015 13:39:11 -0700 (PDT) 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 9D7681B31FB for ; Fri, 5 Jun 2015 13:39:10 -0700 (PDT) Received: from [192.168.1.200] (p54819223.dip0.t-ipconnect.de [84.129.146.35]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 4D0761C0E984B; Fri, 5 Jun 2015 22:39:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Tuexen In-Reply-To: <3BD14996-27AA-4313-954E-C2CDC1BB8973@ifi.uio.no> Date: Fri, 5 Jun 2015 22:39:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <00F80982-91FD-46B6-A3A1-5B0AE09F7437@lurchi.franken.de> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5564F560.3080507@isi.edu> <89748C72-7178-43AC-A1EC-1C024E1A4F38@tik.ee.ethz.ch> <5565FCC9.1040905@isi.edu> <079D0104-2842-4889-8BAC-FE0C015A4E71@tik.ee.ethz.ch> <556751CA.5030403@isi.edu> <67803D51-4D58-460F-BE48-32AA22395685@tik.ee.ethz.ch> <55675BF2.3000409@isi.edu> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> <3BD14996-27AA-4313-954E-C2CDC1BB8973@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 20:39:12 -0000 > On 05 Jun 2015, at 22:17, Michael Welzl wrote: >=20 >=20 >> On 5. jun. 2015, at 19.52, Michael Tuexen = wrote: >>=20 >>> On 05 Jun 2015, at 16:03, Michael Welzl wrote: >>>=20 >>>=20 >>>> On 05 Jun 2015, at 15:52, Michael Tuexen = wrote: >>>>=20 >>>>> On 05 Jun 2015, at 15:39, Michael Welzl = wrote: >>>>>=20 >>>>>=20 >>>>>> On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >>>>>>=20 >>>>>>> On 05 Jun 2015, at 11:05, Michael Welzl = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>>>>>>=20 >>>>>>>> Okay, just to quickly clarify. In the charter only the word = service is used. We defined later on the words component and feature = which are currently not reflected in the charter. The part I've cited = below, I think, it should say components. However, it does not really = matter because we will in the current document first identify components = and then discuss features. In any case this document will not define a = new interface. >>>>>>>=20 >>>>>>> I got that but I disagree about "it should say components" for = the part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>>>>>>=20 >>>>>>>=20 >>>>>>>> I'd also say that this is not the flag ship document (as stated = by Joe). The flagship document probably is the third item on the charter = which then will probably also talk about the interface in more detail = (charter says on the third doc: "This document will explain how to = select and engage an appropriate protocol ..."). >>>>>>>=20 >>>>>>> Well, this first document is no less important, everything = hinges on it. >>>>>>>=20 >>>>>>> So let's think of the future system we're envisioning here. Is = it going to provide "error detection" as a service? Is it going to = provide "strong error detection"? >>>>>>>=20 >>>>>>> When making these decisions, I think we'd first need to go = through the list of things provided to applications by the protocols in = what Joe calls the abstract API. Probably we won't find it there: it's a = static property of the protocols AFAIK. So, next, we go through all the = static properties to figure out what we need to expose. Then, the = question becomes: should a TAPS system decide for or against SCTP based = on the level of error protection? Is this a basis for deciding for this = or the other protocol? >>>>>>>=20 >>>>>>> These are important decisions but I think they are secondary, = whereas what the protocols now explicitly offer is primary - because it = would be very strange not to offer what is being offered today. We can = decide to not expose "level of error protection" and give the TAPS more = freedom in choosing the protocol; given that the goal is to stop = connection applications to specific protocols, we CAN do that. >>>>>> I consider "protecting against bit errors" a service. And I think = the level is important. I agree, TCP and SCTP provide >>>>>> a protocol dependent level of protection, so there is no need to = expose this in the API of the particular protocol, >>>>>> however, I do think someone wants a strong checksum or not, and = that will influence the choice of protocols. >>>>>> So we do have services which are not configurable via the API. >>>>>=20 >>>>> Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. >>>> Such as "reliable" for TCP? Or "byte stream" for TCP? These = properties come with choosing TCP... >>>=20 >>> Exactly. >>>=20 >>> I meant "important" as "to be discussed first" (hm, maybe simply = "listed first in the doc"). I think it would make things easier and = clearer to first discuss the things that are exposed by the abstract = APIs today. >>> SCTP will help, then: it exposes "reliable". So if we'd go with = that, the first item in your list above for TCP would already disappear = from the discussion: it will eventually need to be exposed by a TAPS = system because of SCTP anyway, and thus belongs in the list. >>>=20 >>> So if the document would, for instance, first list all the things = that the protocol's abstract API now expose, and then follow with static = properties that protocols have (and that a certain combination of chosen = services would entail), then that list of static properties gets shorter = - e.g., for TCP, from the two items above, only "byte stream" would be = left. >> Structuring the things are a good idea. Which do you get "byte = stream", not "reliable byte stream"? >=20 > Only "byte stream" because you don't need to talk about reliability = anymore when you have it covered by going through the abstract APIs. OK. So are talking about an abstract API for all protocols, not about an = abstract API for a particular protocol, right? Furthermore you are saying that the abstract API does provide a = specification of the level reliability, but not of byte stream vs = message oriented? Thanks for helping me to get things clear... Best regards Michael >=20 > Then, of course, things are tied to certain protocols ... after all = TCP *IS* reliable so when you pick it e.g. for the byte stream (or = perhaps MPTCP's functions) you always get reliability with it. But then, = certain mechanisms are semantically compatible in a best effort world - = e.g. an application asking for unreliable data transfer will not break = if it gets reliability (it's just slower). This kind of match-making = between the services and protocols might become easier if we first have = a list of what protocols provide to upper layers, and then have the = static properties per protocol MINUS the things in the first list. = That's all I'm suggesting. >=20 > Cheers, > Michael >=20 >=20 From nobody Fri Jun 5 15:12:43 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C341A8A25 for ; Fri, 5 Jun 2015 15:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 CYEe1wyLKpXc for ; Fri, 5 Jun 2015 15:12:39 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0D41A8A06 for ; Fri, 5 Jun 2015 15:12:39 -0700 (PDT) X-Spam-Processed: mail.kau.se, Sat, 06 Jun 2015 00:11:56 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 213.113.182.107 X-MDArrival-Date: Sat, 06 Jun 2015 00:11:56 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org Message-ID: <55721ECA.7080709@kau.se> Date: Sat, 06 Jun 2015 00:12:26 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: taps@ietf.org References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> <3BD14996-27AA-4313-954E-C2CDC1BB8973@ifi.uio .no> In-Reply-To: <3BD14996-27AA-4313-954E-C2CDC1BB8973@ifi.uio.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 22:12:42 -0000 On 2015-06-05 22:17, Michael Welzl wrote: >> On 5. jun. 2015, at 19.52, Michael Tuexen wrote: >> >>> On 05 Jun 2015, at 16:03, Michael Welzl wrote: >>> >>> >>>> On 05 Jun 2015, at 15:52, Michael Tuexen wrote: >>>> >>>>> On 05 Jun 2015, at 15:39, Michael Welzl wrote: >>>>> >>>>> >>>>>> On 05 Jun 2015, at 12:35, Michael Tuexen wrote: >>>>>> >>>>>>> On 05 Jun 2015, at 11:05, Michael Welzl wrote: >>>>>>> >>>>>>> >>>>>>>> On 5. jun. 2015, at 10.12, Mirja Kühlewind wrote: >>>>>>>> >>>>>>>> Okay, just to quickly clarify. In the charter only the word service is used. We defined later on the words component and feature which are currently not reflected in the charter. The part I've cited below, I think, it should say components. However, it does not really matter because we will in the current document first identify components and then discuss features. In any case this document will not define a new interface. >>>>>>> I got that but I disagree about "it should say components" for the part in the charter: from the definition, the component is an implementation, not what is exposed to the application. I think the more important part is to capture what's exposed to the application. For example: SCTP has a component called "strong error detection (CRC32C)". TCP has a component called "error detection (checksum)". This is probably not exposed to the application as such by any of these protocols. I'll explain below why this makes it less important in my opinion... >>>>>>> >>>>>>> >>>>>>>> I'd also say that this is not the flag ship document (as stated by Joe). The flagship document probably is the third item on the charter which then will probably also talk about the interface in more detail (charter says on the third doc: "This document will explain how to select and engage an appropriate protocol ..."). >>>>>>> Well, this first document is no less important, everything hinges on it. >>>>>>> >>>>>>> So let's think of the future system we're envisioning here. Is it going to provide "error detection" as a service? Is it going to provide "strong error detection"? >>>>>>> >>>>>>> When making these decisions, I think we'd first need to go through the list of things provided to applications by the protocols in what Joe calls the abstract API. Probably we won't find it there: it's a static property of the protocols AFAIK. So, next, we go through all the static properties to figure out what we need to expose. Then, the question becomes: should a TAPS system decide for or against SCTP based on the level of error protection? Is this a basis for deciding for this or the other protocol? >>>>>>> >>>>>>> These are important decisions but I think they are secondary, whereas what the protocols now explicitly offer is primary - because it would be very strange not to offer what is being offered today. We can decide to not expose "level of error protection" and give the TAPS more freedom in choosing the protocol; given that the goal is to stop connection applications to specific protocols, we CAN do that. >>>>>> I consider "protecting against bit errors" a service. And I think the level is important. I agree, TCP and SCTP provide >>>>>> a protocol dependent level of protection, so there is no need to expose this in the API of the particular protocol, >>>>>> however, I do think someone wants a strong checksum or not, and that will influence the choice of protocols. >>>>>> So we do have services which are not configurable via the API. >>>>> Just for clarification: this wasn't about whether the level of "protection against bit errors" as such is important or not: I think the level of protection is a less important item to cover in the first document because, given current protocols (what this doc is about), you can't just switch it on or off - it comes with a choice of a whole protocol. So it's just a part of a protocol description - static protocol properties that come as a whole whenever you pick the protocol. >>>> Such as "reliable" for TCP? Or "byte stream" for TCP? These properties come with choosing TCP... >>> Exactly. >>> >>> I meant "important" as "to be discussed first" (hm, maybe simply "listed first in the doc"). I think it would make things easier and clearer to first discuss the things that are exposed by the abstract APIs today. >>> SCTP will help, then: it exposes "reliable". So if we'd go with that, the first item in your list above for TCP would already disappear from the discussion: it will eventually need to be exposed by a TAPS system because of SCTP anyway, and thus belongs in the list. >>> >>> So if the document would, for instance, first list all the things that the protocol's abstract API now expose, and then follow with static properties that protocols have (and that a certain combination of chosen services would entail), then that list of static properties gets shorter - e.g., for TCP, from the two items above, only "byte stream" would be left. >> Structuring the things are a good idea. Which do you get "byte stream", not "reliable byte stream"? > Only "byte stream" because you don't need to talk about reliability anymore when you have it covered by going through the abstract APIs. > > Then, of course, things are tied to certain protocols ... after all TCP *IS* reliable so when you pick it e.g. for the byte stream (or perhaps MPTCP's functions) you always get reliability with it. But then, certain mechanisms are semantically compatible in a best effort world - e.g. an application asking for unreliable data transfer will not break if it gets reliability (it's just slower). This kind of match-making between the services and protocols might become easier if we first have a list of what protocols provide to upper layers, and then have the static properties per protocol MINUS the things in the first list. That's all I'm suggesting. Even if there will be some overlap, I think it will be more clear to describe the abstract API and the static properties per protocol. This is what a protocol provides to upper layers and it will make the description of each protocol self-contained. The static properties are not that many and we can still make a clear distinction between the abstract API and the static properties in the description of each protocol. For the continued work it will also be useful to have a complete and agreed upon view of what each protocol provides. Cheers, Anna > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 5 21:37:46 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA71ACE27 for ; Fri, 5 Jun 2015 21:37:45 -0700 (PDT) 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 E1ET3YQAXSF3 for ; Fri, 5 Jun 2015 21:37:42 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E2E1ACE22 for ; Fri, 5 Jun 2015 21:37:41 -0700 (PDT) X-AuditID: 12074423-f79496d000000d43-72-557279136eb2 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 87.3F.03395.31972755; Sat, 6 Jun 2015 00:37:39 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t564bcWi032072; Sat, 6 Jun 2015 00:37:39 -0400 Received: from w92exedge3.EXCHANGE.MIT.EDU (w92exedge3.exchange.mit.edu [18.7.73.15]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id t564bbGm012252; Sat, 6 Jun 2015 00:37:38 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 8.2.255.0; Sat, 6 Jun 2015 00:37:06 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.162]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0158.001; Sat, 6 Jun 2015 00:37:37 -0400 From: Marie-Jose Montpetit To: Anna Brunstrom Thread-Topic: [Taps] I-D Action: draft-ietf-taps-transports-04.txt Thread-Index: AQHQl7FIUwE5HR8PKE+UWFpM4Ir68Z2OgpOAgACZ2QCAAPIVgIAAR+2AgAEDuQCAAJLKAIAACGsAgAADsACAABUJgIAA0fqAgAAGSgCAABGqgIAAhpaAgAE8R4CAAzd8gIAANfiAgAAC6wCAABysgIAACZiAgAWQ/ACAAA6TAIAAGVaAgAAzZQCAAAOPAIAAAy6AgAA/2QCAACilAIAAIAwAgABrnIA= Date: Sat, 6 Jun 2015 04:37:36 +0000 Message-ID: <04B96CC7-46F7-42F9-9212-4EC58DB202B5@mit.edu> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> <3BD14996-27AA-4313-954E-C2CDC1BB8973@ifi.uio .no> <55721ECA.7080709@kau.se> In-Reply-To: <55721ECA.7080709@kau.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [149.154.208.24] Content-Type: multipart/signed; boundary="Apple-Mail=_23E4FEEA-E5EE-4066-8728-573C98369B30"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKJsWRmVeSWpSXmKPExsUixCmqrCtcWRRq0D1Z3eLEj8vMFndiHJg8 liz5yeTx90IrWwBTFJdNSmpOZllqkb5dAlfGpK3sBe/8KibMXcLWwNjr3MXIySEhYCKx4sxx NghbTOLCvfVANheHkMBiJomj968xgySEBPYzSqw8wQiROMooceXGXGYIZyujxIOti6CcVYwS R1tWM4K0sAnoSDxtXQTWLiKgJTHhVjN7FyMHB7OAssT+p7UgYWEBR4kjew6yQ5Q4Sdxt3c8I Yb9jlLi2yRbEZhFQkZjS/AIszitgJfHz7l+oK+ZzSMw/dYMVJMEpoCaxd+s9JhCbEeiH76fW gNnMAuISt57MZ4L4TUTi4cXTcH/+2/UQylaSOLn2ONjPzAJTGCW+n+1kgtgmKHFy5hOWCYwS s5DMmoWsbhaSOogibYllC18zQ9iaEvu7l0PFTSVeH/3ICGFbS8z4dZANwlaUmNL9kH0BI8cq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXTO93MwSvdSU0k2MoBhnd1HewfjnoNIhRgEORiUeXgnf olAh1sSy4srcQ4ySHExKorw9RUAhvqT8lMqMxOKM+KLSnNTiQ4wqQLsebVh9gVGKJS8/L1VJ hDdaAqiONyWxsiq1KB+mTJqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IE781yoEbBotT0 1Iq0zJwShDQTB+chRgkOHqDhC0BqeIsLEnOLM9Mh8qcYFaXEeWUqgBICIImM0jy4XlhqfsUo DvSWMK8BSBUPMK3Ddb8CGswENPg6awHI4JJEhJRUA2N9dFX/e/1P93Y+bM02cLCbFeWQ9MqH +eoXPi8314Df371fvQnjN1ROZ/9RPmu6/6NrM/UOhHRlnU1/tVD+sNT3kF+zv3udeNG+rLqk LW964cV3z8IuLLj999vOopnKueL+W53q2j45L7WxDug8+84za4vq4wZzrnzvaXrzq3a+WOqW G7bE+YQSS3FGoqEWc1FxIgDctcbEqAMAAA== Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 04:37:45 -0000 --Apple-Mail=_23E4FEEA-E5EE-4066-8728-573C98369B30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I completely agree. Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Jun 6, 2015, at 12:12 AM, Anna Brunstrom = wrote: >=20 >=20 > On 2015-06-05 22:17, Michael Welzl wrote: >>> On 5. jun. 2015, at 19.52, Michael Tuexen = wrote: >>>=20 >>>> On 05 Jun 2015, at 16:03, Michael Welzl wrote: >>>>=20 >>>>=20 >>>>> On 05 Jun 2015, at 15:52, Michael Tuexen = wrote: >>>>>=20 >>>>>> On 05 Jun 2015, at 15:39, Michael Welzl = wrote: >>>>>>=20 >>>>>>=20 >>>>>>> On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >>>>>>>=20 >>>>>>>> On 05 Jun 2015, at 11:05, Michael Welzl = wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>>>>>>>=20 >>>>>>>>> Okay, just to quickly clarify. In the charter only the word = service is used. We defined later on the words component and feature = which are currently not reflected in the charter. The part I've cited = below, I think, it should say components. However, it does not really = matter because we will in the current document first identify components = and then discuss features. In any case this document will not define a = new interface. >>>>>>>> I got that but I disagree about "it should say components" for = the part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> I'd also say that this is not the flag ship document (as = stated by Joe). The flagship document probably is the third item on the = charter which then will probably also talk about the interface in more = detail (charter says on the third doc: "This document will explain how = to select and engage an appropriate protocol ..."). >>>>>>>> Well, this first document is no less important, everything = hinges on it. >>>>>>>>=20 >>>>>>>> So let's think of the future system we're envisioning here. Is = it going to provide "error detection" as a service? Is it going to = provide "strong error detection"? >>>>>>>>=20 >>>>>>>> When making these decisions, I think we'd first need to go = through the list of things provided to applications by the protocols in = what Joe calls the abstract API. Probably we won't find it there: it's a = static property of the protocols AFAIK. So, next, we go through all the = static properties to figure out what we need to expose. Then, the = question becomes: should a TAPS system decide for or against SCTP based = on the level of error protection? Is this a basis for deciding for this = or the other protocol? >>>>>>>>=20 >>>>>>>> These are important decisions but I think they are secondary, = whereas what the protocols now explicitly offer is primary - because it = would be very strange not to offer what is being offered today. We can = decide to not expose "level of error protection" and give the TAPS more = freedom in choosing the protocol; given that the goal is to stop = connection applications to specific protocols, we CAN do that. >>>>>>> I consider "protecting against bit errors" a service. And I = think the level is important. I agree, TCP and SCTP provide >>>>>>> a protocol dependent level of protection, so there is no need to = expose this in the API of the particular protocol, >>>>>>> however, I do think someone wants a strong checksum or not, and = that will influence the choice of protocols. >>>>>>> So we do have services which are not configurable via the API. >>>>>> Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. >>>>> Such as "reliable" for TCP? Or "byte stream" for TCP? These = properties come with choosing TCP... >>>> Exactly. >>>>=20 >>>> I meant "important" as "to be discussed first" (hm, maybe simply = "listed first in the doc"). I think it would make things easier and = clearer to first discuss the things that are exposed by the abstract = APIs today. >>>> SCTP will help, then: it exposes "reliable". So if we'd go with = that, the first item in your list above for TCP would already disappear = from the discussion: it will eventually need to be exposed by a TAPS = system because of SCTP anyway, and thus belongs in the list. >>>>=20 >>>> So if the document would, for instance, first list all the things = that the protocol's abstract API now expose, and then follow with static = properties that protocols have (and that a certain combination of chosen = services would entail), then that list of static properties gets shorter = - e.g., for TCP, from the two items above, only "byte stream" would be = left. >>> Structuring the things are a good idea. Which do you get "byte = stream", not "reliable byte stream"? >> Only "byte stream" because you don't need to talk about reliability = anymore when you have it covered by going through the abstract APIs. >>=20 >> Then, of course, things are tied to certain protocols ... after all = TCP *IS* reliable so when you pick it e.g. for the byte stream (or = perhaps MPTCP's functions) you always get reliability with it. But then, = certain mechanisms are semantically compatible in a best effort world - = e.g. an application asking for unreliable data transfer will not break = if it gets reliability (it's just slower). This kind of match-making = between the services and protocols might become easier if we first have = a list of what protocols provide to upper layers, and then have the = static properties per protocol MINUS the things in the first list. = That's all I'm suggesting. >=20 > Even if there will be some overlap, I think it will be more clear to = describe the abstract API and the static properties per protocol. This = is what a protocol provides to upper layers and it will make the = description of each protocol self-contained. The static properties are = not that many and we can still make a clear distinction between the = abstract API and the static properties in the description of each = protocol. >=20 > For the continued work it will also be useful to have a complete and = agreed upon view of what each protocol provides. >=20 > Cheers, > Anna >=20 >>=20 >> Cheers, >> Michael >>=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 --Apple-Mail=_23E4FEEA-E5EE-4066-8728-573C98369B30 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDRDCCA0Aw ggKpoAMCAQICEQDvxXGV9K8f4AQSxWSxJJPrMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNVBAYTAlVT MRYwFAYDVQQIEw1NYXNzYWNodXNldHRzMS4wLAYDVQQKEyVNYXNzYWNodXNldHRzIEluc3RpdHV0 ZSBvZiBUZWNobm9sb2d5MRUwEwYDVQQLEwxDbGllbnQgQ0EgdjEwHhcNMTQwNzAyMTM1MzUyWhcN MTUwNzMwMTM1MzUyWjCBqzELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAs BgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENs aWVudCBDQSB2MTEdMBsGA1UEAxMUTWFyaWUtSm9zZSBNb250cGV0aXQxHjAcBgkqhkiG9w0BCQEW D21hcmllam9ATUlULkVEVTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvMWfBmhCuS6ol1Q/ KWrhtk0nMP3xU6T6R7Q7y/VnbE6BtYxFaRQ09PzHiv9B58UDhbhNN5y59BVPWWfevOImFitx4PY0 c6wMYGxC6aR0l9VySQ0VNavkRRKujyPxxjz+GRb64mAWzP0xqutz6SaZ2Fi0lxgccRheH/d0OLTg agUCAwEAAaOBoTCBnjAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwCwYDVR0PBAQDAgXgMB0GA1UdDgQWBBRCoWStx3OeBP0pszhPjQgj z28cdDAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY2EubWl0LmVkdS9jYS9taXRjbGllbnQuY3Js MA0GCSqGSIb3DQEBBQUAA4GBAHdNroykei2WKB4gO19mPUIyPMBFZrw5f87upM40csBB5HBBtZO4 op6JqoMxs93UrS+KO2+UK8c4zL/lRBRfbmQ7/r+gbJn0YqMb93eEHXR2u07xiRxHrI8oaC9RGhzc NMjbuAPbxlfY55CEPA2LLT/3nibZfvy+UPV/Xdkbg71gMYICtTCCArECAQEwgYEwbDELMAkGA1UE BhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1c2V0dHMgSW5z dGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/FcZX0rx/gBBLF ZLEkk+swCQYFKw4DAhoFAKCCAYkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNjA2MDQzNzM1WjAjBgkqhkiG9w0BCQQxFgQUVnoM7sInnm1SZaviaabtDqs6ZvAw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYCLRFKZZJlKhQdwIIZT2jGK9d3i6Ipx9PVA TVUhzCIXukXvwFbNcoD8sBNPL74xc/0lmJb6wTCsTAuXu7wC2bF7Fd/UORBHMiovBBERpSbxAOjn ep9Pp/RXj/FVUfksnrE9oiP5nyygz0lYQFJOvKiTs+frxz6bjrxVLix3ztJybAAAAAAAAA== --Apple-Mail=_23E4FEEA-E5EE-4066-8728-573C98369B30-- From nobody Sat Jun 6 02:47:45 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758761A8A46 for ; Sat, 6 Jun 2015 02:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5M336NAxScT for ; Sat, 6 Jun 2015 02:47:40 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067721A8A01 for ; Sat, 6 Jun 2015 02:47:39 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z1AhT-0004p6-Se; Sat, 06 Jun 2015 11:47:35 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z1AhS-0005xO-Vm; Sat, 06 Jun 2015 11:47:35 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <04B96CC7-46F7-42F9-9212-4EC58DB202B5@mit.edu> Date: Sat, 6 Jun 2015 11:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3B86AB05-61FB-4B70-A55C-F7A45F5C41EE@ifi.uio.no> References: <20150526124118.12610.15479.idtracker@ietfa.amsl.com> <5F82FD43-4B0C-4473-BA63-36EA1DD337EE@ifi.uio.no> <20150529080351.GG2764@blasturvion.dynhost.nicta.com.au> <3D2E27E3-62EB-4BBD-94CD-D8159FC9A1AE@tik.ee.ethz.ch> <5568A2B9.2040206@isi.edu> <556C8E8C.9020102@isi.edu> <44E65FC2-87EC-476A-A73E-B3CF1A177B92@tik.ee.ethz.ch> <882B05C0-394E-48E5-AE31-B1C23CB762D7@ifi.uio.no> <55715A02.4020203@tik.ee.ethz.ch> <5B8 5C2F2-7CD7-40C0-856A-8544AA0288BC@lurchi.franken.de> <663118B4-6237-491B-ABD1-6858754E2621@ifi.uio.no> <3BD14996-27AA-4313-954E-C2CDC1BB8973@ifi.uio .no> <5 5721ECA.7080709@kau.se> <04B96CC7-46F7-42F9-9212-4EC58DB202B5@mit.edu> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 9 sum msgs/h 2 total rcpts 29873 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 320854DDD8AF0732A49A0F5CC1B2BF8B16777F06 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1153 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Anna Brunstrom , "taps@ietf.org" Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 09:47:43 -0000 I do, too - I didn't mean that we should merge the abstract APIs = together right now, in this first doc! This was just about the thought = process - while my answer to Michael Tuexen is "yes, I meant the = complete abstract API", that was just about what we could eventually get = from having a complete view of this API. > On 6. jun. 2015, at 06.37, Marie-Jose Montpetit = wrote: >=20 > I completely agree. >=20 > Marie-Jose Montpetit, Ph.D. > mariejo@mit.edu > @SocialTVMIT >=20 >> On Jun 6, 2015, at 12:12 AM, Anna Brunstrom = wrote: >>=20 >>=20 >> On 2015-06-05 22:17, Michael Welzl wrote: >>>> On 5. jun. 2015, at 19.52, Michael Tuexen = wrote: >>>>=20 >>>>> On 05 Jun 2015, at 16:03, Michael Welzl = wrote: >>>>>=20 >>>>>=20 >>>>>> On 05 Jun 2015, at 15:52, Michael Tuexen = wrote: >>>>>>=20 >>>>>>> On 05 Jun 2015, at 15:39, Michael Welzl = wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>> On 05 Jun 2015, at 12:35, Michael Tuexen = wrote: >>>>>>>>=20 >>>>>>>>> On 05 Jun 2015, at 11:05, Michael Welzl = wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> On 5. jun. 2015, at 10.12, Mirja K=C3=BChlewind = wrote: >>>>>>>>>>=20 >>>>>>>>>> Okay, just to quickly clarify. In the charter only the word = service is used. We defined later on the words component and feature = which are currently not reflected in the charter. The part I've cited = below, I think, it should say components. However, it does not really = matter because we will in the current document first identify components = and then discuss features. In any case this document will not define a = new interface. >>>>>>>>> I got that but I disagree about "it should say components" for = the part in the charter: from the definition, the component is an = implementation, not what is exposed to the application. I think the more = important part is to capture what's exposed to the application. For = example: SCTP has a component called "strong error detection (CRC32C)". = TCP has a component called "error detection (checksum)". This is = probably not exposed to the application as such by any of these = protocols. I'll explain below why this makes it less important in my = opinion... >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> I'd also say that this is not the flag ship document (as = stated by Joe). The flagship document probably is the third item on the = charter which then will probably also talk about the interface in more = detail (charter says on the third doc: "This document will explain how = to select and engage an appropriate protocol ..."). >>>>>>>>> Well, this first document is no less important, everything = hinges on it. >>>>>>>>>=20 >>>>>>>>> So let's think of the future system we're envisioning here. Is = it going to provide "error detection" as a service? Is it going to = provide "strong error detection"? >>>>>>>>>=20 >>>>>>>>> When making these decisions, I think we'd first need to go = through the list of things provided to applications by the protocols in = what Joe calls the abstract API. Probably we won't find it there: it's a = static property of the protocols AFAIK. So, next, we go through all the = static properties to figure out what we need to expose. Then, the = question becomes: should a TAPS system decide for or against SCTP based = on the level of error protection? Is this a basis for deciding for this = or the other protocol? >>>>>>>>>=20 >>>>>>>>> These are important decisions but I think they are secondary, = whereas what the protocols now explicitly offer is primary - because it = would be very strange not to offer what is being offered today. We can = decide to not expose "level of error protection" and give the TAPS more = freedom in choosing the protocol; given that the goal is to stop = connection applications to specific protocols, we CAN do that. >>>>>>>> I consider "protecting against bit errors" a service. And I = think the level is important. I agree, TCP and SCTP provide >>>>>>>> a protocol dependent level of protection, so there is no need = to expose this in the API of the particular protocol, >>>>>>>> however, I do think someone wants a strong checksum or not, and = that will influence the choice of protocols. >>>>>>>> So we do have services which are not configurable via the API. >>>>>>> Just for clarification: this wasn't about whether the level of = "protection against bit errors" as such is important or not: I think the = level of protection is a less important item to cover in the first = document because, given current protocols (what this doc is about), you = can't just switch it on or off - it comes with a choice of a whole = protocol. So it's just a part of a protocol description - static = protocol properties that come as a whole whenever you pick the protocol. >>>>>> Such as "reliable" for TCP? Or "byte stream" for TCP? These = properties come with choosing TCP... >>>>> Exactly. >>>>>=20 >>>>> I meant "important" as "to be discussed first" (hm, maybe simply = "listed first in the doc"). I think it would make things easier and = clearer to first discuss the things that are exposed by the abstract = APIs today. >>>>> SCTP will help, then: it exposes "reliable". So if we'd go with = that, the first item in your list above for TCP would already disappear = from the discussion: it will eventually need to be exposed by a TAPS = system because of SCTP anyway, and thus belongs in the list. >>>>>=20 >>>>> So if the document would, for instance, first list all the things = that the protocol's abstract API now expose, and then follow with static = properties that protocols have (and that a certain combination of chosen = services would entail), then that list of static properties gets shorter = - e.g., for TCP, from the two items above, only "byte stream" would be = left. >>>> Structuring the things are a good idea. Which do you get "byte = stream", not "reliable byte stream"? >>> Only "byte stream" because you don't need to talk about reliability = anymore when you have it covered by going through the abstract APIs. >>>=20 >>> Then, of course, things are tied to certain protocols ... after all = TCP *IS* reliable so when you pick it e.g. for the byte stream (or = perhaps MPTCP's functions) you always get reliability with it. But then, = certain mechanisms are semantically compatible in a best effort world - = e.g. an application asking for unreliable data transfer will not break = if it gets reliability (it's just slower). This kind of match-making = between the services and protocols might become easier if we first have = a list of what protocols provide to upper layers, and then have the = static properties per protocol MINUS the things in the first list. = That's all I'm suggesting. >>=20 >> Even if there will be some overlap, I think it will be more clear to = describe the abstract API and the static properties per protocol. This = is what a protocol provides to upper layers and it will make the = description of each protocol self-contained. The static properties are = not that many and we can still make a clear distinction between the = abstract API and the static properties in the description of each = protocol. >>=20 >> For the continued work it will also be useful to have a complete and = agreed upon view of what each protocol provides. >>=20 >> Cheers, >> Anna >>=20 >>>=20 >>> Cheers, >>> Michael >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Jun 8 01:19:58 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 920DD1B2D71 for ; Mon, 8 Jun 2015 01:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ClyLKbpwQkZm for ; Mon, 8 Jun 2015 01:19:55 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBDE1B2D69 for ; Mon, 8 Jun 2015 01:19:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 820C9D9315; Mon, 8 Jun 2015 10:19:53 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MQ0lzohK5QZM; Mon, 8 Jun 2015 10:19:53 +0200 (MEST) Received: from [192.168.178.33] (x5f71602c.dyn.telefonica.de [95.113.96.44]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0117CD9303; Mon, 8 Jun 2015 10:19:52 +0200 (MEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?windows-1252?Q?Mirja_K=FChlewind?= In-Reply-To: <5570C125.1000903@isi.edu> Date: Mon, 8 Jun 2015 10:19:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <5570C125.1000903@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Christian Huitema , "taps@ietf.org" , Marie-Jose Montpetit , Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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, 08 Jun 2015 08:19:57 -0000 Hi Joe, the document defines one more term: Transport Service Instance: an arrangement of transport protocols with a selected set of features and configuration parameters that implements a single transport service, e.g. a protocol stack (RTP over UDP). This is to describe also a stack of protocols which an application might = use to get a certain transport service. (we might need to re-write this = maybe, because I now have the feeling that this is hard to understand). Currently we are not using this term in this document because we try to = describe components of anything that might/could provide a transport = service feature of all protocols that that might be part of a protocol = stack that can be accessed by an application. That=92s what we had in mind when we came up with this terminology and I = think think it covers the case where HTTP over TCP is used as a = transport =82substitute=91. Mirja > Am 04.06.2015 um 23:20 schrieb Joe Touch : >=20 >=20 >=20 > On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote: >> In my presentation in Dallas I had suggested adding RTP (and even >> HTTP) because as both Mirja and Christian mention some 'applications' >> are requesting functionalities that are got given elsewhere. >=20 > The core of this issue is "what is a transport protocol". >=20 > To the user, "transport" is the entire stack between their program and > the network (IP) layer - sometimes even including that (e.g., IPsec). >=20 > To typical transport protocols (e.g., UDP, TCP), everything that > accesses a transport protocol is the "application" layer. >=20 >> =46rom the document: > Transport Service: a set of transport service features, without an > association to any given framing protocol, which provides a > complete service to an application. >=20 > Transport Protocol: an implementation that provides one or more > different transport services using a specific framing and header > format on the wire. >=20 > By those definitions, EVERYTHING between the user program and the link > layer is arguably part of the services an app sees, which include = "shim" > services and layers such as: IPsec, TLS, and RTP. >=20 > I would argue that HTTP is the application that uses TCP (or TLS/TCP), > but not a separate service, but that's true only for conventional web > service. >=20 > There are many services built on top of HTTP, at which point HTTP is > just another part of what this document calls a "transport service". >=20 > As a result, unless you'll be describing every possible stack between > the user program and the link layer, this document cannot proceed with > the current definitions. >=20 > Joe From nobody Mon Jun 8 21:10:53 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E931ACE90 for ; Mon, 8 Jun 2015 21:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6xk1dcG4Gs1 for ; Mon, 8 Jun 2015 21:10:50 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2021ACE8E for ; Mon, 8 Jun 2015 21:10:50 -0700 (PDT) Received: from [192.168.1.6] (70.44.1.67.res-cmts.flt3.ptd.net [70.44.1.67]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t594A5Kq021511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 8 Jun 2015 21:10:16 -0700 (PDT) Message-ID: <5576671B.4070404@isi.edu> Date: Mon, 08 Jun 2015 21:10:03 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?Mirja_K=FChlewind?= References: <4600A299-E820-4D67-8ADF-BB9783931E49@trammell.ch> <556F2413.5040308@tik.ee.ethz.ch> <36C995D9-261C-4AAD-A86D-681F58CACF9A@mit.edu> <5570C125.1000903@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-MailScanner-ID: t594A5Kq021511 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Christian Huitema , "taps@ietf.org" , Marie-Jose Montpetit , Brian Trammell Subject: Re: [Taps] A proposal to throw out RTP 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, 09 Jun 2015 04:10:51 -0000 On 6/8/2015 1:19 AM, Mirja Kühlewind wrote: > Hi Joe, > > the document defines one more term: > > Transport Service Instance: an arrangement of transport protocols > with a selected set of features and configuration parameters that > implements a single transport service, e.g. a protocol stack (RTP > over UDP). > > This is to describe also a stack of protocols which an application > might use to get a certain transport service. (we might need to re-write > this maybe, because I now have the feeling that this is hard to understand). If that's what it means, it certainly needs to be rewritten. A substack of protocols isn't "an arrangement of transport protocols". The former is vertical and involves functional composition; the latter is horizontal ("peers" in the ISO stack at L4) and involves the union of capabilities of the peers. > Currently we are not using this term in this document because we try > to describe components of anything that might/could provide a transport > service feature of all protocols that that might be part of a protocol > stack that can be accessed by an application. I don't understand that either. I really think that the definitions need to decouple the concept of service interface to the upper layer from mechanisms that provide those services. > That’s what we had in mind when we came up with this terminology and > I think think it covers the case where HTTP over TCP is used as a > transport ‚substitute‘. HTTP isn't a transport protocol. I don't know anyone who would call it that or be able to use it as a substitute for TCP. Joe > Mirja > > > >> Am 04.06.2015 um 23:20 schrieb Joe Touch : >> >> >> >> On 6/3/2015 10:45 PM, Marie-Jose Montpetit wrote: >>> In my presentation in Dallas I had suggested adding RTP (and even >>> HTTP) because as both Mirja and Christian mention some 'applications' >>> are requesting functionalities that are got given elsewhere. >> >> The core of this issue is "what is a transport protocol". >> >> To the user, "transport" is the entire stack between their program and >> the network (IP) layer - sometimes even including that (e.g., IPsec). >> >> To typical transport protocols (e.g., UDP, TCP), everything that >> accesses a transport protocol is the "application" layer. >> >>> From the document: >> Transport Service: a set of transport service features, without an >> association to any given framing protocol, which provides a >> complete service to an application. >> >> Transport Protocol: an implementation that provides one or more >> different transport services using a specific framing and header >> format on the wire. >> >> By those definitions, EVERYTHING between the user program and the link >> layer is arguably part of the services an app sees, which include "shim" >> services and layers such as: IPsec, TLS, and RTP. >> >> I would argue that HTTP is the application that uses TCP (or TLS/TCP), >> but not a separate service, but that's true only for conventional web >> service. >> >> There are many services built on top of HTTP, at which point HTTP is >> just another part of what this document calls a "transport service". >> >> As a result, unless you'll be describing every possible stack between >> the user program and the link layer, this document cannot proceed with >> the current definitions. >> >> Joe > From nobody Tue Jun 9 09:49:25 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1021A90DE; Tue, 9 Jun 2015 09:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX0z3tFMZcTK; Tue, 9 Jun 2015 09:49:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D13821A90B7; Tue, 9 Jun 2015 09:49:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150609164917.14670.26357.idtracker@ietfa.amsl.com> Date: Tue, 09 Jun 2015 09:49:17 -0700 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-05.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, 09 Jun 2015 16:49:22 -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-05.txt Pages : 38 Date : 2015-06-09 Abstract: This document describes services provided by existing IETF protocols and congestion control mechanisms. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-05 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 Jun 9 09:53:58 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93031A8829 for ; Tue, 9 Jun 2015 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uc6dSrMglCvw for ; Tue, 9 Jun 2015 09:53:54 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 168001A88AB for ; Tue, 9 Jun 2015 09:53:54 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 689881A0024 for ; Tue, 9 Jun 2015 18:53:52 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_D8C39296-91B2-478D-BBBD-7B57EB933DF9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 9 Jun 2015 18:53:51 +0200 References: <20150609164917.14670.58834.idtracker@ietfa.amsl.com> To: taps WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-05.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:53:56 -0000 --Apple-Mail=_D8C39296-91B2-478D-BBBD-7B57EB933DF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've just posted -05, which adds sections on MP-TCP and TLS. It does = not address any other topics of discussion on the list as yet. We plan = to post a -06 soon (hopefully this week) which will attempt to bring = more unity and clarity to component and feature lists, in line with the = discussion on the list. Cheers, Brian (for the taps-transports editors) > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-ietf-taps-transports-05.txt > Date: 9 Jun 2015 18:49:17 CEST > To: "Gorry Fairhurst" , "Mirja Kuehlewind" = , "Brian Trammell" , = "Mirja Kuehlewind" , "Godred Fairhurst" = , "Brian Trammell" >=20 >=20 > A new version of I-D, draft-ietf-taps-transports-05.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-ietf-taps-transports > Revision: 05 > Title: Services provided by IETF transport protocols = and congestion control mechanisms > Document date: 2015-06-09 > Group: taps > Pages: 38 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-taps-transports-05.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-taps-transports-05 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-05 >=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 >=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 > The IETF Secretariat >=20 --Apple-Mail=_D8C39296-91B2-478D-BBBD-7B57EB933DF9 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 iQEcBAEBCgAGBQJVdxogAAoJENt3nsOmbNJclfgIANeIpk1NQ0DdMvGowoQkYqcS iiiapFi13xZshEl/kCHygNoyVNg/RGHi/KZ1FVeauLJ68vNi3SSOhOkPzpgfS3et jduxSNEBmJSb/Yor2u5ee3FilPzpd6+QJl5VdTrE+csEiYnMjIxKclyJw4zZdPGs gaoU5X9O+zJ5IAHqbuY4SVaeDOp+u81uXPPrg+3+C/pqFqRNrEHfvQ1DQtGNvtnB 8rSgDTQ2kQ1wl4xEro8SQfIuukwCaNUw3KGa/oO5b69T3llzsbUraN5pqcRzG/HU dIwkNV0U84+19ZJIuxdZAz8si52MecxtzpCAtHnZ5/Ql18PkgR+HsKvHe4x71Jc= =McOC -----END PGP SIGNATURE----- --Apple-Mail=_D8C39296-91B2-478D-BBBD-7B57EB933DF9-- From nobody Tue Jun 9 10:21:20 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB041B2D77 for ; Tue, 9 Jun 2015 10:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 kKb5UEvjTJwI for ; Tue, 9 Jun 2015 10:21:17 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5461AC3A5 for ; Tue, 9 Jun 2015 10:21:17 -0700 (PDT) Received: by ieclw1 with SMTP id lw1so18619253iec.3 for ; Tue, 09 Jun 2015 10:21:16 -0700 (PDT) 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=o0xGedNiLhCoKw3HOPjVLH++xPaQqF1TZN04//4+B0o=; b=JRvTX17yRnUygEpKRxSVL2ZC9lLDsSRLWN6/GKWH/ZdYSi8PWz9jfqHEZ+zcFFKD1D esbcDbkXGnukPT2gOKHt0F0yGbKlmcGK6zEq06jAsiN//xHzovGka3NJtFX2kGaXshVz poHybaWaUPeY4/E8wXzJWNMTCmELc4UoMRgowwCVdHOyz8+/G0ijI33O1O2jIJXGDwXM j+ljouBl2IB7c8R0tBvRJ0hEhK9Fdm1dEufiBXRJGud4t3xcM1WnG/gCRH4EZ/O+SZ0W coC0K0S90ZGXfXWAE7PwY6Ea8qqTVD5fupep6is8N6P3oVlOEo1SO8mmuDoDP6IMItLy JBxA== MIME-Version: 1.0 X-Received: by 10.43.96.5 with SMTP id ce5mr22849434icc.96.1433870476775; Tue, 09 Jun 2015 10:21:16 -0700 (PDT) Received: by 10.64.59.225 with HTTP; Tue, 9 Jun 2015 10:21:16 -0700 (PDT) Date: Tue, 9 Jun 2015 13:21:16 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=bcaec51866c26c19e1051818fcb5 Archived-At: Subject: [Taps] Agenda for Prague - solicitation for topics 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, 09 Jun 2015 17:21:18 -0000 --bcaec51866c26c19e1051818fcb5 Content-Type: text/plain; charset=UTF-8 Time to plan for our next wg meeting. Here are a few proposals for topics that seem worth discussing. Seem about right? Anything else we should talk about? Keep in mind the goal is to finish this first document before broadening the discussion. - Review the component / features list for consistency and completeness. - Discuss what an "abstract API" means in the TAPS context - Consider whether other definitions need further revision. --bcaec51866c26c19e1051818fcb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Time to = plan for our next wg meeting.=C2=A0 Here are a few proposals for topics tha= t seem worth discussing.=C2=A0 Seem about right?=C2=A0 Anything else we sho= uld talk about?=C2=A0 Keep in mind the goal is to finish this first documen= t before broadening the discussion.

- Review the component / features list for consistency and c= ompleteness.=C2=A0

- = Discuss what an "abstract API" means in the TAPS context

- Consider whether other defi= nitions need further revision.
--bcaec51866c26c19e1051818fcb5-- From nobody Thu Jun 11 04:52:57 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114771ACD98 for ; Thu, 11 Jun 2015 04:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ48XqzRd90y for ; Thu, 11 Jun 2015 04:52:50 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811DD1ACD96 for ; Thu, 11 Jun 2015 04:52:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 3ED87D9316; Thu, 11 Jun 2015 13:52:47 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BRdBypS48IIs; Thu, 11 Jun 2015 13:52:46 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id E37F7D9309; Thu, 11 Jun 2015 13:52:46 +0200 (MEST) Message-ID: <5579768E.5060402@tik.ee.ethz.ch> Date: Thu, 11 Jun 2015 13:52:46 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "taps@ietf.org" , Brian Trammell Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] TCP components 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, 11 Jun 2015 11:52:56 -0000 Hi all, we gave it a first try to rewrite the component section for TCP. The insight I took from the discussion on the list is that components probably are much more linked to the implementation (choices) a certain protocol made while features are probably more high-level having the question in mind what does an application potentially want/need to know. So for the components in TCP we now have the following list: - Connection-oriented bidirectional communication using three-way handshake connection setup with feature negotiation and an explicit distinction between passive and active open: This implies both unicast addressing and a guarantee of return routability. - Single stream-oriented transmission: The stream abstraction atop the datagram service provided by IP is implemented by dividing the stream into segments. - Limited control over segment transmission scheduling (Nagle's algorithm): This allows for delay minimization in interactive applications. - Port multiplexing, with application-to-port mapping during connection setup: Note that in the presence of network address and port translation (NAPT), TCP ports are in effect part of the endpoint address for forwarding purposes. - Full reliability based on ack-based loss detection and retransmission: Loss is sensed using duplicated acks ("fast retransmit"), which places a lower bound on the delay inherent in this approach to reliability. - Error detection based on a checksum covering the network and transport headers as well as payload: Packets that are detected as corrupted are dropped, relying on the reliability mechanism to retransmit them. - Window-based flow control, with receiver-side window management and signaling of available window: Scaling the flow control window beyond 64kB requires the use of an optional feature, which has performance implications in environments where this option is not supported. - Window-based congestion control reacting to loss, delay, retransmission timeout, or an explicit congestion signal (ECN): Most commonly used is a loss signal from the reliability component's retransmission mechanism. TCP reacts to a congestion signal by reducing the size of the congestion window; retransmission timeout is generally handled with a larger reaction than other signals. We are currently still working on the list of features that results from thiese components but we are not there yet. Probably we not only need the features itself but also properties/aspects (or however you want to call this) of the feature. We already had this discussion a bit but wanted to postpone the decision if we really need to define an own term for this until we are sure that we need it. We are posting this list of (TCP) components now because we would like to get some feedback if this goes into the right direction/is on the right level of detail before we go on and apply this also to other protocols. Brian and Mirja From nobody Thu Jun 11 05:32:11 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA51ACE48 for ; Thu, 11 Jun 2015 05:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.911 X-Spam-Level: X-Spam-Status: No, score=-3.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 MWTnE1Gx0uWA for ; Thu, 11 Jun 2015 05:32:05 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A4EA11ACE0C for ; Thu, 11 Jun 2015 05:31:40 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id F2D181B001AB; Thu, 11 Jun 2015 13:31:38 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 11 Jun 2015 13:30:37 +0100 Message-ID: <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> In-Reply-To: <5579768E.5060402@tik.ee.ethz.ch> References: <5579768E.5060402@tik.ee.ethz.ch> Date: Thu, 11 Jun 2015 13:30:37 +0100 From: gorry@erg.abdn.ac.uk To: =?iso-8859-1?Q?=22Mirja_K=C3=BChlewind=22?= 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: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 11 Jun 2015 12:32:10 -0000 I have a few comments, see below: > Hi all, > > we gave it a first try to rewrite the component section for TCP. The > insight I > took from the discussion on the list is that components probably are much > more > linked to the implementation (choices) a certain protocol made while > features > are probably more high-level having the question in mind what does an > application potentially want/need to know. > > So for the components in TCP we now have the following list: > > - Connection-oriented bidirectional communication using three-way > handshake > connection setup with > feature negotiation and an explicit distinction between passive and > active open: > This implies both unicast addressing and a guarantee of return > routability. > - Single stream-oriented transmission: > The stream abstraction atop the datagram service provided by IP is > implemented > by dividing > the stream into segments. > - Limited control over segment transmission scheduling (Nagle's > algorithm): > This allows for delay minimization in interactive applications. GF: Not quite - To me, it prevents increased delay from the TCP protocol. It doesn't really control anything to reduce delay. > - Port multiplexing, with application-to-port mapping during connection > setup: GF: Thinking on this, is application-to-port mapping really a TCP function? port-mapping is similar in other transports, and doesn't really have any different support in TCP (contrast to the Service Code in DCCP) > Note that in the presence of network address and port translation (NAPT), > TCP > ports are > in effect part of the endpoint address for forwarding purposes. > GF: This is the case only for those middle boxes that do NAPT, load-ballancing etc, saying they are part of the endpoint address is to me confusing forwarding by middle boxes from forwarding by routers - I'd prefer to be more careful here. > - Full reliability based on ack-based loss detection and retransmission: > Loss is sensed using duplicated acks ("fast retransmit"), which places a > lower > bound on > the delay inherent in this approach to reliability. > GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in SCPS-TP and probably doesn't nee dot be mentioned). > - Error detection based on a checksum covering the network and transport > headers > as well as payload: > Packets that are detected as corrupted are dropped, relying on the > reliability > mechanism > to retransmit them. > GF: True (actually packets header checks and data segments + pseudo header) > - Window-based flow control, with receiver-side window management and > signaling > of available window: > Scaling the flow control window beyond 64kB requires the use of an > optional > feature, > which has performance implications in environments where this option is > not > supported. > GF: Does environment mean path? or something else? > - Window-based congestion control reacting to loss, delay, retransmission > timeout, or > an explicit congestion signal (ECN): > Most commonly used is a loss signal from the reliability component's > retransmission mechanism. > TCP reacts to a congestion signal by reducing the size of the congestion > window; > retransmission timeout is generally handled with a larger reaction than > other signals. > GF: Generally? Shouldn't RTO imply loss of path state and always result in a larger reaction? (RTO back-off for instance). > > We are currently still working on the list of features that results from > thiese > components but we are not there yet. Probably we not only need the > features > itself but also properties/aspects (or however you want to call this) of > the > feature. We already had this discussion a bit but wanted to postpone the > decision if we really need to define an own term for this until we are > sure that > we need it. > > We are posting this list of (TCP) components now because we would like to > get > some feedback if this goes into the right direction/is on the right level > of > detail before we go on and apply this also to other protocols. > > Brian and Mirja > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Thu Jun 11 07:11:51 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8621AD37C for ; Thu, 11 Jun 2015 07:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od7ncJ3NutiV for ; Thu, 11 Jun 2015 07:11:46 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14411AD376 for ; Thu, 11 Jun 2015 07:11:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 12FC4D9305; Thu, 11 Jun 2015 16:11:42 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0J-w5kXRubpP; Thu, 11 Jun 2015 16:11:41 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id AE9B0D9304; Thu, 11 Jun 2015 16:11:41 +0200 (MEST) Message-ID: <5579971D.9040509@tik.ee.ethz.ch> Date: Thu, 11 Jun 2015 16:11:41 +0200 From: =?windows-1252?Q?Mirja_K=FChlewind?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: <5579768E.5060402@tik.ee.ethz.ch> <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> In-Reply-To: <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 11 Jun 2015 14:11:49 -0000 Hi Gorry, see below. >> - Limited control over segment transmission scheduling (Nagle's >> algorithm): >> This allows for delay minimization in interactive applications. > > GF: Not quite - To me, it prevents increased delay from the TCP protocol. > It doesn't really control anything to reduce delay. Yes, I think we wanted to say the same thing here; don't really see the difference... > >> - Port multiplexing, with application-to-port mapping during connection >> setup: > > GF: Thinking on this, is application-to-port mapping really a TCP > function? port-mapping is similar in other transports, and doesn't really > have any different support in TCP (contrast to the Service Code in DCCP) No it's not specific to TCP but it's still something you get when you use TCP and that's what we wanted to document here. > >> Note that in the presence of network address and port translation (NAPT), >> TCP >> ports are >> in effect part of the endpoint address for forwarding purposes. >> > GF: This is the case only for those middle boxes that do NAPT, > load-ballancing etc, saying they are part of the endpoint address is to me > confusing forwarding by middle boxes from forwarding by routers - I'd > prefer to be more careful here. I agree that we should be careful here about the wording. However this was only a note to explain slightly better what we had in mind here. > >> - Full reliability based on ack-based loss detection and retransmission: >> Loss is sensed using duplicated acks ("fast retransmit"), which places a >> lower >> bound on >> the delay inherent in this approach to reliability. >> > GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in > SCPS-TP and probably doesn't nee dot be mentioned). I'd say DupACK and RTO is both ACK-based loss detection where in the latter case no ACKs are received for a certain time. However we can add both explicitly here. What we probably should mention is that RTO puts a maximum bound on the delay. I agree that SACK should probably be mentioned as well here because this again helps speeding up the retransmissions and therefore helps reducing delay by head of line blocking. > >> - Error detection based on a checksum covering the network and transport >> headers >> as well as payload: >> Packets that are detected as corrupted are dropped, relying on the >> reliability >> mechanism >> to retransmit them. >> > GF: True (actually packets header checks and data segments + pseudo header) Sorry, what do you mean by pseudo header here? > >> - Window-based flow control, with receiver-side window management and >> signaling >> of available window: >> Scaling the flow control window beyond 64kB requires the use of an >> optional >> feature, >> which has performance implications in environments where this option is >> not >> supported. >> > GF: Does environment mean path? or something else? Both option stripping on the path or no support of the receiving end point. Can make this more clear. > >> - Window-based congestion control reacting to loss, delay, retransmission >> timeout, or >> an explicit congestion signal (ECN): >> Most commonly used is a loss signal from the reliability component's >> retransmission mechanism. >> TCP reacts to a congestion signal by reducing the size of the congestion >> window; >> retransmission timeout is generally handled with a larger reaction than >> other signals. >> > GF: Generally? Shouldn't RTO imply loss of path state and always result in > a larger reaction? (RTO back-off for instance). In principle yes, but you could easily also implement an congestion control algorithm there the window is set to minimum for every dupACK. The 'generally' is because there is not the one and only congestion control in TCP and therefore you never know what people actually implement. Mirja From nobody Thu Jun 11 07:25:49 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0E81B29DA for ; Thu, 11 Jun 2015 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7DfZbNqtHA0 for ; Thu, 11 Jun 2015 07:25:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5C1B29E4 for ; Thu, 11 Jun 2015 07:25:40 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 5ABA01B001AB; Thu, 11 Jun 2015 15:25:41 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Thu, 11 Jun 2015 15:24:38 +0100 Message-ID: <793b109b9fb4bc5dea2db3801cf33e3f.squirrel@erg.abdn.ac.uk> In-Reply-To: <5579971D.9040509@tik.ee.ethz.ch> References: <5579768E.5060402@tik.ee.ethz.ch> <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> <5579971D.9040509@tik.ee.ethz.ch> Date: Thu, 11 Jun 2015 15:24:38 +0100 From: gorry@erg.abdn.ac.uk To: =?iso-8859-1?Q?=22Mirja_K=FChlewind=22?= 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: Cc: gorry@erg.abdn.ac.uk, Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 11 Jun 2015 14:25:42 -0000 We seem to agree mostly, a few small comments in-line > Hi Gorry, > > see below. > >>> - Limited control over segment transmission scheduling (Nagle's >>> algorithm): >>> This allows for delay minimization in interactive applications. >> >> GF: Not quite - To me, it prevents increased delay from the TCP >> protocol. >> It doesn't really control anything to reduce delay. > > Yes, I think we wanted to say the same thing here; don't really see the > difference... > >> >>> - Port multiplexing, with application-to-port mapping during connection >>> setup: >> >> GF: Thinking on this, is application-to-port mapping really a TCP >> function? port-mapping is similar in other transports, and doesn't >> really >> have any different support in TCP (contrast to the Service Code in DCCP) > > No it's not specific to TCP but it's still something you get when you use > TCP and that's what we wanted to document here. > So would we have the same text in UDP, SCTP, etc? >> >>> Note that in the presence of network address and port translation >>> (NAPT), >>> TCP >>> ports are >>> in effect part of the endpoint address for forwarding purposes. >>> >> GF: This is the case only for those middle boxes that do NAPT, >> load-ballancing etc, saying they are part of the endpoint address is to >> me >> confusing forwarding by middle boxes from forwarding by routers - I'd >> prefer to be more careful here. > > I agree that we should be careful here about the wording. However this was > only a note to explain slightly better what we had in mind here. > >> >>> - Full reliability based on ack-based loss detection and >>> retransmission: >>> Loss is sensed using duplicated acks ("fast retransmit"), which places >>> a lower bound on >>> the delay inherent in this approach to reliability. >>> >> GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in >> SCPS-TP and probably doesn't nee dot be mentioned). > > I'd say DupACK and RTO is both ACK-based loss detection where in the > latter case > no ACKs are received for a certain time. However we can add both > explicitly > here. What we probably should mention is that RTO puts a maximum bound on > the > delay. I agree that SACK should probably be mentioned as well here because > this > again helps speeding up the retransmissions and therefore helps reducing > delay > by head of line blocking. > >> >>> - Error detection based on a checksum covering the network and >>> transport >>> headers >>> as well as payload: >>> Packets that are detected as corrupted are dropped, relying on the >>> reliability >>> mechanism >>> to retransmit them. >>> >> GF: True (actually packets header checks and data segments + pseudo >> header) > > Sorry, what do you mean by pseudo header here? > Only that TCP combines the segment data with the pseudo header from IP to perform the checksum. For IPv4, this also assumes that each IP datagram also passes the IP datagram checksum for each datagram (fragment) >> >>> - Window-based flow control, with receiver-side window management and >>> signaling >>> of available window: >>> Scaling the flow control window beyond 64kB requires the use of an >>> optional >>> feature, >>> which has performance implications in environments where this option >>> is >>> not >>> supported. >>> >> GF: Does environment mean path? or something else? > > Both option stripping on the path or no support of the receiving end > point. Can make this more clear. > I'd prefer to be clear on this. > >> >>> - Window-based congestion control reacting to loss, delay, >>> retransmission >>> timeout, or >>> an explicit congestion signal (ECN): >>> Most commonly used is a loss signal from the reliability component's >>> retransmission mechanism. >>> TCP reacts to a congestion signal by reducing the size of the >>> congestion >>> window; >>> retransmission timeout is generally handled with a larger reaction >>> than >>> other signals. >>> >> GF: Generally? Shouldn't RTO imply loss of path state and always result >> in >> a larger reaction? (RTO back-off for instance). > > In principle yes, but you could easily also implement an congestion > control > algorithm there the window is set to minimum for every dupACK. The > 'generally' > is because there is not the one and only congestion control in TCP and > therefore > you never know what people actually implement. > > Mirja > > Gorry From nobody Thu Jun 11 07:40:09 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7198A1B2A8D for ; Thu, 11 Jun 2015 07:40:07 -0700 (PDT) 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 RKAgzdgPVvIC for ; Thu, 11 Jun 2015 07:40:05 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8460F1A890B for ; Thu, 11 Jun 2015 07:36:44 -0700 (PDT) Received: by wgv5 with SMTP id 5so6484741wgv.1 for ; Thu, 11 Jun 2015 07:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2m2PgPAN3Fqa5p1Lbraiwr6WePhpHAimESrohPcmhOw=; b=yo43CkxZuZokXv9UnQKaf1GugcefyewzZroZvbPeL62E9IS61rT42Lqs78hJ7Db80t ID5UQMt3F4+v+fseJk0yF5M/Yx2HrWWmSlYjockqsiMzMJ6nM3kY2oHfDZ+E8RBpLBkv XGnCBkqJspTIuSxgDzt8B7NXJHPjm52m5DEaKFk3vHOYvpNVia8G/SkjcWjzdtgimUVK tttjh8rxJFn3uwp8cxQr0JJRyTByQ+iuMHrQX09S7siGedfDd5PqwmAgyLsnm1gzjkF7 rJ7sO1WRyTUxEx+y1onpSjjBjAob1vDxjJRl74UL+KCWWtGacqHDwZnRDuiOUWJjrAwL nhCg== MIME-Version: 1.0 X-Received: by 10.180.73.10 with SMTP id h10mr29921157wiv.21.1434033403301; Thu, 11 Jun 2015 07:36:43 -0700 (PDT) Received: by 10.28.145.7 with HTTP; Thu, 11 Jun 2015 07:36:43 -0700 (PDT) Received: by 10.28.145.7 with HTTP; Thu, 11 Jun 2015 07:36:43 -0700 (PDT) In-Reply-To: <5579971D.9040509@tik.ee.ethz.ch> References: <5579768E.5060402@tik.ee.ethz.ch> <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> <5579971D.9040509@tik.ee.ethz.ch> Date: Thu, 11 Jun 2015 16:36:43 +0200 Message-ID: From: Mohamed Oulmahdi To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=f46d043c7f1e99954805183eebe4 Archived-At: Cc: gorry@erg.abdn.ac.uk, Brian Trammell , taps@ietf.org Subject: Re: [Taps] TCP components 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, 11 Jun 2015 14:40:07 -0000 --f46d043c7f1e99954805183eebe4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Jun 11, 2015 4:11 PM, "Mirja K=C3=BChlewind" wrote: > > Hi Gorry, > > see below. > > >>> - Limited control over segment transmission scheduling (Nagle's >>> algorithm): >>> This allows for delay minimization in interactive applications. >> >> >> GF: Not quite - To me, it prevents increased delay from the TCP protocol= . >> It doesn't really control anything to reduce delay. > > > Yes, I think we wanted to say the same thing here; don't really see the difference... I don't understand this delay optimization. Is it thanks to Nagle's algorithm or for the possibility of its deactivation? Because it's known that this algorithm increase delay and so became unsuitable for delay-sensitive applications... > > >> >>> - Port multiplexing, with application-to-port mapping during connection >>> setup: >> >> >> GF: Thinking on this, is application-to-port mapping really a TCP >> function? port-mapping is similar in other transports, and doesn't reall= y >> have any different support in TCP (contrast to the Service Code in DCCP) > > > No it's not specific to TCP but it's still something you get when you use TCP and that's what we wanted to document here. > > >> >>> Note that in the presence of network address and port translation (NAPT), >>> TCP >>> ports are >>> in effect part of the endpoint address for forwarding purposes. >>> >> GF: This is the case only for those middle boxes that do NAPT, >> load-ballancing etc, saying they are part of the endpoint address is to me >> confusing forwarding by middle boxes from forwarding by routers - I'd >> prefer to be more careful here. > > > I agree that we should be careful here about the wording. However this was only a note to explain slightly better what we had in mind here. > > >> >>> - Full reliability based on ack-based loss detection and retransmission= : >>> Loss is sensed using duplicated acks ("fast retransmit"), which places a >>> lower >>> bound on >>> the delay inherent in this approach to reliability. >>> >> GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used in >> SCPS-TP and probably doesn't nee dot be mentioned). > > > I'd say DupACK and RTO is both ACK-based loss detection where in the latter case no ACKs are received for a certain time. However we can add both explicitly here. What we probably should mention is that RTO puts a maximum bound on the delay. I agree that SACK should probably be mentioned as well here because this again helps speeding up the retransmissions and therefore helps reducing delay by head of line blocking. > > >> >>> - Error detection based on a checksum covering the network and transpor= t >>> headers >>> as well as payload: >>> Packets that are detected as corrupted are dropped, relying on the >>> reliability >>> mechanism >>> to retransmit them. >>> >> GF: True (actually packets header checks and data segments + pseudo header) > > > Sorry, what do you mean by pseudo header here? > > >> >>> - Window-based flow control, with receiver-side window management and >>> signaling >>> of available window: >>> Scaling the flow control window beyond 64kB requires the use of an >>> optional >>> feature, >>> which has performance implications in environments where this option is >>> not >>> supported. >>> >> GF: Does environment mean path? or something else? > > > Both option stripping on the path or no support of the receiving end point. Can make this more clear. > > > >> >>> - Window-based congestion control reacting to loss, delay, retransmission >>> timeout, or >>> an explicit congestion signal (ECN): >>> Most commonly used is a loss signal from the reliability component's >>> retransmission mechanism. >>> TCP reacts to a congestion signal by reducing the size of the congestion >>> window; >>> retransmission timeout is generally handled with a larger reaction than >>> other signals. >>> >> GF: Generally? Shouldn't RTO imply loss of path state and always result in >> a larger reaction? (RTO back-off for instance). > > > In principle yes, but you could easily also implement an congestion control algorithm there the window is set to minimum for every dupACK. The 'generally' is because there is not the one and only congestion control in TCP and therefore you never know what people actually implement. > > > Mirja > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --f46d043c7f1e99954805183eebe4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

On Jun 11, 2015 4:11 PM, "Mirja K=C3=BChlewind" &l= t;mirja.kuehlewind@tik.e= e.ethz.ch> wrote:
>
> Hi Gorry,
>
> see below.
>
>
>>> - Limited control over segment transmission scheduling (Nagle&= #39;s
>>> algorithm):
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This allows for delay minimization= in interactive applications.
>>
>>
>> GF: Not quite - To me, it prevents increased delay from the TCP pr= otocol.
>> It doesn't really control anything to reduce delay.
>
>
> Yes, I think we wanted to say the same thing here; don't really se= e the difference...

=C2=A0I don't understand this delay optimization. Is it = thanks to Nagle's=C2=A0 algorithm or for the possibility of its deactiv= ation? Because it's known that this algorithm increase delay and so bec= ame unsuitable for delay-sensitive applications...
>
>
>>
>>> - Port multiplexing, with application-to-port mapping during c= onnection
>>> setup:
>>
>>
>> GF: Thinking on this, is application-to-port mapping really a TCP<= br> >> function? port-mapping is similar in other transports, and doesn&#= 39;t really
>> have any different support in TCP (contrast to the Service Code in= DCCP)
>
>
> No it's not specific to TCP but it's still something you get w= hen you use TCP and that's what we wanted to document here.
>
>
>>
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that in the presence of netwo= rk address and port translation (NAPT),
>>> TCP
>>> ports are
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 in effect part of the endpoint add= ress for forwarding purposes.
>>>
>> GF: This is the case only for those middle boxes that do NAPT,
>> load-ballancing etc, saying they are part of the endpoint address = is to me
>> confusing forwarding by middle boxes from forwarding by routers - = I'd
>> prefer to be more careful here.
>
>
> I agree that we should be careful here about the wording. However this= was only a note to explain slightly better what we had in mind here.
>
>
>>
>>> - Full reliability based on ack-based loss detection and retra= nsmission:
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Loss is sensed using duplicated ac= ks ("fast retransmit"), which places a
>>> lower
>>> bound on
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the delay inherent in this approac= h to reliability.
>>>
>> GF: DupACK, SACK, and the RTO. (explicit NACK is I think only used= in
>> SCPS-TP and probably doesn't nee dot be mentioned).
>
>
> I'd say DupACK and RTO is both ACK-based loss detection where in t= he latter case no ACKs are received for a certain time. However we can add = both explicitly here. What we probably should mention is that RTO puts a ma= ximum bound on the delay. I agree that SACK should probably be mentioned as= well here because this again helps speeding up the retransmissions and the= refore helps reducing delay by head of line blocking.
>
>
>>
>>> - Error detection based on a checksum covering the network and= transport
>>> headers
>>> as well as payload:
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packets that are detected as corru= pted are dropped, relying on the
>>> reliability
>>> mechanism
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 to retransmit them.
>>>
>> GF: True (actually packets header checks and data segments + pseud= o header)
>
>
> Sorry, what do you mean by pseudo header here?
>
>
>>
>>> - Window-based flow control, with receiver-side window managem= ent and
>>> signaling
>>> of available window:
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Scaling the flow control window be= yond 64kB requires the use of an
>>> optional
>>> feature,
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 which has performance implications= in environments where this option is
>>> not
>>> supported.
>>>
>> GF: Does environment mean path? or something else?
>
>
> Both option stripping on the path or no support of the receiving end p= oint. Can make this more clear.
>
>
>
>>
>>> - Window-based congestion control reacting to loss, delay, ret= ransmission
>>> timeout, or
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 an explicit congestion signal (ECN= ):
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Most commonly used is a loss signa= l from the reliability component's
>>> retransmission mechanism.
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP reacts to a congestion signal = by reducing the size of the congestion
>>> window;
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 retransmission timeout is generall= y handled with a larger reaction than
>>> other=C2=A0 signals.
>>>
>> GF: Generally? Shouldn't RTO imply loss of path state and alwa= ys result in
>> a larger reaction? (RTO back-off for instance).
>
>
> In principle yes, but you could easily also implement an congestion co= ntrol algorithm there the window is set to minimum for every dupACK. The &#= 39;generally' is because there is not the one and only congestion contr= ol in TCP and therefore you never know what people actually implement.
>
>
> Mirja
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.iet= f.org/mailman/listinfo/taps

--f46d043c7f1e99954805183eebe4-- From nobody Thu Jun 11 07:43:01 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178301A8730 for ; Thu, 11 Jun 2015 07:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tur4LjBkS9Si for ; Thu, 11 Jun 2015 07:42:58 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E451A890F for ; Thu, 11 Jun 2015 07:42:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 949F4D9307; Thu, 11 Jun 2015 16:42:27 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KGGOIoN0nEBe; Thu, 11 Jun 2015 16:42:27 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 5BB97D9305; Thu, 11 Jun 2015 16:42:27 +0200 (MEST) Message-ID: <55799E53.2050200@tik.ee.ethz.ch> Date: Thu, 11 Jun 2015 16:42:27 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mohamed Oulmahdi References: <5579768E.5060402@tik.ee.ethz.ch> <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> <5579971D.9040509@tik.ee.ethz.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: gorry@erg.abdn.ac.uk, Brian Trammell , taps@ietf.org Subject: Re: [Taps] TCP components 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, 11 Jun 2015 14:43:00 -0000 Hi Mohamed, see below. >>>> - Limited control over segment transmission scheduling (Nagle's >>>> algorithm): >>>> This allows for delay minimization in interactive applications. >>> >>> >>> GF: Not quite - To me, it prevents increased delay from the TCP protocol. >>> It doesn't really control anything to reduce delay. >> >> >> Yes, I think we wanted to say the same thing here; don't really see the difference... > > I don't understand this delay optimization. Is it thanks to Nagle's algorithm > or for the possibility of its deactivation? Because it's known that this > algorithm increase delay and so became unsuitable for delay-sensitive > applications... Yes, the delay is reduced if you deactivate it. The component is the fact that there is an algorithm that will influence when packets are sent (if data is available and the sending window is large enough). Mirja From nobody Tue Jun 16 16:59:38 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C081B2B75 for ; Tue, 16 Jun 2015 16:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fW1VRaKUo5f for ; Tue, 16 Jun 2015 16:59:36 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2DA1B2B84 for ; Tue, 16 Jun 2015 16:59:35 -0700 (PDT) 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 t5GNwN38002779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 Jun 2015 16:58:25 -0700 (PDT) Message-ID: <5580B81F.2050906@isi.edu> Date: Tue, 16 Jun 2015 16:58:23 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk, =?windows-1252?Q?Mirja_K=FChlewind?= References: <5579768E.5060402@tik.ee.ethz.ch> <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> In-Reply-To: <2e1ca6a7e239e671b7516431ad5db93c.squirrel@erg.abdn.ac.uk> 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: Cc: Brian Trammell , "taps@ietf.org" , touch@isi.edu Subject: Re: [Taps] TCP components 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 Jun 2015 23:59:37 -0000 On 6/11/2015 5:30 AM, gorry@erg.abdn.ac.uk wrote: ... >> - Port multiplexing, with application-to-port mapping during connection >> setup: > > GF: Thinking on this, is application-to-port mapping really a TCP > function? port-mapping is similar in other transports, and doesn't really > have any different support in TCP (contrast to the Service Code in DCCP) The assumption of app-to-port mapping is part of how assigned ports are, well, assigned. >> Note that in the presence of network address and port translation (NAPT), >> TCP >> ports are >> in effect part of the endpoint address for forwarding purposes. >> > GF: This is the case only for those middle boxes that do NAPT, > load-ballancing etc, saying they are part of the endpoint address is to me > confusing forwarding by middle boxes from forwarding by routers - I'd > prefer to be more careful here. Ports are part of the connection identifier, in conjunction with the endpoint address. The fact that NATs or any other devices remap, translate, or overload that function (i.e., using it for forwarding decisions) is not relevant to TCP's view of these values or to the service TCP provides, IMO. Joe From nobody Wed Jun 17 00:36:56 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB881A1B8D for ; Wed, 17 Jun 2015 00:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPFINVLtPO0d for ; Wed, 17 Jun 2015 00:36:54 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC051A1B86 for ; Wed, 17 Jun 2015 00:36:54 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z57u0-0006lh-S7; Wed, 17 Jun 2015 09:36:52 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z57u0-0005kQ-9H; Wed, 17 Jun 2015 09:36:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <5579768E.5060402@tik.ee.ethz.ch> Date: Wed, 17 Jun 2015 09:36:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 4 sum rcpts/h 12 sum msgs/h 4 total rcpts 30178 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: CAD2A846824F79523FCC9191B825BD0ACD08482D X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 7322 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 17 Jun 2015 07:36:55 -0000 Hi, > On 11 Jun 2015, at 13:52, Mirja K=C3=BChlewind = wrote: >=20 > Hi all, >=20 > we gave it a first try to rewrite the component section for TCP. The = insight I took from the discussion on the list is that components = probably are much more linked to the implementation (choices) a certain = protocol made while features are probably more high-level having the = question in mind what does an application potentially want/need to know. >=20 > So for the components in TCP we now have the following list: >=20 > - Connection-oriented bidirectional communication using three-way = handshake connection setup with > feature negotiation and an explicit distinction between passive = and active open: > This implies both unicast addressing and a guarantee of return = routability. > - Single stream-oriented transmission: > The stream abstraction atop the datagram service provided by IP = is implemented by dividing > the stream into segments. > - Limited control over segment transmission scheduling (Nagle's = algorithm): > This allows for delay minimization in interactive applications. > - Port multiplexing, with application-to-port mapping during = connection setup: > Note that in the presence of network address and port = translation (NAPT), TCP ports are > in effect part of the endpoint address for forwarding purposes. > - Full reliability based on ack-based loss detection and = retransmission: > Loss is sensed using duplicated acks ("fast retransmit"), which = places a lower bound on > the delay inherent in this approach to reliability. > - Error detection based on a checksum covering the network and = transport headers as well as payload: > Packets that are detected as corrupted are dropped, relying on = the reliability mechanism > to retransmit them. > - Window-based flow control, with receiver-side window management and = signaling of available window: > Scaling the flow control window beyond 64kB requires the use of = an optional feature, > which has performance implications in environments where this = option is not supported. > - Window-based congestion control reacting to loss, delay, = retransmission timeout, or > an explicit congestion signal (ECN): > Most commonly used is a loss signal from the reliability = component's retransmission mechanism. > TCP reacts to a congestion signal by reducing the size of the = congestion window; > retransmission timeout is generally handled with a larger = reaction than other signals. >=20 > We are currently still working on the list of features that results = from thiese components but we are not there yet. Probably we not only = need the features itself but also properties/aspects (or however you = want to call this) of the feature. We already had this discussion a bit = but wanted to postpone the decision if we really need to define an own = term for this until we are sure that we need it. >=20 > We are posting this list of (TCP) components now because we would like = to get some feedback if this goes into the right direction/is on the = right level of detail before we go on and apply this also to other = protocols. I agree that the list below is closer to what I think a "component" = should be ... but looking at it, is it not even clearer now that = components are not what TAPS is after? To me this list now contains lots = and lots of details that are irrelevant to the service provided to the = application. Not harmful to list but pretty useless?! And how do you draw the line for what goes in and out of such a list? = E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK are = not mentioned? To me, this whole thing is just too full of arbitrariness. We should aim = for a systematic approach that minimizes the number of arbitrary = decisions made IMO. Cheers, Michael From nobody Wed Jun 17 01:28:29 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C8E1A700B for ; Wed, 17 Jun 2015 01:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZWZ3gswJYnY5 for ; Wed, 17 Jun 2015 01:28:25 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C251A7003 for ; Wed, 17 Jun 2015 01:28:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 5C01DD9307; Wed, 17 Jun 2015 10:28:22 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1wO0bPgOzcMQ; Wed, 17 Jun 2015 10:28:22 +0200 (MEST) Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0F418D9302; Wed, 17 Jun 2015 10:28:22 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 17 Jun 2015 10:28:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> References: <5579768E.5060402@tik.ee.ethz.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 17 Jun 2015 08:28:28 -0000 Hi Michael, see below. > Am 17.06.2015 um 09:36 schrieb Michael Welzl : >=20 > Hi, >=20 >=20 >> On 11 Jun 2015, at 13:52, Mirja K=C3=BChlewind = wrote: >>=20 >> Hi all, >>=20 >> we gave it a first try to rewrite the component section for TCP. The = insight I took from the discussion on the list is that components = probably are much more linked to the implementation (choices) a certain = protocol made while features are probably more high-level having the = question in mind what does an application potentially want/need to know. >>=20 >> So for the components in TCP we now have the following list: >>=20 >> - Connection-oriented bidirectional communication using three-way = handshake connection setup with >> feature negotiation and an explicit distinction between passive = and active open: >> This implies both unicast addressing and a guarantee of return = routability. >> - Single stream-oriented transmission: >> The stream abstraction atop the datagram service provided by IP = is implemented by dividing >> the stream into segments. >> - Limited control over segment transmission scheduling (Nagle's = algorithm): >> This allows for delay minimization in interactive applications. >> - Port multiplexing, with application-to-port mapping during = connection setup: >> Note that in the presence of network address and port = translation (NAPT), TCP ports are >> in effect part of the endpoint address for forwarding purposes. >> - Full reliability based on ack-based loss detection and = retransmission: >> Loss is sensed using duplicated acks ("fast retransmit"), which = places a lower bound on >> the delay inherent in this approach to reliability. >> - Error detection based on a checksum covering the network and = transport headers as well as payload: >> Packets that are detected as corrupted are dropped, relying on = the reliability mechanism >> to retransmit them. >> - Window-based flow control, with receiver-side window management and = signaling of available window: >> Scaling the flow control window beyond 64kB requires the use of = an optional feature, >> which has performance implications in environments where this = option is not supported. >> - Window-based congestion control reacting to loss, delay, = retransmission timeout, or >> an explicit congestion signal (ECN): >> Most commonly used is a loss signal from the reliability = component's retransmission mechanism. >> TCP reacts to a congestion signal by reducing the size of the = congestion window; >> retransmission timeout is generally handled with a larger = reaction than other signals. >>=20 >> We are currently still working on the list of features that results = from thiese components but we are not there yet. Probably we not only = need the features itself but also properties/aspects (or however you = want to call this) of the feature. We already had this discussion a bit = but wanted to postpone the decision if we really need to define an own = term for this until we are sure that we need it. >>=20 >> We are posting this list of (TCP) components now because we would = like to get some feedback if this goes into the right direction/is on = the right level of detail before we go on and apply this also to other = protocols. >=20 > I agree that the list below is closer to what I think a "component" = should be ... but looking at it, is it not even clearer now that = components are not what TAPS is after? To me this list now contains lots = and lots of details that are irrelevant to the service provided to the = application. Not harmful to list but pretty useless?! In this case we decided to list/discuss rather some more details, so = that people can understand what we had in mind. We might remove some of = these details/explanations at the end (or move those parts that are = actually relevant into the feature section (4)). >=20 > And how do you draw the line for what goes in and out of such a list? = E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK are = not mentioned? We tried to ask ourself which parts have an effect on the behavior of = the flow that could potentially be of interest for the application. We = might have missed some points. Actually Gorry already point out some. The next step is to work on the feature list and figure out how these = things that are interesting for the application would be described in a = more general way (independent of the concrete algorithm that is used by = one protocol) and also discuss which features actually should be exposed = because they have a real use for the application. >=20 > To me, this whole thing is just too full of arbitrariness. We should = aim for a systematic approach that minimizes the number of arbitrary = decisions made IMO. For us the systematic approach is to look at the implementation of = existing protocol an figure out which algorithm have an influence on the = traffic that might be interest for a higher layer to control. So we = always had, to some extend, the application in mind. However, you could = go for a even more generic approach and only look at the implementation = and as a first step figure where are any knobs that in principle could = be configurable and then afterwards discuss all of these very specific = knobs. I though about this approach and think it would be an interest = exercise and potentially the right way to go. But I also think that the = overhead would be super large and I don=E2=80=99t think it would give us = much more than we have right now. So we the current approach we might = need to expect some arbitrariness=E2=80=A6 Mirja >=20 > Cheers, > Michael From nobody Wed Jun 17 01:45:06 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505451A00DC for ; Wed, 17 Jun 2015 01:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1loZfkAD_A_d for ; Wed, 17 Jun 2015 01:45:03 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C921A0211 for ; Wed, 17 Jun 2015 01:45:02 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z58xx-0002uQ-ER; Wed, 17 Jun 2015 10:45:01 +0200 Received: from 1x-193-157-197-115.uio.no ([193.157.197.115]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Z58xw-0001cj-Ew; Wed, 17 Jun 2015 10:45:01 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> Date: Wed, 17 Jun 2015 10:44:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> To: =?windows-1252?Q?Mirja_K=FChlewind?= X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 10 sum msgs/h 4 total rcpts 30183 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.05, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6EE7CD706D8827D57D1E7D402AA1E4BD036E9047 X-UiO-SPAM-Test: remote_host: 193.157.197.115 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 82 max/h 8 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 17 Jun 2015 08:45:05 -0000 On Jun 17, 2015, at 10:28 AM, Mirja K=FChlewind = wrote: > Hi Michael, >=20 > see below. >=20 >> Am 17.06.2015 um 09:36 schrieb Michael Welzl : >>=20 >> Hi, >>=20 >>=20 >>> On 11 Jun 2015, at 13:52, Mirja K=FChlewind = wrote: >>>=20 >>> Hi all, >>>=20 >>> we gave it a first try to rewrite the component section for TCP. The = insight I took from the discussion on the list is that components = probably are much more linked to the implementation (choices) a certain = protocol made while features are probably more high-level having the = question in mind what does an application potentially want/need to know. >>>=20 >>> So for the components in TCP we now have the following list: >>>=20 >>> - Connection-oriented bidirectional communication using three-way = handshake connection setup with >>> feature negotiation and an explicit distinction between passive = and active open: >>> This implies both unicast addressing and a guarantee of return = routability. >>> - Single stream-oriented transmission: >>> The stream abstraction atop the datagram service provided by IP = is implemented by dividing >>> the stream into segments. >>> - Limited control over segment transmission scheduling (Nagle's = algorithm): >>> This allows for delay minimization in interactive applications. >>> - Port multiplexing, with application-to-port mapping during = connection setup: >>> Note that in the presence of network address and port = translation (NAPT), TCP ports are >>> in effect part of the endpoint address for forwarding purposes. >>> - Full reliability based on ack-based loss detection and = retransmission: >>> Loss is sensed using duplicated acks ("fast retransmit"), which = places a lower bound on >>> the delay inherent in this approach to reliability. >>> - Error detection based on a checksum covering the network and = transport headers as well as payload: >>> Packets that are detected as corrupted are dropped, relying on = the reliability mechanism >>> to retransmit them. >>> - Window-based flow control, with receiver-side window management = and signaling of available window: >>> Scaling the flow control window beyond 64kB requires the use of = an optional feature, >>> which has performance implications in environments where this = option is not supported. >>> - Window-based congestion control reacting to loss, delay, = retransmission timeout, or >>> an explicit congestion signal (ECN): >>> Most commonly used is a loss signal from the reliability = component's retransmission mechanism. >>> TCP reacts to a congestion signal by reducing the size of the = congestion window; >>> retransmission timeout is generally handled with a larger = reaction than other signals. >>>=20 >>> We are currently still working on the list of features that results = from thiese components but we are not there yet. Probably we not only = need the features itself but also properties/aspects (or however you = want to call this) of the feature. We already had this discussion a bit = but wanted to postpone the decision if we really need to define an own = term for this until we are sure that we need it. >>>=20 >>> We are posting this list of (TCP) components now because we would = like to get some feedback if this goes into the right direction/is on = the right level of detail before we go on and apply this also to other = protocols. >>=20 >> I agree that the list below is closer to what I think a "component" = should be ... but looking at it, is it not even clearer now that = components are not what TAPS is after? To me this list now contains lots = and lots of details that are irrelevant to the service provided to the = application. Not harmful to list but pretty useless?! >=20 > In this case we decided to list/discuss rather some more details, so = that people can understand what we had in mind. We might remove some of = these details/explanations at the end (or move those parts that are = actually relevant into the feature section (4)). >=20 >>=20 >> And how do you draw the line for what goes in and out of such a list? = E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK are = not mentioned? >=20 > We tried to ask ourself which parts have an effect on the behavior of = the flow that could potentially be of interest for the application. We = might have missed some points. Actually Gorry already point out some. Okay; btw just to be clear, I didn't mean that FACK etc. should be in = the list - on the contrary! My point was really about "how do you draw = the line", which you answered in the first sentence here. > The next step is to work on the feature list and figure out how these = things that are interesting for the application would be described in a = more general way (independent of the concrete algorithm that is used by = one protocol) and also discuss which features actually should be exposed = because they have a real use for the application. >=20 >>=20 >> To me, this whole thing is just too full of arbitrariness. We should = aim for a systematic approach that minimizes the number of arbitrary = decisions made IMO. >=20 > For us the systematic approach is to look at the implementation of = existing protocol an figure out which algorithm have an influence on the = traffic that might be interest for a higher layer to control. So we = always had, to some extend, the application in mind. Okay, I understand. Thanks for clarifying! > However, you could go for a even more generic approach and only look = at the implementation and as a first step figure where are any knobs = that in principle could be configurable and then afterwards discuss all = of these very specific knobs. I though about this approach and think it = would be an interest exercise and potentially the right way to go. But I = also think that the overhead would be super large and I don=92t think it = would give us much more than we have right now. So we the current = approach we might need to expect some arbitrariness=85 I lean towards this other one, of beginning with the knobs, but not with = the implementation but rather the "abstract API" as Joe called it: the = interface to the app as defined in the RFCs (for where it really *is* = defined). I think that this discussion with Joe maybe suffered from focusing on = TCP. SCTP is perhaps a better starting point because it supports almost = everything. So I'm thinking that a different (and, to me, perhaps more = appropriate and more systematic) method to get a list of features could = be to start with the read / write options in RFC 6458, extend it with = all such options from the other protocols, and then, protocol by = protocol, ask: "what does this protocol provide that the list now = doesn't contain?". Not sure the overhead of this approach would be super = large? But I agree, you may end up with the same list the way you do it = now. Cheers, Michael From nobody Wed Jun 17 03:13:47 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40C31A889C for ; Wed, 17 Jun 2015 03:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rQsT4dQCmie for ; Wed, 17 Jun 2015 03:13:42 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id AE4B51A8870 for ; Wed, 17 Jun 2015 03:13:41 -0700 (PDT) Received: from nb-10604.ethz.ch (nb-10604.ethz.ch [82.130.102.91]) by trammell.ch (Postfix) with ESMTPSA id 6FC7E1A0206; Wed, 17 Jun 2015 12:13:40 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_3C832BA8-461E-450A-985E-1FAB3E233409"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> Date: Wed, 17 Jun 2015 12:13:40 +0200 Message-Id: <8377C788-96BC-4F70-ADDD-B3E07AC814A0@trammell.ch> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 17 Jun 2015 10:13:45 -0000 --Apple-Mail=_3C832BA8-461E-450A-985E-1FAB3E233409 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Michael, all, A couple of random points inline at various levels of quotation... > On 17 Jun 2015, at 10:44, Michael Welzl wrote: >=20 >=20 > On Jun 17, 2015, at 10:28 AM, Mirja K=FChlewind = wrote: >=20 >> Hi Michael, >>=20 >> see below. >>=20 >>> Am 17.06.2015 um 09:36 schrieb Michael Welzl : >>>=20 >>> Hi, >>>=20 >>>=20 >>>> On 11 Jun 2015, at 13:52, Mirja K=FChlewind = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> we gave it a first try to rewrite the component section for TCP. = The insight I took from the discussion on the list is that components = probably are much more linked to the implementation (choices) a certain = protocol made while features are probably more high-level having the = question in mind what does an application potentially want/need to know. >>>>=20 >>>> So for the components in TCP we now have the following list: >>>>=20 >>>> - Connection-oriented bidirectional communication using three-way = handshake connection setup with >>>> feature negotiation and an explicit distinction between passive = and active open: >>>> This implies both unicast addressing and a guarantee of return = routability. >>>> - Single stream-oriented transmission: >>>> The stream abstraction atop the datagram service provided by IP = is implemented by dividing >>>> the stream into segments. >>>> - Limited control over segment transmission scheduling (Nagle's = algorithm): >>>> This allows for delay minimization in interactive applications. >>>> - Port multiplexing, with application-to-port mapping during = connection setup: >>>> Note that in the presence of network address and port = translation (NAPT), TCP ports are >>>> in effect part of the endpoint address for forwarding purposes. >>>> - Full reliability based on ack-based loss detection and = retransmission: >>>> Loss is sensed using duplicated acks ("fast retransmit"), which = places a lower bound on >>>> the delay inherent in this approach to reliability. >>>> - Error detection based on a checksum covering the network and = transport headers as well as payload: >>>> Packets that are detected as corrupted are dropped, relying on = the reliability mechanism >>>> to retransmit them. >>>> - Window-based flow control, with receiver-side window management = and signaling of available window: >>>> Scaling the flow control window beyond 64kB requires the use of = an optional feature, >>>> which has performance implications in environments where this = option is not supported. >>>> - Window-based congestion control reacting to loss, delay, = retransmission timeout, or >>>> an explicit congestion signal (ECN): >>>> Most commonly used is a loss signal from the reliability = component's retransmission mechanism. >>>> TCP reacts to a congestion signal by reducing the size of the = congestion window; >>>> retransmission timeout is generally handled with a larger = reaction than other signals. >>>>=20 >>>> We are currently still working on the list of features that results = from thiese components but we are not there yet. Probably we not only = need the features itself but also properties/aspects (or however you = want to call this) of the feature. We already had this discussion a bit = but wanted to postpone the decision if we really need to define an own = term for this until we are sure that we need it. >>>>=20 >>>> We are posting this list of (TCP) components now because we would = like to get some feedback if this goes into the right direction/is on = the right level of detail before we go on and apply this also to other = protocols. >>>=20 >>> I agree that the list below is closer to what I think a "component" = should be ... but looking at it, is it not even clearer now that = components are not what TAPS is after? To me this list now contains lots = and lots of details that are irrelevant to the service provided to the = application. That's part of the point we're trying to address here. The realization = we had here is that components *don't* necessarily map to feature, and = it's not clear that we can simply ignore those components that don't = map, since they may have impact on the interfaces/features it is = possible to (reasonably) implement atop those protocols. >>> Not harmful to list but pretty useless?! Let's start with TCP as probably the most difficult example (indeed, = that's why we worked out this "new" arrangement of components for TCP = first). A completely clean and unambiguous decomposition of TCP into its = features -- what, I agree, we're after in the end -- is not *really* = possible, because the protocols as defined and implemented weren't = really composed of discrete features. The evolution of loss-based = congestion control, for instance, was predicated on the particular loss = signals that were available at the time it was first defined. The error = detection mechanism likewise relies on the fact that reliability is = provided by retransmission. One could say that given the parallel = evolution of computing power that all these choices made by TCP were the = only obvious ones at the time. But it's precisely the co-evolution of = reliability and congestion control that makes gluing FEC to TCP so = fraught with peril. That's an important point to capture IMO. I expect that the same exercise for SCTP will show a simpler mapping = between components and features, since it *was* designed as a = composition of features. >> In this case we decided to list/discuss rather some more details, so = that people can understand what we had in mind. We might remove some of = these details/explanations at the end (or move those parts that are = actually relevant into the feature section (4)). >>=20 >>>=20 >>> And how do you draw the line for what goes in and out of such a = list? E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK = are not mentioned? >>=20 >> We tried to ask ourself which parts have an effect on the behavior of = the flow that could potentially be of interest for the application. We = might have missed some points. Actually Gorry already point out some. >=20 > Okay; btw just to be clear, I didn't mean that FACK etc. should be in = the list - on the contrary! My point was really about "how do you draw = the line", which you answered in the first sentence here. >=20 >=20 >> The next step is to work on the feature list and figure out how these = things that are interesting for the application would be described in a = more general way (independent of the concrete algorithm that is used by = one protocol) and also discuss which features actually should be exposed = because they have a real use for the application. >>=20 >>>=20 >>> To me, this whole thing is just too full of arbitrariness. We should = aim for a systematic approach that minimizes the number of arbitrary = decisions made IMO. >>=20 >> For us the systematic approach is to look at the implementation of = existing protocol an figure out which algorithm have an influence on the = traffic that might be interest for a higher layer to control. So we = always had, to some extend, the application in mind. >=20 > Okay, I understand. Thanks for clarifying! >=20 >=20 >> However, you could go for a even more generic approach and only look = at the implementation and as a first step figure where are any knobs = that in principle could be configurable and then afterwards discuss all = of these very specific knobs. I though about this approach and think it = would be an interest exercise and potentially the right way to go. But I = also think that the overhead would be super large and I don=92t think it = would give us much more than we have right now. So we the current = approach we might need to expect some arbitrariness=85 >=20 > I lean towards this other one, of beginning with the knobs, ... understanding that interface definitions aren't just about which = knobs (and indicators) the API provides, but also the interaction = patterns it enables, and that these interaction patterns can also be = made inefficient or even impractical by the details of the protocol in = question. (It's always *possible* to implement object transfer over = streams, or time domain transfer over objects, or to translate = asynchonous events into a synchronous API. That the Web and video = thereon "work" is proof of that. You can run the whole Internet over = DNS, if you want to. It would not work as well as the one we have today. = :) ) > but not with the implementation but rather the "abstract API" as Joe = called it: the interface to the app as defined in the RFCs (for where it = really *is* defined). >=20 > I think that this discussion with Joe maybe suffered from focusing on = TCP. SCTP is perhaps a better starting point because it supports almost = everything. We can certainly do SCTP next, which should make the exercise look less = arbitrary. (FWIW I don't think we can *eliminate* arbitrary decisions in = classification and where to cut the line between components, or to = determine which components are worth talking about. But minimizing them = is a good goal. :) ) > So I'm thinking that a different (and, to me, perhaps more appropriate = and more systematic) method to get a list of features could be to start = with the read / write options in RFC 6458, extend it with all such = options from the other protocols, and then, protocol by protocol, ask: = "what does this protocol provide that the list now doesn't contain?". = Not sure the overhead of this approach would be super large? But I = agree, you may end up with the same list the way you do it now. Again, that captures knobs and indicators, less so interaction patterns. = (I will say I'm not 100% convinced the interaction patterns are = important to capture for the individual protocols, but paying attention = to them will be *crucial* to making sure that TAPS-the-system sees = uptake among application and platform developers) Cheers, Brian --Apple-Mail=_3C832BA8-461E-450A-985E-1FAB3E233409 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 iQEcBAEBCgAGBQJVgUhUAAoJENt3nsOmbNJcsOkH/1Eb+ReSpD6X6tx8832FWVsb h1UJCAEvVc7sQoWkRhuysNKe66TCxGXGoNi/yeJZm4Fsh0FL//79xK6RSjJwDNCV HsTFPqYWHCx+cve1nzfeX7gLBaBVQEIZq8SSeZ3pwbDIgZV4LZJq86uRmIlNjoBO l++sSgP7XPK5RTDgfNfkziubn7vm9hsVjrHG7LOAaPI7PQC7atg6q7TMSZXvBVD4 9BfQVxrqJsEPp6OtXcX7l3KNAlNZtMUwCo+uRrMLU3LHX0Ctf6ogqem94GGNT5NT JFU27JHxSwNtPwNgaG7Uf8BtfpcCtDhY15AoHXZArOwsCWcrZqXQHknjx8aa13s= =OpRq -----END PGP SIGNATURE----- --Apple-Mail=_3C832BA8-461E-450A-985E-1FAB3E233409-- From nobody Wed Jun 17 08:42:33 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A621ACEAE for ; Wed, 17 Jun 2015 08:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, 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 ktnmh-pKdebP for ; Wed, 17 Jun 2015 08:42:29 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232911A90A8 for ; Wed, 17 Jun 2015 08:42:29 -0700 (PDT) Received: by igblz2 with SMTP id lz2so39709653igb.1 for ; Wed, 17 Jun 2015 08:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=s3Kh3eTcJ5g274nhafOkZKhPxFUFYUpyKHkC9EL0Woo=; b=QfkJzZuS2HA+oKZe9pTiKGj/UVp4lfLto99IKygWUH26OwUoTL4j95os2bBUMNnv6S GyLWjQy5g2P94YIqilzN+/YIUQBHnxZGQ1iZIQ9zH2SjpqrXY3qlL4NnFLSlLL/Rpzkl x3PiQuDuT/wPKr2d/ohcr8p97Tny86D2v14Hq+Lp0vM8xLYH7npcfYUC3ZEiBRVpV2su /i8sUThb7RVA488IV3EjCUX0OplSU48qyrNDzQQTQWfpra+ORCYC6k2tcSQcpZsuy7Gk /HkVfd1LPhxRsau4Y8k7r+o7h+J/fZgGXqB2lYsy7kG7mcm8dVjdRGtONp3S59mLfoHT L4Pg== MIME-Version: 1.0 X-Received: by 10.107.32.73 with SMTP id g70mr9098377iog.23.1434555748629; Wed, 17 Jun 2015 08:42:28 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.79.68.66 with HTTP; Wed, 17 Jun 2015 08:42:28 -0700 (PDT) In-Reply-To: <5579768E.5060402@tik.ee.ethz.ch> References: <5579768E.5060402@tik.ee.ethz.ch> Date: Wed, 17 Jun 2015 11:42:28 -0400 X-Google-Sender-Auth: CCaAcFdL7BOsffNpaCFBGamFfS0 Message-ID: From: Erik Nygren To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a11404078ceefca0518b88917 Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 17 Jun 2015 15:42:32 -0000 --001a11404078ceefca0518b88917 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Another major item to add to the list would be: - MTU/MSS negotiation and management, including initial negotiation, response to packet-too-big signals from middle-boxes, and optional probing. To what degree is it worth talking about known design limitations and issues associated with each? For example, checksums in TCP not being large enough to detect errors in many high-volume real-world scenarios? Erik On Jun 11, 2015 7:53 AM, "Mirja K=C3=BChlewind" wrote: > Hi all, > > we gave it a first try to rewrite the component section for TCP. The > insight I took from the discussion on the list is that components probabl= y > are much more linked to the implementation (choices) a certain protocol > made while features are probably more high-level having the question in > mind what does an application potentially want/need to know. > > So for the components in TCP we now have the following list: > > - Connection-oriented bidirectional communication using three-way > handshake connection setup with > feature negotiation and an explicit distinction between passive > and active open: > This implies both unicast addressing and a guarantee of return > routability. > - Single stream-oriented transmission: > The stream abstraction atop the datagram service provided by IP i= s > implemented by dividing > the stream into segments. > - Limited control over segment transmission scheduling (Nagle's algorithm= ): > This allows for delay minimization in interactive applications. > - Port multiplexing, with application-to-port mapping during connection > setup: > Note that in the presence of network address and port translation > (NAPT), TCP ports are > in effect part of the endpoint address for forwarding purposes. > - Full reliability based on ack-based loss detection and retransmission: > Loss is sensed using duplicated acks ("fast retransmit"), which > places a lower bound on > the delay inherent in this approach to reliability. > - Error detection based on a checksum covering the network and transport > headers as well as payload: > Packets that are detected as corrupted are dropped, relying on th= e > reliability mechanism > to retransmit them. > - Window-based flow control, with receiver-side window management and > signaling of available window: > Scaling the flow control window beyond 64kB requires the use of a= n > optional feature, > which has performance implications in environments where this > option is not supported. > - Window-based congestion control reacting to loss, delay, retransmission > timeout, or > an explicit congestion signal (ECN): > Most commonly used is a loss signal from the reliability > component's retransmission mechanism. > TCP reacts to a congestion signal by reducing the size of the > congestion window; > retransmission timeout is generally handled with a larger reactio= n > than other signals. > > We are currently still working on the list of features that results from > thiese components but we are not there yet. Probably we not only need the > features itself but also properties/aspects (or however you want to call > this) of the feature. We already had this discussion a bit but wanted to > postpone the decision if we really need to define an own term for this > until we are sure that we need it. > > We are posting this list of (TCP) components now because we would like to > get some feedback if this goes into the right direction/is on the right > level of detail before we go on and apply this also to other protocols. > > Brian and Mirja > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a11404078ceefca0518b88917 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Another major item to add to the list would be:

-= MTU/MSS negotiation and management, including initial negotiation, respons= e to packet-too-big signals from middle-boxes, and optional probing.

= To what degree is it worth talking about known design limitations and issue= s associated with each?=C2=A0 For example, checksums in TCP not being large= enough to detect errors in many high-volume real-world scenarios?

E= rik


On Jun 11, 2015 7:53 AM, &qu= ot;Mirja K=C3=BChlewind" <mirja.kuehlewind@tik.ee.ethz.ch> wrote:<= br type=3D"attribution">
Hi all,

we gave it a first try to rewrite the component section for TCP. The insigh= t I took from the discussion on the list is that components probably are mu= ch more linked to the implementation (choices) a certain protocol made whil= e features are probably more high-level having the question in mind what do= es an application potentially want/need to know.

So for the components in TCP we now have the following list:

- Connection-oriented bidirectional communication using three-way handshake= connection setup with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 feature negotiation and an explicit distinction= between passive and active open:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This implies both unicast addressing and a guar= antee of return routability.
- Single stream-oriented transmission:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The stream abstraction atop the datagram servic= e provided by IP is implemented by dividing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the stream into segments.
- Limited control over segment transmission scheduling (Nagle's algorit= hm):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This allows for delay minimization in interacti= ve applications.
- Port multiplexing, with application-to-port mapping during connection set= up:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Note that in the presence of network address an= d port translation (NAPT), TCP ports are
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in effect part of the endpoint address for forw= arding purposes.
- Full reliability based on ack-based loss detection and retransmission: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Loss is sensed using duplicated acks ("fas= t retransmit"), which places a lower bound on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the delay inherent in this approach to reliabil= ity.
- Error detection based on a checksum covering the network and transport he= aders as well as payload:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Packets that are detected as corrupted are drop= ped, relying on the reliability mechanism
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to retransmit them.
- Window-based flow control, with receiver-side window management and signa= ling of available window:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Scaling the flow control window beyond 64kB req= uires the use of an optional feature,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 which has performance implications in environme= nts where this option is not supported.
- Window-based congestion control reacting to loss, delay, retransmission t= imeout, or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 an explicit congestion signal (ECN):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Most commonly used is a loss signal from the re= liability component's retransmission mechanism.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP reacts to a congestion signal by reducing t= he size of the congestion window;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 retransmission timeout is generally handled wit= h a larger reaction than other signals.

We are currently still working on the list of features that results from th= iese components but we are not there yet. Probably we not only need the fea= tures itself but also properties/aspects (or however you want to call this)= of the feature. We already had this discussion a bit but wanted to postpon= e the decision if we really need to define an own term for this until we ar= e sure that we need it.

We are posting this list of (TCP) components now because we would like to g= et some feedback if this goes into the right direction/is on the right leve= l of detail before we go on and apply this also to other protocols.

Brian and Mirja



_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--001a11404078ceefca0518b88917-- From nobody Wed Jun 17 11:11:15 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245721B2C93 for ; Wed, 17 Jun 2015 11:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Vla5-asRlaj for ; Wed, 17 Jun 2015 11:11:13 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E6E1B2CA0 for ; Wed, 17 Jun 2015 11:11:10 -0700 (PDT) Received: from [128.9.160.252] (pen.isi.edu [128.9.160.252]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t5HIAaw2000145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Jun 2015 11:10:36 -0700 (PDT) Message-ID: <5581B81B.4090500@isi.edu> Date: Wed, 17 Jun 2015 11:10:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl , =?windows-1252?Q?Mirja_K=FChlew?= =?windows-1252?Q?ind?= References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> In-Reply-To: <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: t5HIAaw2000145 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , "taps@ietf.org" , touch@isi.edu Subject: Re: [Taps] TCP components 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, 17 Jun 2015 18:11:14 -0000 On 6/17/2015 1:44 AM, Michael Welzl wrote: > I think that this discussion with Joe maybe suffered from focusing on > TCP. To be fair, TCP has a simpler abstract API. > SCTP is perhaps a better starting point because it supports > almost everything. IMO, that makes it very hard as a starting point, and I also think that TCP's variant of an API description is much better as an example. E.g., Section 10 of RFC4960 claims it defines an abstract API (ULP-to_SCTP), but it begins by describing a call to initialize a data structure (INITIALIZE). That's decidedly NOT an abstract API; it's a generic description of an implementation issue. IMO, if we don't understand the difference between the API in RFC793 vs. that in RFC4960 (and why 793 is a better example), then this is going to be a very bumpy road. Joe From nobody Wed Jun 17 11:33:13 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A871A0469 for ; Wed, 17 Jun 2015 11:33:13 -0700 (PDT) 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 2nrrKOdG-tgU for ; Wed, 17 Jun 2015 11:33:11 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99D61A00B1 for ; Wed, 17 Jun 2015 11:33:11 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so43476734igb.0 for ; Wed, 17 Jun 2015 11:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rzIncgH1ESRsHm+CYR1/2SIv/RK7tI8w9kfr/FGhs+s=; b=kGhbyt7G+xVC3SKhyRdVQpsvlaYMC2X4x1tC0x/FXkx+ygCLOu8K+uAxMUL1jBJq6J aru+xeskBrWXdSTZPyur64zcwwve1snjbpSAwbUeBGveydjza2YKRC6UmWXffcshTSEl 210QOzKfmdm5Mi2xF+G6IyBTsisP/zJJMcTQ2t4jXRV0FOP0xCaT69MDReXq6UnaQ58r tE+KfXWPJnJoUzY+zDqDqMSF/wMr4Y/wQTBEERWE1r4XKJ16aowiSN14wT1FylZ10kFi jY2BACI3gXspvS15HxGCPGfqpnlFuFuhJomssNW5wvBSpzufL9yK3nUcjGk9KOBbVq+z qUHw== MIME-Version: 1.0 X-Received: by 10.107.7.66 with SMTP id 63mr10001820ioh.28.1434565991182; Wed, 17 Jun 2015 11:33:11 -0700 (PDT) Received: by 10.64.59.225 with HTTP; Wed, 17 Jun 2015 11:33:11 -0700 (PDT) In-Reply-To: <5581B81B.4090500@isi.edu> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> Date: Wed, 17 Jun 2015 14:33:11 -0400 Message-ID: From: Aaron Falk To: Joe Touch Content-Type: multipart/alternative; boundary=001a113f8f2a4fb7ed0518baecfb Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] TCP components 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, 17 Jun 2015 18:33:13 -0000 --001a113f8f2a4fb7ed0518baecfb Content-Type: text/plain; charset=UTF-8 Some suggested homework for the group: if you haven't done so recently, read section 3.8 of RFC793. (It's only 8 pages.) --aaron On Wed, Jun 17, 2015 at 2:10 PM, Joe Touch wrote: > > IMO, if we don't understand the difference between the API in RFC793 vs. > that in RFC4960 (and why 793 is a better example), then this is going to > be a very bumpy road. > --001a113f8f2a4fb7ed0518baecfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some= suggested homework for the group: if you haven't done so recently, rea= d section 3.8 of RFC793. =C2=A0(It's only 8 pages.)

--aaron


On Wed, Jun 17, 2015 at 2:10 PM, Joe Touch <touch@isi.edu= > wrote:

IMO, if we don't understand the difference between the API in RFC793 vs= .
that in RFC4960 (and why 793 is a better example), then this is going to be a very bumpy road.


=C2=A0
--001a113f8f2a4fb7ed0518baecfb-- From nobody Thu Jun 18 01:48:19 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD4D1A00F1 for ; Thu, 18 Jun 2015 01:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4XbZVH0wuPU for ; Thu, 18 Jun 2015 01:48:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF991A2130 for ; Thu, 18 Jun 2015 01:48:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 0B472D9315; Thu, 18 Jun 2015 10:48:12 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id NpeitZu-GorQ; Thu, 18 Jun 2015 10:48:11 +0200 (MEST) Received: from [192.168.178.33] (x5f700897.dyn.telefonica.de [95.112.8.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 7BB93D9310; Thu, 18 Jun 2015 10:48:11 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <5581B81B.4090500@isi.edu> Date: Thu, 18 Jun 2015 10:48:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] TCP components 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 Jun 2015 08:48:17 -0000 Hi Joe, I believe the approach Michael is proposing is to look at existing APIs = as a starting point; not only abstract APIs. The assumption is that = someone who implemented/designed an API, thought that it would be worth = to provide a configuration possibility to the higher layer. This = assumption is more true for SCTP than for TCP because there are quite a = few different TCP implementation that are grown over time. Quite often a = new interface was only created because a new feature was added to TCP; = and to be on the safe side we allow the user to turn it off again. That=E2=80=99s the reason why I prefer the approach we are/I'm taking = right now (analyzing components). I think we should still describe the = abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in = this document, but I personally would not and will not spend too much = time analyzing other API. However, everybody who has time and is = interested in this can of course provide his/her outcome as input for = this document and we will happily take it and compare it to what we have = so far. Mirja > Am 17.06.2015 um 20:10 schrieb Joe Touch : >=20 >=20 >=20 > On 6/17/2015 1:44 AM, Michael Welzl wrote: >> I think that this discussion with Joe maybe suffered from focusing on >> TCP.=20 >=20 > To be fair, TCP has a simpler abstract API. >=20 >> SCTP is perhaps a better starting point because it supports >> almost everything.=20 >=20 > IMO, that makes it very hard as a starting point, and I also think = that > TCP's variant of an API description is much better as an example. >=20 > E.g., Section 10 of RFC4960 claims it defines an abstract API > (ULP-to_SCTP), but it begins by describing a call to initialize a data > structure (INITIALIZE). That's decidedly NOT an abstract API; it's a > generic description of an implementation issue. >=20 > IMO, if we don't understand the difference between the API in RFC793 = vs. > that in RFC4960 (and why 793 is a better example), then this is going = to > be a very bumpy road. >=20 > Joe >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 18 06:44:06 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A12E1B31C8 for ; Thu, 18 Jun 2015 06:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H7xSCncxvvK for ; Thu, 18 Jun 2015 06:44:03 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B9B1B31C7 for ; Thu, 18 Jun 2015 06:44:02 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z5a6e-0007BT-81; Thu, 18 Jun 2015 15:43:48 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z5a6d-0001lb-Nx; Thu, 18 Jun 2015 15:43:48 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> Date: Thu, 18 Jun 2015 15:43:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 7 sum msgs/h 4 total rcpts 30220 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 74F6EA01134BA958F0AD1E81D283024816026866 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7335 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 13:44:05 -0000 > On 18 Jun 2015, at 10:48, Mirja K=C3=BChlewind = wrote: >=20 > Hi Joe, >=20 > I believe the approach Michael is proposing is to look at existing = APIs as a starting point; not only abstract APIs. No, wrong. Only abstract ones from RFCs, I said this before. These = things would typically have preceding IETF debate, whereas trying to = cover implementations is a huge and probably meaningless endeavour (the = bar may be high for adding function calls to an API on system X and low = for an API on system Y). > The assumption is that someone who implemented/designed an API, = thought that it would be worth to provide a configuration possibility to = the higher layer. This assumption is more true for SCTP than for TCP = because there are quite a few different TCP implementation that are = grown over time. Quite often a new interface was only created because a = new feature was added to TCP; and to be on the safe side we allow the = user to turn it off again. >=20 > That=E2=80=99s the reason why I prefer the approach we are/I'm taking = right now (analyzing components). I think we should still describe the = abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in = this document, but I personally would not and will not spend too much = time analyzing other API. However, everybody who has time and is = interested in this can of course provide his/her outcome as input for = this document and we will happily take it and compare it to what we have = so far. But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), = not implementations out there. More below, answering Joe (hm, that rhymes ;-) ) - >=20 > Mirja >=20 >=20 >> Am 17.06.2015 um 20:10 schrieb Joe Touch : >>=20 >>=20 >>=20 >> On 6/17/2015 1:44 AM, Michael Welzl wrote: >>> I think that this discussion with Joe maybe suffered from focusing = on >>> TCP.=20 >>=20 >> To be fair, TCP has a simpler abstract API. >>=20 >>> SCTP is perhaps a better starting point because it supports >>> almost everything.=20 >>=20 >> IMO, that makes it very hard as a starting point, and I also think = that >> TCP's variant of an API description is much better as an example. >>=20 >> E.g., Section 10 of RFC4960 claims it defines an abstract API >> (ULP-to_SCTP), but it begins by describing a call to initialize a = data >> structure (INITIALIZE). That's decidedly NOT an abstract API; it's a >> generic description of an implementation issue. >>=20 >> IMO, if we don't understand the difference between the API in RFC793 = vs. >> that in RFC4960 (and why 793 is a better example), then this is going = to >> be a very bumpy road. How abstract it is in the RFC indeed isn't my main concern here: it's to = start with the interface (however abstract it is) offered to = applications as described in the RFCs, as this reflects what the = designers (with some level of IETF consensus) thought should be exposed. Now, of course SCTP has more options and is more complex in its usage = than TCP, but it covers a larger part of the space of services in = protocols - so I thought it's a good starting point, as in: 80% done by = looking at 1 protocol, check the others for the remaining 20%. Something = like that. This is just me being pragmatic and trying to have a more systematic = approach to developing a list of services. I agree with Brian that some = level of arbitrariness will always be there, but we must try to minimize = it I think. Cheers, Michael From nobody Thu Jun 18 06:54:30 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F0B1B31DC for ; Thu, 18 Jun 2015 06:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pthI70sfYckC for ; Thu, 18 Jun 2015 06:54:26 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233791B31DA for ; Thu, 18 Jun 2015 06:54:26 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z5aGt-00020e-Dt; Thu, 18 Jun 2015 15:54:23 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z5aGs-0000gT-EG; Thu, 18 Jun 2015 15:54:23 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <8377C788-96BC-4F70-ADDD-B3E07AC814A0@trammell.ch> Date: Thu, 18 Jun 2015 15:54:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <8377C788-96BC-4F70-ADDD-B3E07AC814A0@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 3 sum rcpts/h 10 sum msgs/h 5 total rcpts 30223 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5174C176406FCD766359416DE94DB06C32DBFB6B X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 7336 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: =?windows-1252?Q?Mirja_K=FChlewind?= , "taps@ietf.org" Subject: Re: [Taps] TCP components 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 Jun 2015 13:54:29 -0000 > On 17 Jun 2015, at 12:13, Brian Trammell wrote: >=20 > hi Michael, all, >=20 > A couple of random points inline at various levels of quotation... >=20 >> On 17 Jun 2015, at 10:44, Michael Welzl wrote: >>=20 >>=20 >> On Jun 17, 2015, at 10:28 AM, Mirja K=FChlewind = wrote: >>=20 >>> Hi Michael, >>>=20 >>> see below. >>>=20 >>>> Am 17.06.2015 um 09:36 schrieb Michael Welzl : >>>>=20 >>>> Hi, >>>>=20 >>>>=20 >>>>> On 11 Jun 2015, at 13:52, Mirja K=FChlewind = wrote: >>>>>=20 >>>>> Hi all, >>>>>=20 >>>>> we gave it a first try to rewrite the component section for TCP. = The insight I took from the discussion on the list is that components = probably are much more linked to the implementation (choices) a certain = protocol made while features are probably more high-level having the = question in mind what does an application potentially want/need to know. >>>>>=20 >>>>> So for the components in TCP we now have the following list: >>>>>=20 >>>>> - Connection-oriented bidirectional communication using three-way = handshake connection setup with >>>>> feature negotiation and an explicit distinction between passive = and active open: >>>>> This implies both unicast addressing and a guarantee of return = routability. >>>>> - Single stream-oriented transmission: >>>>> The stream abstraction atop the datagram service provided by IP = is implemented by dividing >>>>> the stream into segments. >>>>> - Limited control over segment transmission scheduling (Nagle's = algorithm): >>>>> This allows for delay minimization in interactive applications. >>>>> - Port multiplexing, with application-to-port mapping during = connection setup: >>>>> Note that in the presence of network address and port = translation (NAPT), TCP ports are >>>>> in effect part of the endpoint address for forwarding purposes. >>>>> - Full reliability based on ack-based loss detection and = retransmission: >>>>> Loss is sensed using duplicated acks ("fast retransmit"), which = places a lower bound on >>>>> the delay inherent in this approach to reliability. >>>>> - Error detection based on a checksum covering the network and = transport headers as well as payload: >>>>> Packets that are detected as corrupted are dropped, relying on = the reliability mechanism >>>>> to retransmit them. >>>>> - Window-based flow control, with receiver-side window management = and signaling of available window: >>>>> Scaling the flow control window beyond 64kB requires the use of = an optional feature, >>>>> which has performance implications in environments where this = option is not supported. >>>>> - Window-based congestion control reacting to loss, delay, = retransmission timeout, or >>>>> an explicit congestion signal (ECN): >>>>> Most commonly used is a loss signal from the reliability = component's retransmission mechanism. >>>>> TCP reacts to a congestion signal by reducing the size of the = congestion window; >>>>> retransmission timeout is generally handled with a larger = reaction than other signals. >>>>>=20 >>>>> We are currently still working on the list of features that = results from thiese components but we are not there yet. Probably we not = only need the features itself but also properties/aspects (or however = you want to call this) of the feature. We already had this discussion a = bit but wanted to postpone the decision if we really need to define an = own term for this until we are sure that we need it. >>>>>=20 >>>>> We are posting this list of (TCP) components now because we would = like to get some feedback if this goes into the right direction/is on = the right level of detail before we go on and apply this also to other = protocols. >>>>=20 >>>> I agree that the list below is closer to what I think a "component" = should be ... but looking at it, is it not even clearer now that = components are not what TAPS is after? To me this list now contains lots = and lots of details that are irrelevant to the service provided to the = application. >=20 > That's part of the point we're trying to address here. The realization = we had here is that components *don't* necessarily map to feature, and = it's not clear that we can simply ignore those components that don't = map, since they may have impact on the interfaces/features it is = possible to (reasonably) implement atop those protocols. >=20 >>>> Not harmful to list but pretty useless?! >=20 > Let's start with TCP as probably the most difficult example (indeed, = that's why we worked out this "new" arrangement of components for TCP = first). A completely clean and unambiguous decomposition of TCP into its = features -- what, I agree, we're after in the end -- is not *really* = possible, because the protocols as defined and implemented weren't = really composed of discrete features. The evolution of loss-based = congestion control, for instance, was predicated on the particular loss = signals that were available at the time it was first defined. The error = detection mechanism likewise relies on the fact that reliability is = provided by retransmission. One could say that given the parallel = evolution of computing power that all these choices made by TCP were the = only obvious ones at the time. But it's precisely the co-evolution of = reliability and congestion control that makes gluing FEC to TCP so = fraught with peril. That's an important point to capture IMO. >=20 > I expect that the same exercise for SCTP will show a simpler mapping = between components and features, since it *was* designed as a = composition of features. I expect that too, but I still don't understand the point of the = component list above. I mean, yes, you may be able to map and say "we = need components X Y Z to provide features A and B" but how does this = help TAPS? >>> In this case we decided to list/discuss rather some more details, so = that people can understand what we had in mind. We might remove some of = these details/explanations at the end (or move those parts that are = actually relevant into the feature section (4)). >>>=20 >>>>=20 >>>> And how do you draw the line for what goes in and out of such a = list? E.g., on which basis did you decide that FACK, FRTO, PRR and DSACK = are not mentioned? >>>=20 >>> We tried to ask ourself which parts have an effect on the behavior = of the flow that could potentially be of interest for the application. = We might have missed some points. Actually Gorry already point out some. >>=20 >> Okay; btw just to be clear, I didn't mean that FACK etc. should be in = the list - on the contrary! My point was really about "how do you draw = the line", which you answered in the first sentence here. >>=20 >>=20 >>> The next step is to work on the feature list and figure out how = these things that are interesting for the application would be described = in a more general way (independent of the concrete algorithm that is = used by one protocol) and also discuss which features actually should be = exposed because they have a real use for the application. >>>=20 >>>>=20 >>>> To me, this whole thing is just too full of arbitrariness. We = should aim for a systematic approach that minimizes the number of = arbitrary decisions made IMO. >>>=20 >>> For us the systematic approach is to look at the implementation of = existing protocol an figure out which algorithm have an influence on the = traffic that might be interest for a higher layer to control. So we = always had, to some extend, the application in mind. >>=20 >> Okay, I understand. Thanks for clarifying! >>=20 >>=20 >>> However, you could go for a even more generic approach and only look = at the implementation and as a first step figure where are any knobs = that in principle could be configurable and then afterwards discuss all = of these very specific knobs. I though about this approach and think it = would be an interest exercise and potentially the right way to go. But I = also think that the overhead would be super large and I don=92t think it = would give us much more than we have right now. So we the current = approach we might need to expect some arbitrariness=85 >>=20 >> I lean towards this other one, of beginning with the knobs, >=20 > ... understanding that interface definitions aren't just about which = knobs (and indicators) the API provides, but also the interaction = patterns it enables, and that these interaction patterns can also be = made inefficient or even impractical by the details of the protocol in = question. (It's always *possible* to implement object transfer over = streams, or time domain transfer over objects, or to translate = asynchonous events into a synchronous API. That the Web and video = thereon "work" is proof of that. You can run the whole Internet over = DNS, if you want to. It would not work as well as the one we have today. = :) ) Yes, I agree, and I hope that this won't really bite us... or what's = your plan for addressing this problem? >> but not with the implementation but rather the "abstract API" as Joe = called it: the interface to the app as defined in the RFCs (for where it = really *is* defined). >>=20 >> I think that this discussion with Joe maybe suffered from focusing on = TCP. SCTP is perhaps a better starting point because it supports almost = everything. >=20 > We can certainly do SCTP next, which should make the exercise look = less arbitrary. (FWIW I don't think we can *eliminate* arbitrary = decisions in classification and where to cut the line between = components, or to determine which components are worth talking about. = But minimizing them is a good goal. :) ) >=20 >> So I'm thinking that a different (and, to me, perhaps more = appropriate and more systematic) method to get a list of features could = be to start with the read / write options in RFC 6458, extend it with = all such options from the other protocols, and then, protocol by = protocol, ask: "what does this protocol provide that the list now = doesn't contain?". Not sure the overhead of this approach would be super = large? But I agree, you may end up with the same list the way you do it = now. >=20 > Again, that captures knobs and indicators, less so interaction = patterns. (I will say I'm not 100% convinced the interaction patterns = are important to capture for the individual protocols, but paying = attention to them will be *crucial* to making sure that TAPS-the-system = sees uptake among application and platform developers) I agree about that, but components won't capture these interaction = patterns either, or (why/how) would they? Cheers, Michael From nobody Thu Jun 18 06:56:22 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688931B31F9 for ; Thu, 18 Jun 2015 06:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QL5ksYO0RXD for ; Thu, 18 Jun 2015 06:56:18 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EB71B31E9 for ; Thu, 18 Jun 2015 06:56:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 7CA2ED930C; Thu, 18 Jun 2015 15:56:10 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mRyUoJ5coO+X; Thu, 18 Jun 2015 15:56:10 +0200 (MEST) Received: from [192.168.178.33] (x5f700897.dyn.telefonica.de [95.112.8.151]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 075DFD930B; Thu, 18 Jun 2015 15:56:09 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> Date: Thu, 18 Jun 2015 15:56:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 13:56:20 -0000 Hi Michael, > Am 18.06.2015 um 15:43 schrieb Michael Welzl : >=20 >=20 >> On 18 Jun 2015, at 10:48, Mirja K=C3=BChlewind = wrote: >>=20 >> Hi Joe, >>=20 >> I believe the approach Michael is proposing is to look at existing = APIs as a starting point; not only abstract APIs. >=20 > No, wrong. Only abstract ones from RFCs, I said this before. These = things would typically have preceding IETF debate, whereas trying to = cover implementations is a huge and probably meaningless endeavour (the = bar may be high for adding function calls to an API on system X and low = for an API on system Y). Okay, but then I don=E2=80=99t really understand your approach fully. = Yes we should document and look at what=E2=80=99s already specified in = RFC, however isn=E2=80=99t the goal of taps to actually figure out how = to change/extend/improve these APIs? How can we figure out what=E2=80=99s = missing/wrong if we only look at what=E2=80=99s already there? Mirja >=20 >=20 >> The assumption is that someone who implemented/designed an API, = thought that it would be worth to provide a configuration possibility to = the higher layer. This assumption is more true for SCTP than for TCP = because there are quite a few different TCP implementation that are = grown over time. Quite often a new interface was only created because a = new feature was added to TCP; and to be on the safe side we allow the = user to turn it off again. >>=20 >> That=E2=80=99s the reason why I prefer the approach we are/I'm taking = right now (analyzing components). I think we should still describe the = abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in = this document, but I personally would not and will not spend too much = time analyzing other API. However, everybody who has time and is = interested in this can of course provide his/her outcome as input for = this document and we will happily take it and compare it to what we have = so far. >=20 > But you misunderstood me. I was talking about RFCs (btw 6458, not = 4960), not implementations out there. >=20 > More below, answering Joe (hm, that rhymes ;-) ) - >=20 >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 17.06.2015 um 20:10 schrieb Joe Touch : >>>=20 >>>=20 >>>=20 >>> On 6/17/2015 1:44 AM, Michael Welzl wrote: >>>> I think that this discussion with Joe maybe suffered from focusing = on >>>> TCP.=20 >>>=20 >>> To be fair, TCP has a simpler abstract API. >>>=20 >>>> SCTP is perhaps a better starting point because it supports >>>> almost everything.=20 >>>=20 >>> IMO, that makes it very hard as a starting point, and I also think = that >>> TCP's variant of an API description is much better as an example. >>>=20 >>> E.g., Section 10 of RFC4960 claims it defines an abstract API >>> (ULP-to_SCTP), but it begins by describing a call to initialize a = data >>> structure (INITIALIZE). That's decidedly NOT an abstract API; it's a >>> generic description of an implementation issue. >>>=20 >>> IMO, if we don't understand the difference between the API in RFC793 = vs. >>> that in RFC4960 (and why 793 is a better example), then this is = going to >>> be a very bumpy road. >=20 > How abstract it is in the RFC indeed isn't my main concern here: it's = to start with the interface (however abstract it is) offered to = applications as described in the RFCs, as this reflects what the = designers (with some level of IETF consensus) thought should be exposed. > Now, of course SCTP has more options and is more complex in its usage = than TCP, but it covers a larger part of the space of services in = protocols - so I thought it's a good starting point, as in: 80% done by = looking at 1 protocol, check the others for the remaining 20%. Something = like that. >=20 > This is just me being pragmatic and trying to have a more systematic = approach to developing a list of services. I agree with Brian that some = level of arbitrariness will always be there, but we must try to minimize = it I think. >=20 > Cheers, > Michael From nobody Thu Jun 18 09:45:16 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7E61AD2D5 for ; Thu, 18 Jun 2015 09:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3ZXGYZkD3pl for ; Thu, 18 Jun 2015 09:45:12 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB86E1AD2A4 for ; Thu, 18 Jun 2015 09:45:11 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z5cvx-0003Je-Ox; Thu, 18 Jun 2015 18:44:57 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z5cvx-0000RF-3p; Thu, 18 Jun 2015 18:44:57 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> Date: Thu, 18 Jun 2015 18:44:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 13 sum msgs/h 5 total rcpts 30235 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8858960EA84F940E256625ED695328B152734AD8 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1217 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 16:45:15 -0000 > On 18. jun. 2015, at 15.56, Mirja K=C3=BChlewind = wrote: >=20 > Hi Michael, >=20 >> Am 18.06.2015 um 15:43 schrieb Michael Welzl : >>=20 >>=20 >>> On 18 Jun 2015, at 10:48, Mirja K=C3=BChlewind = wrote: >>>=20 >>> Hi Joe, >>>=20 >>> I believe the approach Michael is proposing is to look at existing = APIs as a starting point; not only abstract APIs. >>=20 >> No, wrong. Only abstract ones from RFCs, I said this before. These = things would typically have preceding IETF debate, whereas trying to = cover implementations is a huge and probably meaningless endeavour (the = bar may be high for adding function calls to an API on system X and low = for an API on system Y). >=20 > Okay, but then I don=E2=80=99t really understand your approach fully. = Yes we should document and look at what=E2=80=99s already specified in = RFC, however isn=E2=80=99t the goal of taps to actually figure out how = to change/extend/improve these APIs? How can we figure out what=E2=80=99s = missing/wrong if we only look at what=E2=80=99s already there? *My* goal is, and has always been, to provide a simpler, general API = that is protocol independent. Note that this is not only for simplicity = for ease of use BUT also for the sake of being able to automatize. After = all the major goal is to remove the strict binding between applications = and a specific protocol choice. To be able to do this (documents 2 and 3), we first need a list of the = existing services - our toolbox, if you wish (document 1). Figuring out = what's missing / wrong about today's APIs (except that they are bound to = a specific protocol) has never been *my* major intention, and I = certainly don't see that as the goal of this document. I'd be surprised = if that's what the charter suggests?! But of course my opinion is only = what it is, the charter reflects the consensus... All this being said, it can be a nice side-effect of the document (and = note that noone knows what a TAPS system will really look like, and how = these RFCs will actually end up being used). So I'm not strongly = opposing the approach you're now following in that I don't see a big = issue with there being a list of components - I just think it's not = particularly useful for the goal of the document and doesn't really help = the group progress towards its goals. I thought that proposing something = more systematic with less arbitrariness could make it easier to put = everyone in the same boat (in a way: "look, the boat HAS to be like = that, there wasn't much choice, sit down please" rather than "sorry I = painted it green, I like that color; I can understand you would have = preferred a blue boat..."). Cheers, Michael From nobody Thu Jun 18 15:52:11 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDC01A9030 for ; Thu, 18 Jun 2015 15:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq2NsLU3hrxM for ; Thu, 18 Jun 2015 15:52:09 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554FB1A8A9D for ; Thu, 18 Jun 2015 15:52:09 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id t5IMpOaU015294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Jun 2015 15:51:25 -0700 (PDT) To: Michael Welzl , =?UTF-8?Q?Mirja_K=c3=bchlewind?= References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> From: Joe Touch Message-ID: <55834B6C.5020000@isi.edu> Date: Thu, 18 Jun 2015 15:51:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: t5IMpOaU015294 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , "taps@ietf.org" , touch@isi.edu Subject: Re: [Taps] TCP components 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 Jun 2015 22:52:10 -0000 +1 On 6/18/2015 9:44 AM, Michael Welzl wrote: > *My* goal is, and has always been, to provide a simpler, general API > that is protocol independent. Note that this is not only for > simplicity for ease of use BUT also for the sake of being able to > automatize. After all the major goal is to remove the strict binding > between applications and a specific protocol choice. > > To be able to do this (documents 2 and 3), we first need a list of > the existing services - our toolbox, if you wish (document 1). > Figuring out what's missing / wrong about today's APIs (except that > they are bound to a specific protocol) has never been*my* major > intention, and I certainly don't see that as the goal of this > document. I'd be surprised if that's what the charter suggests?! But > of course my opinion is only what it is, the charter reflects the > consensus... From nobody Fri Jun 19 03:07:26 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0791A8870 for ; Fri, 19 Jun 2015 03:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxbdza8febJF for ; Fri, 19 Jun 2015 03:07:22 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5791A886B for ; Fri, 19 Jun 2015 03:07:21 -0700 (PDT) Received: from [10.0.0.87] (unknown [89.246.150.136]) by trammell.ch (Postfix) with ESMTPSA id 9048B1A0777; Fri, 19 Jun 2015 12:07:20 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D8BBFD79-A2B2-4867-845D-7DB0A45DCFE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: Date: Fri, 19 Jun 2015 12:07:19 +0200 Message-Id: <6F42B0B2-9349-4639-8695-814D9C797F01@trammell.ch> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <8377C788-96BC-4F70-ADDD-B3E07AC814A0@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "taps@ietf.org" Subject: Re: [Taps] TCP components 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 Jun 2015 10:07:25 -0000 --Apple-Mail=_D8BBFD79-A2B2-4867-845D-7DB0A45DCFE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Michael, A few replies inline. > On 18 Jun 2015, at 15:54, Michael Welzl wrote: >=20 >=20 >> On 17 Jun 2015, at 12:13, Brian Trammell wrote: >>=20 >> hi Michael, all, >>=20 >> A couple of random points inline at various levels of quotation... >>=20 >>> On 17 Jun 2015, at 10:44, Michael Welzl wrote: >>>=20 >>>>>=20 >>>>> I agree that the list below is closer to what I think a = "component" should be ... but looking at it, is it not even clearer now = that components are not what TAPS is after? To me this list now contains = lots and lots of details that are irrelevant to the service provided to = the application. >>=20 >> That's part of the point we're trying to address here. The = realization we had here is that components *don't* necessarily map to = feature, and it's not clear that we can simply ignore those components = that don't map, since they may have impact on the interfaces/features it = is possible to (reasonably) implement atop those protocols. >>=20 >>>>> Not harmful to list but pretty useless?! >>=20 >> Let's start with TCP as probably the most difficult example (indeed, = that's why we worked out this "new" arrangement of components for TCP = first). A completely clean and unambiguous decomposition of TCP into its = features -- what, I agree, we're after in the end -- is not *really* = possible, because the protocols as defined and implemented weren't = really composed of discrete features. The evolution of loss-based = congestion control, for instance, was predicated on the particular loss = signals that were available at the time it was first defined. The error = detection mechanism likewise relies on the fact that reliability is = provided by retransmission. One could say that given the parallel = evolution of computing power that all these choices made by TCP were the = only obvious ones at the time. But it's precisely the co-evolution of = reliability and congestion control that makes gluing FEC to TCP so = fraught with peril. That's an important point to capture IMO. >>=20 >> I expect that the same exercise for SCTP will show a simpler mapping = between components and features, since it *was* designed as a = composition of features. >=20 > I expect that too, but I still don't understand the point of the = component list above. I mean, yes, you may be able to map and say "we = need components X Y Z to provide features A and B" but how does this = help TAPS? So as I see it, "features" are the TAPS view of the world of the future = -- the set of things that transport protocols can do, and that a better = interface can give you access to. "Components" are the view of the world = of the present -- what the current definitions *and deployed = implementations* of transport protocols can do, and what each of those = features imply. There are a few ways you can implement the TAPS API. The one we chose to = pursue in the WG (or at least I thought we had) is that the TAPS API = takes (1) information from the application about its requirements in = terms of features and parameters on those features (if available), (2) = information from the path about which transport protocols and options = are usable on the path, and the selects a transport protocol, and acts = as glue between the API and the underlying protocol. In this approach, it is IMO important to catalog the protocol components = (and the interactions among them) since the mappings between components = and features might not be clean. This might not be the document to do = that in. But we wanted to do the exercise to see what the outcome looked = like. >>>> However, you could go for a even more generic approach and only = look at the implementation and as a first step figure where are any = knobs that in principle could be configurable and then afterwards = discuss all of these very specific knobs. I though about this approach = and think it would be an interest exercise and potentially the right way = to go. But I also think that the overhead would be super large and I = don=92t think it would give us much more than we have right now. So we = the current approach we might need to expect some arbitrariness=85 >>>=20 >>> I lean towards this other one, of beginning with the knobs, >>=20 >> ... understanding that interface definitions aren't just about which = knobs (and indicators) the API provides, but also the interaction = patterns it enables, and that these interaction patterns can also be = made inefficient or even impractical by the details of the protocol in = question. (It's always *possible* to implement object transfer over = streams, or time domain transfer over objects, or to translate = asynchonous events into a synchronous API. That the Web and video = thereon "work" is proof of that. You can run the whole Internet over = DNS, if you want to. It would not work as well as the one we have today. = :) ) >=20 > Yes, I agree, and I hope that this won't really bite us... or what's = your plan for addressing this problem? In this document, I don't think we need to do anything. If we take an = API-centric view, we simply need to note the interaction pattern = supported by each API. In the services and interfaces documents, I think = we need to explicitly address which interaction patterns we want to = support. >>> but not with the implementation but rather the "abstract API" as Joe = called it: the interface to the app as defined in the RFCs (for where it = really *is* defined). >>>=20 >>> I think that this discussion with Joe maybe suffered from focusing = on TCP. SCTP is perhaps a better starting point because it supports = almost everything. >>=20 >> We can certainly do SCTP next, which should make the exercise look = less arbitrary. (FWIW I don't think we can *eliminate* arbitrary = decisions in classification and where to cut the line between = components, or to determine which components are worth talking about. = But minimizing them is a good goal. :) ) >>=20 >>> So I'm thinking that a different (and, to me, perhaps more = appropriate and more systematic) method to get a list of features could = be to start with the read / write options in RFC 6458, extend it with = all such options from the other protocols, and then, protocol by = protocol, ask: "what does this protocol provide that the list now = doesn't contain?". Not sure the overhead of this approach would be super = large? But I agree, you may end up with the same list the way you do it = now. >>=20 >> Again, that captures knobs and indicators, less so interaction = patterns. (I will say I'm not 100% convinced the interaction patterns = are important to capture for the individual protocols, but paying = attention to them will be *crucial* to making sure that TAPS-the-system = sees uptake among application and platform developers) >=20 > I agree about that, but components won't capture these interaction = patterns either, or (why/how) would they? No, they won't -- I was responding to two separate points here, sorry... Cheers, Brian --Apple-Mail=_D8BBFD79-A2B2-4867-845D-7DB0A45DCFE1 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 iQEcBAEBCgAGBQJVg+nXAAoJENt3nsOmbNJcGuEH/AzoiPYfypDkUPCclFUoYV8r jGL1RSx5L+Mt44iexIQM4ALvs/7bk5Gkc+6UGeHUpZtLjMdix/RV3abQ2i0WmX7V EgauW8vkYxKScQ6Mq+X9gB8TMbyroHfYStUEZrEQngvOHw6YMmNb1vO3cFLqwCYD cpJ0Dp7Ud4iHpOnZGq5f5p5SRMgCN+ifKNN8aXqM2Zw5HMTDcFXLHydY/rXZJ4CK jXKFOiDAgjv17cp0bNrEIgdkWtXWJzWWEUPJkAsz/2Y92E3N4ZwjtHdaMLcefQ7X cjzky+a1IeCrFefkE9gt71fbw0wKePpBHnh1ZIxS5KRbLArNrQg4jWjOBu5lw20= =gK/K -----END PGP SIGNATURE----- --Apple-Mail=_D8BBFD79-A2B2-4867-845D-7DB0A45DCFE1-- From nobody Fri Jun 19 04:18:42 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58111A895C for ; Fri, 19 Jun 2015 04:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idatj0ziyeQL for ; Fri, 19 Jun 2015 04:18:38 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445181A890E for ; Fri, 19 Jun 2015 04:18:38 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z5uJg-0001yO-3w; Fri, 19 Jun 2015 13:18:36 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1Z5uJf-0007OD-7Q; Fri, 19 Jun 2015 13:18:36 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <6F42B0B2-9349-4639-8695-814D9C797F01@trammell.ch> Date: Fri, 19 Jun 2015 13:18:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <8377C788-96BC-4F70-ADDD-B3E07AC814A0@trammell.ch> <6F42B0B2-9349-4639-8695-814D9C797F01@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 30269 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.052, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 78FD6E9ABDE8A6DF3733D619543EEBE58D984141 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 7347 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: =?windows-1252?Q?Mirja_K=FChlewind?= , "taps@ietf.org" Subject: Re: [Taps] TCP components 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 Jun 2015 11:18:41 -0000 > On 19 Jun 2015, at 12:07, Brian Trammell wrote: >=20 > hi Michael, >=20 > A few replies inline. >=20 >> On 18 Jun 2015, at 15:54, Michael Welzl wrote: >>=20 >>=20 >>> On 17 Jun 2015, at 12:13, Brian Trammell wrote: >>>=20 >>> hi Michael, all, >>>=20 >>> A couple of random points inline at various levels of quotation... >>>=20 >>>> On 17 Jun 2015, at 10:44, Michael Welzl wrote: >>>>=20 >>>>>>=20 >>>>>> I agree that the list below is closer to what I think a = "component" should be ... but looking at it, is it not even clearer now = that components are not what TAPS is after? To me this list now contains = lots and lots of details that are irrelevant to the service provided to = the application. >>>=20 >>> That's part of the point we're trying to address here. The = realization we had here is that components *don't* necessarily map to = feature, and it's not clear that we can simply ignore those components = that don't map, since they may have impact on the interfaces/features it = is possible to (reasonably) implement atop those protocols. >>>=20 >>>>>> Not harmful to list but pretty useless?! >>>=20 >>> Let's start with TCP as probably the most difficult example (indeed, = that's why we worked out this "new" arrangement of components for TCP = first). A completely clean and unambiguous decomposition of TCP into its = features -- what, I agree, we're after in the end -- is not *really* = possible, because the protocols as defined and implemented weren't = really composed of discrete features. The evolution of loss-based = congestion control, for instance, was predicated on the particular loss = signals that were available at the time it was first defined. The error = detection mechanism likewise relies on the fact that reliability is = provided by retransmission. One could say that given the parallel = evolution of computing power that all these choices made by TCP were the = only obvious ones at the time. But it's precisely the co-evolution of = reliability and congestion control that makes gluing FEC to TCP so = fraught with peril. That's an important point to capture IMO. >>>=20 >>> I expect that the same exercise for SCTP will show a simpler mapping = between components and features, since it *was* designed as a = composition of features. >>=20 >> I expect that too, but I still don't understand the point of the = component list above. I mean, yes, you may be able to map and say "we = need components X Y Z to provide features A and B" but how does this = help TAPS? >=20 > So as I see it, "features" are the TAPS view of the world of the = future -- the set of things that transport protocols can do, and that a = better interface can give you access to. "Components" are the view of = the world of the present -- what the current definitions *and deployed = implementations* of transport protocols can do, and what each of those = features imply. >=20 > There are a few ways you can implement the TAPS API. The one we chose = to pursue in the WG (or at least I thought we had) is that the TAPS API = takes (1) information from the application about its requirements in = terms of features and parameters on those features (if available), (2) = information from the path about which transport protocols and options = are usable on the path, and the selects a transport protocol, and acts = as glue between the API and the underlying protocol. >=20 > In this approach, it is IMO important to catalog the protocol = components (and the interactions among them) since the mappings between = components and features might not be clean. This might not be the = document to do that in. But we wanted to do the exercise to see what the = outcome looked like. I see. Well I don't have a problem with that, I was just suggesting that = this is probably not the path of easy agreement. > >=20 >>>>> However, you could go for a even more generic approach and only = look at the implementation and as a first step figure where are any = knobs that in principle could be configurable and then afterwards = discuss all of these very specific knobs. I though about this approach = and think it would be an interest exercise and potentially the right way = to go. But I also think that the overhead would be super large and I = don=92t think it would give us much more than we have right now. So we = the current approach we might need to expect some arbitrariness=85 >>>>=20 >>>> I lean towards this other one, of beginning with the knobs, >>>=20 >>> ... understanding that interface definitions aren't just about which = knobs (and indicators) the API provides, but also the interaction = patterns it enables, and that these interaction patterns can also be = made inefficient or even impractical by the details of the protocol in = question. (It's always *possible* to implement object transfer over = streams, or time domain transfer over objects, or to translate = asynchonous events into a synchronous API. That the Web and video = thereon "work" is proof of that. You can run the whole Internet over = DNS, if you want to. It would not work as well as the one we have today. = :) ) >>=20 >> Yes, I agree, and I hope that this won't really bite us... or what's = your plan for addressing this problem? >=20 > In this document, I don't think we need to do anything. If we take an = API-centric view, we simply need to note the interaction pattern = supported by each API. In the services and interfaces documents, I think = we need to explicitly address which interaction patterns we want to = support. That makes sense to me. Cheers, Michael From nobody Fri Jun 19 05:03:44 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3151A8888 for ; Fri, 19 Jun 2015 05:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 QG_42wA2doYw for ; Fri, 19 Jun 2015 05:03:40 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7831A1BDC for ; Fri, 19 Jun 2015 05:03:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id AC4D6D930C; Fri, 19 Jun 2015 14:03:38 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k3GjOTqjUtO6; Fri, 19 Jun 2015 14:03:38 +0200 (MEST) Received: from [192.168.178.33] (x4d02dd5d.dyn.telefonica.de [77.2.221.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2B071D9309; Fri, 19 Jun 2015 14:03:38 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 19 Jun 2015 14:03:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 12:03:42 -0000 Hi Michael, > *My* goal is, and has always been, to provide a simpler, general API = that is protocol independent. Note that this is not only for simplicity = for ease of use BUT also for the sake of being able to automatize. After = all the major goal is to remove the strict binding between applications = and a specific protocol choice. Yes, I agree! (not sure if this is simpler though=E2=80=A6 depends on = the definition of simple=E2=80=A6 but hopefully easier to use and = understand for the overlying application). >=20 > To be able to do this (documents 2 and 3), we first need a list of the = existing services - our toolbox, if you wish (document 1). Figuring out = what's missing / wrong about today's APIs (except that they are bound to = a specific protocol) has never been *my* major intention, and I = certainly don't see that as the goal of this document. I'd be surprised = if that's what the charter suggests?! But of course my opinion is only = what it is, the charter reflects the consensus=E2=80=A6 So there current API is always bound to a specify protocol which already = provides you a certain set of service feature. At least in TCP there is = not much choice left and there the current API does not give us a good = indication which services are actually provided by TCP. Therefore from = my point of view the only way to identify these services is to look at = the protocol itself and not only the API. In SCTP it=E2=80=99s different = and we definitely have to and will discuss the existing API in the = document. >=20 > All this being said, it can be a nice side-effect of the document (and = note that noone knows what a TAPS system will really look like, and how = these RFCs will actually end up being used). So I'm not strongly = opposing the approach you're now following in that I don't see a big = issue with there being a list of components - I just think it's not = particularly useful for the goal of the document and doesn't really help = the group progress towards its goals. I thought that proposing something = more systematic with less arbitrariness could make it easier to put = everyone in the same boat (in a way: "look, the boat HAS to be like = that, there wasn't much choice, sit down please" rather than "sorry I = painted it green, I like that color; I can understand you would have = preferred a blue boat...=E2=80=9C). I totally understand this point. But at least for TCP I think it is not = sufficient to look at the (abstract) API because in TCP there are not = much choices and therefore the services TCP provides are not exposed = over the API. I personally currently don=E2=80=99t see how another = approach would bring us the the goal of identify existing services. Again, if you have time to work on an alternative approach, please go = ahead and provide input or even submit an own draft and I=E2=80=99m/we=E2=80= =99re really open to discuss this and see what makes more sense.=20 Mirja >=20 > Cheers, > Michael From nobody Fri Jun 19 05:33:13 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1A51A8ACC for ; Fri, 19 Jun 2015 05:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.142 X-Spam-Level: X-Spam-Status: No, score=-1.142 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haHd4EniRUWa for ; Fri, 19 Jun 2015 05:33:10 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAFD1A8AD6 for ; Fri, 19 Jun 2015 05:33:09 -0700 (PDT) Received: from [10.0.0.87] (unknown [89.246.150.136]) by trammell.ch (Postfix) with ESMTPSA id 736CC1A078E; Fri, 19 Jun 2015 14:32:37 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9B3DCC8E-64AE-4F5B-B129-625E6993B9DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Brian Trammell In-Reply-To: Date: Fri, 19 Jun 2015 14:32:36 +0200 Message-Id: <5995ACCC-6074-4E5B-8E21-BC65EE80571B@trammell.ch> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 12:33:12 -0000 --Apple-Mail=_9B3DCC8E-64AE-4F5B-B129-625E6993B9DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Michael, continued, inline. > On 18 Jun 2015, at 18:44, Michael Welzl wrote: >=20 >=20 >> On 18. jun. 2015, at 15.56, Mirja K=C3=BChlewind = wrote: >>=20 >> Hi Michael, >>=20 >>> Am 18.06.2015 um 15:43 schrieb Michael Welzl : >>>=20 >>>=20 >>>> On 18 Jun 2015, at 10:48, Mirja K=C3=BChlewind = wrote: >>>>=20 >>>> Hi Joe, >>>>=20 >>>> I believe the approach Michael is proposing is to look at existing = APIs as a starting point; not only abstract APIs. >>>=20 >>> No, wrong. Only abstract ones from RFCs, I said this before. These = things would typically have preceding IETF debate, whereas trying to = cover implementations is a huge and probably meaningless endeavour (the = bar may be high for adding function calls to an API on system X and low = for an API on system Y). >>=20 >> Okay, but then I don=E2=80=99t really understand your approach fully. = Yes we should document and look at what=E2=80=99s already specified in = RFC, however isn=E2=80=99t the goal of taps to actually figure out how = to change/extend/improve these APIs? How can we figure out what=E2=80=99s = missing/wrong if we only look at what=E2=80=99s already there? >=20 > *My* goal is, and has always been, to provide a simpler, general API = that is protocol independent. +1, though I would at this point say "better" as opposed to "simpler" = and "general", with the caveat that i'm not yet sure what better looks = like. This gets back to my point about interaction patterns in the = previous message, though: if the simpler API provides only stream = interaction, or packet sequence interaction, or if it only allows = receivers to get data through asynchronous notifications, it will make = it hard to support . So maybe we want a better common API for defining = the *requirements* of an association, and better TX/RX *APIs* plural, = one for each interaction pattern we want to support. > Note that this is not only for simplicity for ease of use BUT also for = the sake of being able to automatize. After all the major goal is to = remove the strict binding between applications and a specific protocol = choice. We share this higher level goal in any case. > To be able to do this (documents 2 and 3), we first need a list of the = existing services - our toolbox, if you wish (document 1). Figuring out = what's missing / wrong about today's APIs (except that they are bound to = a specific protocol) has never been *my* major intention, and I = certainly don't see that as the goal of this document. I'd be surprised = if that's what the charter suggests?! But of course my opinion is only = what it is, the charter reflects the consensus... I don't think that's in scope for this document, either. The component = (and decomposition) work is aimed at figuring out what the available = features are, and what (in a "TAPS as glue layer over existing = transports" design) the implications of using protocol X for feature Y = are. The API work is a bit of a non-sequitur (but also important to = note...) > All this being said, it can be a nice side-effect of the document (and = note that noone knows what a TAPS system will really look like, and how = these RFCs will actually end up being used). In general, if there's any content in this document that is useful but = doesn't fit but we still find useful, we can certainly put it something = else. > So I'm not strongly opposing the approach you're now following in that = I don't see a big issue with there being a list of components - I just = think it's not particularly useful for the goal of the document and = doesn't really help the group progress towards its goals. I thought that = proposing something more systematic with less arbitrariness could make = it easier to put everyone in the same boat (in a way: "look, the boat = HAS to be like that, there wasn't much choice, sit down please" rather = than "sorry I painted it green, I like that color; I can understand you = would have preferred a blue boat..."). I agree. Given, though, that the protocols we're looking at, that they = weren't designed from components, it is really not clear to me how to = systematically decompose existing protocols without making arbitrary = choices as to where to make the cut. (and I wouldn't read too much into = the approach we're following -- we're trying to incorporate the input = we've taken from discussion on the list into the structure of the = document, and as Mirja says, we're completely open to trying other = approaches to do that). We could take an opposite approach here: jump forward to section 4, = define the features we think we want -- this we can do more = systematically, because we're only limited by the intersection of the = features we want and the features we think we can realistically deploy, = as opposed to the history represented by the protocol components -- and = then use the components as a check on the feasibility of those features. Cheers, Brian --Apple-Mail=_9B3DCC8E-64AE-4F5B-B129-625E6993B9DE 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 iQEcBAEBCgAGBQJVhAvlAAoJENt3nsOmbNJcqS8H/idAzuz7SjAI9RtGvcApybtc /kmZA6cPPuXg/Iud/heDEEu20yZ4Wf9n4/C4B4/tqDwkz55wIHTZ897OVg+lilBY ga209UK4wlnahI+juD4bkfQe+KJGJRAFIc5g1m8Fq4uZddJwnLDtnc9LwsEXxU3k +GgAai+OPtRARoIy3m926+n7fSvTLI/kA86BgOXNP3RMUJGfE+q6GnE8gxacU8VD dfyy0a9pPEs281Q77wLLOxozqo8On8MegMT4hOEcJq7jPnbMropOIkJ/PFrAfSEc 482eWjprL6emN0izL35wHbe1s0rC5Q6pahJXEYyVrLh5yTpwxnOKijI90uXCyjQ= =bXKm -----END PGP SIGNATURE----- --Apple-Mail=_9B3DCC8E-64AE-4F5B-B129-625E6993B9DE-- From nobody Fri Jun 19 06:22:55 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E741A901D for ; Fri, 19 Jun 2015 06:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQxpd9GEXOHj for ; Fri, 19 Jun 2015 06:22:52 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435C21A8FD7 for ; Fri, 19 Jun 2015 06:22:51 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z5wFi-0005Fs-1u; Fri, 19 Jun 2015 15:22:38 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z5wFh-00049T-Hw; Fri, 19 Jun 2015 15:22:37 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: Date: Fri, 19 Jun 2015 15:22:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 30276 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.052, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: FBFAA8419863BA3DA676AE3B51057515DE66B225 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 7350 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 13:22:54 -0000 > On 19 Jun 2015, at 14:03, Mirja K=C3=BChlewind = wrote: >=20 > Hi Michael, >=20 >> *My* goal is, and has always been, to provide a simpler, general API = that is protocol independent. Note that this is not only for simplicity = for ease of use BUT also for the sake of being able to automatize. After = all the major goal is to remove the strict binding between applications = and a specific protocol choice. >=20 > Yes, I agree! (not sure if this is simpler though=E2=80=A6 depends on = the definition of simple=E2=80=A6 but hopefully easier to use and = understand for the overlying application). Agree too, easier to use is what I meant >> To be able to do this (documents 2 and 3), we first need a list of = the existing services - our toolbox, if you wish (document 1). Figuring = out what's missing / wrong about today's APIs (except that they are = bound to a specific protocol) has never been *my* major intention, and I = certainly don't see that as the goal of this document. I'd be surprised = if that's what the charter suggests?! But of course my opinion is only = what it is, the charter reflects the consensus=E2=80=A6 >=20 > So there current API is always bound to a specify protocol which = already provides you a certain set of service feature. At least in TCP = there is not much choice left and there the current API does not give us = a good indication which services are actually provided by TCP. Therefore = from my point of view the only way to identify these services is to look = at the protocol itself and not only the API. In SCTP it=E2=80=99s = different and we definitely have to and will discuss the existing API in = the document. Exactly that's why I thought starting with TCP's API (even when it's the = abstract one) is not very helpful. Joe, Aaron: what is it you were expecting us to take away from reading = section 3.8 of RFC 793? ( I can see it highlighting the need to discuss communication patterns = (or decide for a specific one) in document #2, but not really = contributing much to the list in document #1 ? ) >> All this being said, it can be a nice side-effect of the document = (and note that noone knows what a TAPS system will really look like, and = how these RFCs will actually end up being used). So I'm not strongly = opposing the approach you're now following in that I don't see a big = issue with there being a list of components - I just think it's not = particularly useful for the goal of the document and doesn't really help = the group progress towards its goals. I thought that proposing something = more systematic with less arbitrariness could make it easier to put = everyone in the same boat (in a way: "look, the boat HAS to be like = that, there wasn't much choice, sit down please" rather than "sorry I = painted it green, I like that color; I can understand you would have = preferred a blue boat...=E2=80=9C). >=20 > I totally understand this point. But at least for TCP I think it is = not sufficient to look at the (abstract) API because in TCP there are = not much choices and therefore the services TCP provides are not exposed = over the API. I personally currently don=E2=80=99t see how another = approach would bring us the the goal of identify existing services. Agree about TCP > Again, if you have time to work on an alternative approach, please go = ahead and provide input or even submit an own draft and I=E2=80=99m/we=E2=80= =99re really open to discuss this and see what makes more sense.=20 Ok.... well, I agree that what I request is easier said than done :-( = myself, I've been working on a first version of document #2 as I = think this would help us understand if the set of "services" or whatever = we call them in document #1 is useful for the group's purpose. Michael From nobody Fri Jun 19 06:41:09 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CF51A011B for ; Fri, 19 Jun 2015 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyS7eN3dbQ_M for ; Fri, 19 Jun 2015 06:41:06 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098761A0113 for ; Fri, 19 Jun 2015 06:41:06 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z5wXX-0007xW-V4; Fri, 19 Jun 2015 15:41:03 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z5wXX-0000v4-61; Fri, 19 Jun 2015 15:41:03 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl In-Reply-To: <5995ACCC-6074-4E5B-8E21-BC65EE80571B@trammell.ch> Date: Fri, 19 Jun 2015 15:41:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <45CE5D07-F7C9-4698-98D6-2C8D8927C6E9@ifi.uio.no> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5995ACCC-6074-4E5B-8E21-BC65EE80571B@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 3 sum rcpts/h 11 sum msgs/h 3 total rcpts 30281 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.052, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2918D837161EE1AB4E99DB4964F15A2F0A725F0A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 7352 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 13:41:08 -0000 > On 19 Jun 2015, at 14:32, Brian Trammell wrote: >=20 > hi Michael, >=20 > continued, inline. >=20 >> On 18 Jun 2015, at 18:44, Michael Welzl wrote: >>=20 >>=20 >>> On 18. jun. 2015, at 15.56, Mirja K=C3=BChlewind = wrote: >>>=20 >>> Hi Michael, >>>=20 >>>> Am 18.06.2015 um 15:43 schrieb Michael Welzl : >>>>=20 >>>>=20 >>>>> On 18 Jun 2015, at 10:48, Mirja K=C3=BChlewind = wrote: >>>>>=20 >>>>> Hi Joe, >>>>>=20 >>>>> I believe the approach Michael is proposing is to look at existing = APIs as a starting point; not only abstract APIs. >>>>=20 >>>> No, wrong. Only abstract ones from RFCs, I said this before. These = things would typically have preceding IETF debate, whereas trying to = cover implementations is a huge and probably meaningless endeavour (the = bar may be high for adding function calls to an API on system X and low = for an API on system Y). >>>=20 >>> Okay, but then I don=E2=80=99t really understand your approach = fully. Yes we should document and look at what=E2=80=99s already = specified in RFC, however isn=E2=80=99t the goal of taps to actually = figure out how to change/extend/improve these APIs? How can we figure = out what=E2=80=99s missing/wrong if we only look at what=E2=80=99s = already there? >>=20 >> *My* goal is, and has always been, to provide a simpler, general API = that is protocol independent. >=20 > +1, though I would at this point say "better" as opposed to "simpler" = and "general", with the caveat that i'm not yet sure what better looks = like. This gets back to my point about interaction patterns in the = previous message, though: if the simpler API provides only stream = interaction, or packet sequence interaction, or if it only allows = receivers to get data through asynchronous notifications, it will make = it hard to support . So maybe we want a better common API for defining = the *requirements* of an association, and better TX/RX *APIs* plural, = one for each interaction pattern we want to support. I agree. >> Note that this is not only for simplicity for ease of use BUT also = for the sake of being able to automatize. After all the major goal is to = remove the strict binding between applications and a specific protocol = choice. >=20 > We share this higher level goal in any case. >=20 >> To be able to do this (documents 2 and 3), we first need a list of = the existing services - our toolbox, if you wish (document 1). Figuring = out what's missing / wrong about today's APIs (except that they are = bound to a specific protocol) has never been *my* major intention, and I = certainly don't see that as the goal of this document. I'd be surprised = if that's what the charter suggests?! But of course my opinion is only = what it is, the charter reflects the consensus... >=20 > I don't think that's in scope for this document, either. The component = (and decomposition) work is aimed at figuring out what the available = features are, and what (in a "TAPS as glue layer over existing = transports" design) the implications of using protocol X for feature Y = are. The API work is a bit of a non-sequitur (but also important to = note...) >=20 >> All this being said, it can be a nice side-effect of the document = (and note that noone knows what a TAPS system will really look like, and = how these RFCs will actually end up being used). >=20 > In general, if there's any content in this document that is useful but = doesn't fit but we still find useful, we can certainly put it something = else. >=20 >> So I'm not strongly opposing the approach you're now following in = that I don't see a big issue with there being a list of components - I = just think it's not particularly useful for the goal of the document and = doesn't really help the group progress towards its goals. I thought that = proposing something more systematic with less arbitrariness could make = it easier to put everyone in the same boat (in a way: "look, the boat = HAS to be like that, there wasn't much choice, sit down please" rather = than "sorry I painted it green, I like that color; I can understand you = would have preferred a blue boat..."). >=20 > I agree. Given, though, that the protocols we're looking at, that they = weren't designed from components, it is really not clear to me how to = systematically decompose existing protocols without making arbitrary = choices as to where to make the cut. but why decompose? > (and I wouldn't read too much into the approach we're following -- = we're trying to incorporate the input we've taken from discussion on the = list into the structure of the document, and as Mirja says, we're = completely open to trying other approaches to do that). >=20 > We could take an opposite approach here: jump forward to section 4, = define the features we think we want -- this we can do more = systematically, because we're only limited by the intersection of the = features we want and the features we think we can realistically deploy, = as opposed to the history represented by the protocol components -- and = then use the components as a check on the feasibility of those features. Interesting idea - it sounds good to me! Cheers, Michael From nobody Fri Jun 19 07:15:57 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9051A037E for ; Fri, 19 Jun 2015 07:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eLNTBkVlCpC for ; Fri, 19 Jun 2015 07:15:54 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 420941A036A for ; Fri, 19 Jun 2015 07:15:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D7C5FD930D; Fri, 19 Jun 2015 16:15:52 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id V2eHkY66yT2E; Fri, 19 Jun 2015 16:15:52 +0200 (MEST) Received: from [192.168.178.33] (x4d02dd5d.dyn.telefonica.de [77.2.221.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 53CB1D930C; Fri, 19 Jun 2015 16:15:52 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 19 Jun 2015 16:15:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> To: Michael Welzl X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Brian Trammell , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 14:15:56 -0000 Hi Michael, >=20 >> Again, if you have time to work on an alternative approach, please go = ahead and provide input or even submit an own draft and I=E2=80=99m/we=E2=80= =99re really open to discuss this and see what makes more sense.=20 >=20 > Ok.... well, I agree that what I request is easier said than done = :-( myself, I've been working on a first version of document #2 as I = think this would help us understand if the set of "services" or whatever = we call them in document #1 is useful for the group's purpose. Cool! I think that the alternative approach Brian just proposed: Start = with the feature we think/know we want to have and the compare them with = what we have in the first document. Mirja From nobody Fri Jun 19 09:09:03 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F571A9233 for ; Fri, 19 Jun 2015 09:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-BxRSLXtIJQ for ; Fri, 19 Jun 2015 09:09:01 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF8D01A9252 for ; Fri, 19 Jun 2015 09:08:57 -0700 (PDT) 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 t5JG7uE0018424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Jun 2015 09:07:56 -0700 (PDT) Message-ID: <55843E5C.1000704@isi.edu> Date: Fri, 19 Jun 2015 09:07:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , Michael Welzl References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> 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: Cc: Brian Trammell , "taps@ietf.org" , touch@isi.edu Subject: Re: [Taps] TCP components 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 Jun 2015 16:09:02 -0000 On 6/19/2015 7:15 AM, Mirja Kühlewind wrote: > Cool! I think that the alternative approach Brian just proposed: > Start with the feature we think/know we want to have and the compare > them with what we have in the first document. -1 If you don't know what you already have, it's hard to figure out why what you need isn't there. Joe From nobody Fri Jun 19 09:15:55 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EB21A92E1 for ; Fri, 19 Jun 2015 09:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.61 X-Spam-Level: X-Spam-Status: No, score=-6.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11opoxZc31dC for ; Fri, 19 Jun 2015 09:15:53 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CEB1A92B9 for ; Fri, 19 Jun 2015 09:15:53 -0700 (PDT) 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 t5JGF8sR020095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Jun 2015 09:15:08 -0700 (PDT) Message-ID: <5584400C.5080406@isi.edu> Date: Fri, 19 Jun 2015 09:15:08 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Michael Welzl , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> 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: Cc: Brian Trammell , "taps@ietf.org" , touch@isi.edu Subject: Re: [Taps] TCP components 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 Jun 2015 16:15:54 -0000 On 6/19/2015 6:22 AM, Michael Welzl wrote: > > On 19 Jun 2015, at 14:03, Mirja Kühlewind wrote: >> So there current API is always bound to a specify protocol which >> already provides you a certain set of service feature. At least in >> TCP there is not much choice left and there the current API does >> not give us a good indication which services are actually provided >> by TCP. Therefore from my point of view the only way to identify >> these services is to look at the protocol itself and not only the >> API. In SCTP it’s different and we definitely have to and will >> discuss the existing API in the document. > > Exactly that's why I thought starting with TCP's API > (even when it's the abstract one) is not very helpful. > > Joe, Aaron: what is it you were expecting us to take away from > reading section 3.8 of RFC 793? No. IMO, the current description of that API fails to indicate the controls *already* available to TCP. I don't agree that the TCP API doesn't indicate the service TCP provides - it's just implicit. E.g.: OPEN call indicates TCP is connection oriented SEND/RECEIVE calls indicates TCP is an ordered byte stream, that the user-level byte boundaries are NOT related to message boundaries, etc. Yes, there's some "reading between the lines" to do here. > ( I can see it highlighting the need > to discuss communication patterns (or decide for a specific one) in > document #2, but not really contributing much to the list in document > #1 ? ) I believe the opposite is true. Joe From nobody Fri Jun 19 14:39:16 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E711B2AFE for ; Fri, 19 Jun 2015 14:39:15 -0700 (PDT) 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 FpOqYHygJU85 for ; Fri, 19 Jun 2015 14:39:13 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1512B1B2AFD for ; Fri, 19 Jun 2015 14:39:13 -0700 (PDT) Received: by wibee9 with SMTP id ee9so20594996wib.0 for ; Fri, 19 Jun 2015 14:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xrjywfq07GpdZGs6XF2fyyD1IKjedUPIKjNrMqFlBZc=; b=Ego25cn1lG7xt3jIAegrHI6ke9EDEv0P9BbnwjdcNqgAmqSNjnP9x5fiYni0OWWf0C M1/wDc+uj69fuSpBIZ8cXASDA87cIJEIbwWweqMeIjmIg9AVGwOKel1JLNdcgclnAON1 PAdhZuGgZ/eYfsC/+rNY6LSfwt8CdJK4RzqiK5SLylkhXgEJSqnMtRAUocasPgcRab4L y4vjNno6/eNEbbco77zdy0paBLfpxs0W8Pq3EhL+aYb2Sz52Ihogjfr9Pxnb45Vmfd9b wdqXQfG+9PCqsDpTQXQaWltsTOmnilD5aWek1pXv2dXWDuLC0mghSaXF85NXWxwPs2i8 A/LA== MIME-Version: 1.0 X-Received: by 10.180.188.97 with SMTP id fz1mr10270282wic.29.1434749951766; Fri, 19 Jun 2015 14:39:11 -0700 (PDT) Received: by 10.28.145.7 with HTTP; Fri, 19 Jun 2015 14:39:11 -0700 (PDT) In-Reply-To: <5584400C.5080406@isi.edu> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> Date: Fri, 19 Jun 2015 23:39:11 +0200 Message-ID: From: Mohamed Oulmahdi To: Joe Touch Content-Type: multipart/alternative; boundary=001a11c38dc03774760518e5c1c4 Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] TCP components 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 Jun 2015 21:39:15 -0000 --001a11c38dc03774760518e5c1c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jun 19, 2015 at 6:15 PM, Joe Touch wrote: > > > On 6/19/2015 6:22 AM, Michael Welzl wrote: > > > > On 19 Jun 2015, at 14:03, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > >> So there current API is always bound to a specify protocol which > >> already provides you a certain set of service feature. At least in > >> TCP there is not much choice left and there the current API does > >> not give us a good indication which services are actually provided > >> by TCP. Therefore from my point of view the only way to identify > >> these services is to look at the protocol itself and not only the > >> API. In SCTP it=E2=80=99s different and we definitely have to and will > >> discuss the existing API in the document. > > > > Exactly that's why I thought starting with TCP's API > > (even when it's the abstract one) is not very helpful. > > > > Joe, Aaron: what is it you were expecting us to take away from > > reading section 3.8 of RFC 793? > > No. IMO, the current description of that API fails to indicate the > controls *already* available to TCP. > > I don't agree that the TCP API doesn't indicate the service TCP provides > - it's just implicit. E.g.: > > OPEN call > indicates TCP is connection oriented > > SEND/RECEIVE calls > indicates TCP is an ordered byte stream, > that the user-level byte boundaries are NOT > related to message boundaries, etc. > > Yes, there's some "reading between the lines" to do here. > Of course, no one use a protocol without knowing the service it offers. When the application requests a TCP connection, it really request a reliable and ordered connection oriented service. The protocols primitives are used to each one to offer a part of this service. The difficulty occurs when several protocols are available, with mainly a certain service overlapping. In this case, exposing Transport services by the protocols offering them is not convenient to applications developers because they must be aware of the several protocols details that are not always evident to some of them. The objective is so simply to change this service exposition from a protocol-based to a service-based, allowing developers to request services without knowing anything about the underlying protocols offering these services. > > > ( I can see it highlighting the need > > to discuss communication patterns (or decide for a specific one) in > > document #2, but not really contributing much to the list in document > > #1 ? ) > > I believe the opposite is true. > > Joe > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a11c38dc03774760518e5c1c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jun 19, 2015 at 6:15 PM, Joe Touch <touch@isi.edu> w= rote:


On 6/19/2015 6:22 AM, Michael Welzl wrote:
>
> On 19 Jun 2015, at 14:03, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wro= te:
>> So there current API is always bound to a = specify protocol which
>> already provides you a certain set of service feature. At least in=
>> TCP there is not much choice left and there the current API does >> not give us a good indication which services are actually provided=
>> by TCP. Therefore from my point of view the only way to identify >> these services is to look at the protocol itself and not only the<= br> >> API. In SCTP it=E2=80=99s different and we definitely have to and = will
>> discuss the existing API in the document.
>
> Exactly that's why I thought starting with TCP's API
> (even when it's the abstract one) is not very helpful.
>
> Joe, Aaron: what is it you were expecting us to take away from
> reading section 3.8 of RFC 793?

No. IMO, the current description of that API fails to indicate the controls *already* available to TCP.

I don't agree that the TCP API doesn't indicate the service TCP pro= vides
- it's just implicit. E.g.:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 OPEN call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indicates TCP is co= nnection oriented

=C2=A0 =C2=A0 =C2=A0 =C2=A0 SEND/RECEIVE calls
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indicates TCP is an= ordered byte stream,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that the user-level= byte boundaries are NOT
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 related to message = boundaries, etc.

Yes, there's some "reading between the lines" to do here.
=


Of course, no one use a pro= tocol without knowing the service it offers. When the application requests = a TCP connection, it really request a reliable and ordered connection orien= ted service. The protocols primitives are used to each one to offer a part = of this service. The difficulty occurs when several protocols are available= , with mainly a certain service overlapping. In this case, exposing Transpo= rt services by the protocols offering them is not convenient to application= s developers because they must be aware of the several protocols details th= at are not always evident to some of them. The objective is so simply to ch= ange this service exposition from a protocol-based to a service-based, allo= wing developers to request services without knowing anything about the unde= rlying protocols offering these services.
=C2=A0

> ( I can see it highlighting the need
> to discuss communication patterns (or decide for a specific one) in > document #2, but not really contributing much to the list in document<= br> > #1 ? )

I believe the opposite is true.

Joe

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--001a11c38dc03774760518e5c1c4-- From nobody Fri Jun 19 15:11:33 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206B81B2B68 for ; Fri, 19 Jun 2015 15:11:32 -0700 (PDT) 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 16MY8gCsUEnF for ; Fri, 19 Jun 2015 15:11:31 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F361B2B63 for ; Fri, 19 Jun 2015 15:11:31 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t5JMBCwG019766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Jun 2015 15:11:16 -0700 (PDT) To: Mohamed Oulmahdi References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> From: Joe Touch Message-ID: <5584937F.2030408@isi.edu> Date: Fri, 19 Jun 2015 15:11:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , "taps@ietf.org" , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Michael Welzl , touch@isi.edu Subject: Re: [Taps] TCP components 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 Jun 2015 22:11:32 -0000 On 6/19/2015 2:39 PM, Mohamed Oulmahdi wrote: > > Of course, no one use a protocol without knowing the service it offers. > When the application requests a TCP connection, it really request a > reliable and ordered connection oriented service. The protocols > primitives are used to each one to offer a part of this service. My point is that the API primitives do define the service offered in this case. You can't use TCP without using OPEN; OPEN exists only because TCP is connection-oriented. Similarly, SEND/RECEIVE are handled in-order and the byte order within each call is preserved - which indicates that this is a byte stream service. The lack of boundary marking within the SEND/RECEIVE calls - and the indication that SEND/RECEIVE block boundaries are not preserved - indicates that this is a byte stream service with no internal boundaries. All of this can be gleaned from the API in section 3.8 of RFC 793. > The > difficulty occurs when several protocols are available, with mainly a > certain service overlapping. You're getting far ahead of the conversation, IMO. This document needs to start by explaining the services we already have before jumping into a "service of services" model. I don't disagree with the goal, but it's impractical to develop a meta-interface when the base interface has not been described. Joe From nobody Fri Jun 19 15:42:57 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE401A6F1E for ; Fri, 19 Jun 2015 15:42:55 -0700 (PDT) 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 kytmalkwDzrh for ; Fri, 19 Jun 2015 15:42:54 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE7D1A1B2D for ; Fri, 19 Jun 2015 15:42:54 -0700 (PDT) Received: by wicgi11 with SMTP id gi11so30296818wic.0 for ; Fri, 19 Jun 2015 15:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5PO8rwyLBEez2Kbn06nSCxD756f0UceOhhaqH908FSo=; b=B37TLF6BU8yFN/VDpdl9xFmvo/vlKynI+fewxPax1NxSkrU7Lsmh+CPPvyiWw8IEnB E/wMtJeoyIO7YMKqjjEQRhoh05F+zWVfjaXeyAGHpCSjOxcK05UV51JXUbXMv6jbJ0ms cifM8shIuvQ2Hi5ELLPGiFVPv53PMmqRzVm0KjPoih1zHNNQdNtokfyeBqXYTdM7ZcGj lSTceDKUU+O75G5ibFfsi8cmhskqxm3XGOfsm3T+FPVyUPsU5sFXukUFWhZHFSdO8EM+ Gw65xeWjVHNUUL/s40iU7vgFBQI/vmf67QwRgrXLqitGLY5ncPTe+LghiAT3VE83bJgG Tasg== MIME-Version: 1.0 X-Received: by 10.180.19.100 with SMTP id d4mr10636695wie.29.1434753773048; Fri, 19 Jun 2015 15:42:53 -0700 (PDT) Received: by 10.28.145.7 with HTTP; Fri, 19 Jun 2015 15:42:52 -0700 (PDT) In-Reply-To: <5584937F.2030408@isi.edu> References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> <5584937F.2030408@isi.edu> Date: Sat, 20 Jun 2015 00:42:52 +0200 Message-ID: From: Mohamed Oulmahdi To: Joe Touch Content-Type: multipart/alternative; boundary=bcaec53d5c63fb96e80518e6a4dc Archived-At: Cc: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] TCP components 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 Jun 2015 22:42:56 -0000 --bcaec53d5c63fb96e80518e6a4dc Content-Type: text/plain; charset=UTF-8 On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch wrote: > > You're getting far ahead of the conversation, IMO. This document needs to > start by explaining the services we already have before jumping into a > "service of services" model. > > I don't disagree with the goal, but it's impractical to develop a > meta-interface when the base interface has not been described. It is just to say that TCP already defines its services, and the goal is not to give another definition of these services, but only to change the way they are exposed to applications. So the services definition already exists, but implicitly. > > > Joe > --bcaec53d5c63fb96e80518e6a4dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch <touch@isi.edu> = wrote:

 You're getting far ahead of the conversation, IMO. This document needs = to start by explaining the services we already have before jumping into a &= quot;service of services" model.

I don't disagree with the goal, but it's impractical to develop a m= eta-interface when the base interface has not been described.
<= div>
It is just to say that TCP already defines its services,= and the goal is not to give another definition of these services, but only= to change the way they are exposed to applications. So the services defini= tion already exists, but implicitly.


Joe

--bcaec53d5c63fb96e80518e6a4dc-- From nobody Fri Jun 19 15:55:45 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D9E1A8785 for ; Fri, 19 Jun 2015 15:55:43 -0700 (PDT) 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 SoLynFvDX-lU for ; Fri, 19 Jun 2015 15:55:42 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A2C31A7D83 for ; Fri, 19 Jun 2015 15:55:42 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t5JMt2P0029697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 19 Jun 2015 15:55:03 -0700 (PDT) To: Mohamed Oulmahdi References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> <5584937F.2030408@isi.edu> From: Joe Touch Message-ID: <55849DC5.7040600@isi.edu> Date: Fri, 19 Jun 2015 15:55:01 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Brian Trammell , "taps@ietf.org" , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Michael Welzl , touch@isi.edu Subject: Re: [Taps] TCP components 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 Jun 2015 22:55:43 -0000 On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote: > > > On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch > wrote: > > > You're getting far ahead of the conversation, IMO. This document > needs to start by explaining the services we already have before > jumping into a "service of services" model. > > I don't disagree with the goal, but it's impractical to develop a > meta-interface when the base interface has not been described. > > > It is just to say that TCP already defines its services, and the goal is > not to give another definition of these services, but only to change the > way they are exposed to applications. So the services definition already > exists, but implicitly. It's explicit - see section 3.8 of RFC 793. The issue with that variant is that it captures the state of TCP in 1981; it has evolved quite a bit since then. Although we do have a 793-bis in the works, the update of that section hasn't been tackled yet. Let's put it this way: - if the goal of TAPS is to unify existing APIs, then those APIs need to be summarized together in one place - if TAPS is indeed focused solely on an alternate API, then it should NOT try to 'restate' the existing TCP API in a TAPS doc "Do, or do not; there is no try." - Yoda Joe From nobody Sat Jun 20 01:35:53 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F2B1B2DFE for ; Sat, 20 Jun 2015 01:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, 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 sHjUkRCWKELT for ; Sat, 20 Jun 2015 01:35:50 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6751B2DFC for ; Sat, 20 Jun 2015 01:35:50 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z6EFT-00068b-7h; Sat, 20 Jun 2015 10:35:35 +0200 Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Z6EFS-0001Px-KZ; Sat, 20 Jun 2015 10:35:35 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <55849DC5.7040600@isi.edu> Date: Sat, 20 Jun 2015 10:35:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> <5584937F.2030408@isi.edu> <55849DC5.7040600@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 5 sum rcpts/h 14 sum msgs/h 5 total rcpts 30299 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3B03DD379883A6DE05EE6A027F7D204133E03D00 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 1231 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Mohamed Oulmahdi , "taps@ietf.org" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell Subject: Re: [Taps] TCP components 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 Jun 2015 08:35:52 -0000 > On 20. jun. 2015, at 00.55, Joe Touch wrote: >=20 >=20 >=20 > On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote: >>=20 >>=20 >> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch > > wrote: >>=20 >>=20 >> You're getting far ahead of the conversation, IMO. This document >> needs to start by explaining the services we already have before >> jumping into a "service of services" model. >>=20 >> I don't disagree with the goal, but it's impractical to develop a >> meta-interface when the base interface has not been described. >>=20 >>=20 >> It is just to say that TCP already defines its services, and the goal = is >> not to give another definition of these services, but only to change = the >> way they are exposed to applications. So the services definition = already >> exists, but implicitly. >=20 > It's explicit - see section 3.8 of RFC 793. The issue with that = variant is that it captures the state of TCP in 1981; it has evolved = quite a bit since then. Although we do have a 793-bis in the works, the = update of that section hasn't been tackled yet. >=20 > Let's put it this way: >=20 > - if the goal of TAPS is to unify existing APIs, > then those APIs need to be summarized together in one place >=20 >=20 > - if TAPS is indeed focused solely on an alternate API, > then it should NOT try to 'restate' the existing TCP API > in a TAPS doc >=20 > "Do, or do not; there is no try." > - Yoda TAPS is focused on an alternate API that it's based on existing = transports. As a way of analyzing existing transports and creating a = foundation for this API, document #1 is written. I think this discussion = is about the approach taken to write document #1. So now I wonder what you're complaining about, as you go on about TCP = already defining its services implicitly in the API. I mean, yes it = does, okay - and so? You criticized the SCTP API for not being abstract = enough - so clearly if we'd just copy+paste the API descriptions of the = RFCs of the considered transports in a list, that would look pretty = messy. You seem to want a "clean" approach, but you're not going to get = that unless we focus on TCP alone :-) I've been proposing go through transport APIs and then analyze what we = have, because this way, SCTP is already going to give us a long list of = services. You've been saying that we should start with TCP. Well okay, but the = service list there is pretty narrow. Maybe the TCP API isn't properly = described in the current draft, okay, I think we can take that criticism = for what it is. Still, I don't know what you're really after - in the = end, we're going to get a list that's pretty similar to what's there = now, and that's what we want, right? - unordered reliable delivery of messages - delivery of messages with timed delivery - reliable delivery of a data stream (naturally that's ordered) .... and so on. Right? Or what else is it you want / expect?=20 Cheers, Michael From nobody Sat Jun 20 02:51:08 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134111A014E for ; Sat, 20 Jun 2015 02:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, 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 upk9fgpYcFNW for ; Sat, 20 Jun 2015 02:51:04 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6CE1A0158 for ; Sat, 20 Jun 2015 02:51:04 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so84578193lbb.3 for ; Sat, 20 Jun 2015 02:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=UvNRiORFkAhp2VIDxGlTnQlQpIBmIGpfZ8P63FfBa8I=; b=NR5soXhmEp+had903vtrDuCShhO1B5ZdsmEiNlApnZ+QT/kO8k2oECvDyzntF8ALqB f2is//6KDzpeyKm9s0OkxViPJ5lBHIW6RcS2TDKa1AMLEaIPRxd+wGXhioSooQ2J0XzF LRGk+/xziqHpfp6isGByXUBBKhDDRRmC1rZIbvU4+toUedIlJ6Oy8IYAGFhq3KhZ3Pmf p2rJ7XIc/S7JIaifKYMZ3sKHzo1MrKmOCUR+YP3kssVwbm9jgrvKSVxmnwy3wlBxVVQx jQ7sclDljmjRbvjB8OxkBT8ar7brtDTT+6HkrDzsQb768pZbZbw4WY/6mV59oP/KovsO Fk7A== MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr21547259laj.123.1434793862443; Sat, 20 Jun 2015 02:51:02 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.25.140.134 with HTTP; Sat, 20 Jun 2015 02:51:02 -0700 (PDT) In-Reply-To: References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> <5584937F.2030408@isi.edu> <55849DC5.7040600@isi.edu> Date: Sat, 20 Jun 2015 10:51:02 +0100 X-Google-Sender-Auth: GgP5RLcZ1cOajZwucdC71kfnkQg Message-ID: From: Jon Crowcroft To: Michael Welzl Content-Type: multipart/alternative; boundary=089e0158ba0a7f3ba90518effa73 Archived-At: Cc: Brian Trammell , Mohamed Oulmahdi , "taps@ietf.org" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Joe Touch Subject: Re: [Taps] TCP components 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 Jun 2015 09:51:07 -0000 --089e0158ba0a7f3ba90518effa73 Content-Type: text/plain; charset=UTF-8 i dont have any spare time to do it, but maybe someone could have a go at analyzing all the different TCP offload techniques, which would give another lens to view this through... On Sat, Jun 20, 2015 at 9:35 AM, Michael Welzl wrote: > > > On 20. jun. 2015, at 00.55, Joe Touch wrote: > > > > > > > > On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote: > >> > >> > >> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch >> > wrote: > >> > >> > >> You're getting far ahead of the conversation, IMO. This document > >> needs to start by explaining the services we already have before > >> jumping into a "service of services" model. > >> > >> I don't disagree with the goal, but it's impractical to develop a > >> meta-interface when the base interface has not been described. > >> > >> > >> It is just to say that TCP already defines its services, and the goal is > >> not to give another definition of these services, but only to change the > >> way they are exposed to applications. So the services definition already > >> exists, but implicitly. > > > > It's explicit - see section 3.8 of RFC 793. The issue with that variant > is that it captures the state of TCP in 1981; it has evolved quite a bit > since then. Although we do have a 793-bis in the works, the update of that > section hasn't been tackled yet. > > > > Let's put it this way: > > > > - if the goal of TAPS is to unify existing APIs, > > then those APIs need to be summarized together in one place > > > > > > - if TAPS is indeed focused solely on an alternate API, > > then it should NOT try to 'restate' the existing TCP API > > in a TAPS doc > > > > "Do, or do not; there is no try." > > - Yoda > > TAPS is focused on an alternate API that it's based on existing > transports. As a way of analyzing existing transports and creating a > foundation for this API, document #1 is written. I think this discussion is > about the approach taken to write document #1. > > So now I wonder what you're complaining about, as you go on about TCP > already defining its services implicitly in the API. I mean, yes it does, > okay - and so? You criticized the SCTP API for not being abstract enough - > so clearly if we'd just copy+paste the API descriptions of the RFCs of the > considered transports in a list, that would look pretty messy. You seem to > want a "clean" approach, but you're not going to get that unless we focus > on TCP alone :-) > > I've been proposing go through transport APIs and then analyze what we > have, because this way, SCTP is already going to give us a long list of > services. > You've been saying that we should start with TCP. Well okay, but the > service list there is pretty narrow. Maybe the TCP API isn't properly > described in the current draft, okay, I think we can take that criticism > for what it is. Still, I don't know what you're really after - in the end, > we're going to get a list that's pretty similar to what's there now, and > that's what we want, right? > > - unordered reliable delivery of messages > - delivery of messages with timed delivery > - reliable delivery of a data stream (naturally that's ordered) > > .... and so on. Right? Or what else is it you want / expect? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --089e0158ba0a7f3ba90518effa73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
i dont have any spare time to do it, but maybe someone cou= ld have a go at analyzing all the different TCP offload techniques, which w= ould give another lens to view this through...

On Sat, Jun 20, 2015 at 9:35 AM, Michael= Welzl <michawe@ifi.uio.no> wrote:

> On 20. jun. 2015, at 00.55, Joe Touch <touch@isi.edu> wrote:
>
>
>
> On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
>>
>>
>> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch <touch@isi.edu
>> <mailto:touch@isi.edu>&= gt; wrote:
>>
>>
>>=C2=A0 =C2=A0 You're getting far ahead of the conversation, IMO= . This document
>>=C2=A0 =C2=A0 needs to start by explaining the services we already = have before
>>=C2=A0 =C2=A0 jumping into a "service of services" model.=
>>
>>=C2=A0 =C2=A0 I don't disagree with the goal, but it's impr= actical to develop a
>>=C2=A0 =C2=A0 meta-interface when the base interface has not been d= escribed.
>>
>>
>> It is just to say that TCP already defines its services, and the g= oal is
>> not to give another definition of these services, but only to chan= ge the
>> way they are exposed to applications. So the services definition a= lready
>> exists, but implicitly.
>
> It's explicit - see section 3.8 of RFC 793. The issue with that va= riant is that it captures the state of TCP in 1981; it has evolved quite a = bit since then. Although we do have a 793-bis in the works, the update of t= hat section hasn't been tackled yet.
>
> Let's put it this way:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- if the goal of TAPS is to unify existing A= PIs,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0then those APIs need to be summarized togeth= er in one place
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- if TAPS is indeed focused solely on an alt= ernate API,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0then it should NOT try to 'restate' = the existing TCP API
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in a TAPS doc
>
> "Do, or do not; there is no try."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- Yoda

TAPS is focused on an alternate API that it's based on exis= ting transports. As a way of analyzing existing transports and creating a f= oundation for this API, document #1 is written. I think this discussion is = about the approach taken to write document #1.

So now I wonder what you're complaining about, as you go on about TCP a= lready defining its services implicitly in the API. I mean, yes it does, ok= ay - and so?=C2=A0 You criticized the SCTP API for not being abstract enoug= h - so clearly if we'd just copy+paste the API descriptions of the RFCs= of the considered transports in a list, that would look pretty messy. You = seem to want a "clean" approach, but you're not going to get = that unless we focus on TCP alone=C2=A0 :-)

I've been proposing go through transport APIs and then analyze what we = have, because this way, SCTP is already going to give us a long list of ser= vices.
You've been saying that we should start with TCP. Well okay, but the se= rvice list there is pretty narrow. Maybe the TCP API isn't properly des= cribed in the current draft, okay, I think we can take that criticism for w= hat it is. Still, I don't know what you're really after - in the en= d, we're going to get a list that's pretty similar to what's th= ere now, and that's what we want, right?

- unordered reliable delivery of messages
- delivery of messages with timed delivery
- reliable delivery of a data stream (naturally that's ordered)

.... and so on. Right? Or what else is it you want / expect?

Cheers,
Michael

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

--089e0158ba0a7f3ba90518effa73-- From nobody Sat Jun 20 10:33:39 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFD51A89C4 for ; Sat, 20 Jun 2015 10:33:37 -0700 (PDT) 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 JnWLMHJBCsNP for ; Sat, 20 Jun 2015 10:33:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDF1B1A89B5 for ; Sat, 20 Jun 2015 10:33:34 -0700 (PDT) Received: from [192.168.1.10] (pool-71-108-123-251.lsanca.dsl-w.verizon.net [71.108.123.251]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t5KHWcvc005388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 Jun 2015 10:32:39 -0700 (PDT) To: Michael Welzl References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> <5584937F.2030408@isi.edu> <55849DC5.7040600@isi.edu> From: Joe Touch Message-ID: <5585A3B5.5030702@isi.edu> Date: Sat, 20 Jun 2015 10:32:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Mohamed Oulmahdi , "taps@ietf.org" , Brian Trammell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , touch@isi.edu Subject: Re: [Taps] TCP components 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 Jun 2015 17:33:38 -0000 Michael, On 6/20/2015 1:35 AM, Michael Welzl wrote: > >> On 20. jun. 2015, at 00.55, Joe Touch wrote: >> >> On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote: ... >> Let's put it this way: >> >> - if the goal of TAPS is to unify existing APIs, >> then those APIs need to be summarized together in one place >> >> >> - if TAPS is indeed focused solely on an alternate API, >> then it should NOT try to 'restate' the existing TCP API >> in a TAPS doc >> >> "Do, or do not; there is no try." >> - Yoda > > TAPS is focused on an alternate API that it's based on existing > transports. As a way of analyzing existing transports and creating > a foundation for this API, document #1 is written. I think this > discussion is about the approach taken to write document #1. > > So now I wonder what you're complaining about, I'm trying to get Mohamed (and perhaps others) on the same page as you and I. Joe From nobody Sat Jun 20 19:37:24 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9101A90C2 for ; Sat, 20 Jun 2015 19:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] 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 Zu6bigBKU0J8 for ; Sat, 20 Jun 2015 19:37:21 -0700 (PDT) Received: from atl4mhob03.myregisteredsite.com (atl4mhob03.myregisteredsite.com [209.17.115.41]) by ietfa.amsl.com (Postfix) with ESMTP id 900A11A90BF for ; Sat, 20 Jun 2015 19:37:21 -0700 (PDT) Received: from mailpod.hostingplatform.com ([10.30.71.204]) by atl4mhob03.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id t5L2bJBM027790 for ; Sat, 20 Jun 2015 22:37:19 -0400 Received: (qmail 23761 invoked by uid 0); 21 Jun 2015 02:37:19 -0000 X-TCPREMOTEIP: 69.81.157.169 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.1.112?) (wes@mti-systems.com@69.81.157.169) by 0 with ESMTPA; 21 Jun 2015 02:37:19 -0000 Message-ID: <55862358.2060608@mti-systems.com> Date: Sat, 20 Jun 2015 22:37:12 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Joe Touch , Mohamed Oulmahdi References: <5579768E.5060402@tik.ee.ethz.ch> <154FD7B7-9A01-43EC-927D-B9D71F1BC38D@tik.ee.ethz.ch> <57DC7DAB-7054-41BE-8515-626353782BBC@ifi.uio.no> <5581B81B.4090500@isi.edu> <725D4141-40AB-4E30-9409-96813C80905B@tik.ee.ethz.ch> <33CA72C2-D0EC-43A1-B766-D34F3636961B@ifi.uio.no> <23AACB56-2044-4E89-930B-C7D501AD7184@tik.ee.ethz.ch> <5584400C.5080406@isi.edu> <5584937F.2030408@isi.edu> <55849DC5.7040600@isi.edu> In-Reply-To: <55849DC5.7040600@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: Brian Trammell , =?windows-1252?Q?Mirja_K=FChlewind?= , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] TCP components 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: Sun, 21 Jun 2015 02:37:22 -0000 On 6/19/2015 6:55 PM, Joe Touch wrote: > It's explicit - see section 3.8 of RFC 793. The issue with that variant > is that it captures the state of TCP in 1981; it has evolved quite a bit > since then. Although we do have a 793-bis in the works, the update of > that section hasn't been tackled yet. I'm not sure that it will be tackled, but we should discuss that on the TCPM list :). Since there are no newer RFCs that alter, deprecate, or replace that API, I don't think we have a good basis to change it in 793bis. It's still pretty reasonable in my opinion. -- Wes Eddy MTI Systems From nobody Fri Jun 26 00:21:47 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8781B34AC for ; Fri, 26 Jun 2015 00:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbKnAWAJvhqV for ; Fri, 26 Jun 2015 00:21:43 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53B0B1B34A8 for ; Fri, 26 Jun 2015 00:21:43 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z8NxF-0007TW-K5 for taps@ietf.org; Fri, 26 Jun 2015 09:21:41 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80.1) (envelope-from ) id 1Z8NxE-0004iC-S1; Fri, 26 Jun 2015 09:21:41 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Michael Welzl Date: Fri, 26 Jun 2015 09:21:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32F6B230-8614-47AB-9D05-5B4CD5490322@ifi.uio.no> References: <20150622123743.10608.86417.idtracker@ietfa.amsl.com> To: taps WG X-Mailer: Apple Mail (2.2098) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 13 sum msgs/h 6 total rcpts 30429 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6765F20C64340D61291FDE986BD49CBF01A4A468 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 99990 minaction 1 bait 0 mail/h: 5 total 7371 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Stein Gjessing Subject: [Taps] Fwd: New Version Notification for draft-gjessing-taps-minset-00.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, 26 Jun 2015 07:21:45 -0000 Dear all, This is a very first stab at a draft addressing the charter's second = item - the minimal set of transport services that end systems should = support. It is based on version 4 of draft-ietf-taps-transports, so the list of = features / components is not up to date - but that's not really the main = point of the document for now anyway: it's about showing how the number of exposed services *could* be = reduced. Our hope is that, by sketching the possible destination of our = journey, this helps the current discussion of the first document. Cheers, Michael > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-gjessing-taps-minset-00.txt > Date: 22 Jun 2015 14:37:43 CEST > To: Michael Welzl , Stein Gjessing = , Stein Gjessing , Michael Welzl = > Resent-From: >=20 >=20 > A new version of I-D, draft-gjessing-taps-minset-00.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-gjessing-taps-minset > Revision: 00 > Title: A Minimal Set of Transport Services for TAPS = Systems > Document date: 2015-06-22 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-00.txt > Status: = https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ > Htmlized: = https://tools.ietf.org/html/draft-gjessing-taps-minset-00 >=20 >=20 > Abstract: > This draft will eventually recommend a minimal set of IETF Transport > Services offered by end systems supporting TAPS, and give guidance = on > choosing among the available mechanisms and protocols. As a = starting > point for discussion, it currently only gives an overview of some > ways to categorize the set of transport services in the first TAPS > document (version 4: draft-ietf-taps-transports-04), assuming that > the eventual minimal set of transport services will be based on a > similar form of categorization. >=20 >=20 >=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 > The IETF Secretariat >=20 From nobody Fri Jun 26 02:22:45 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B3D1A1B3C for ; Fri, 26 Jun 2015 02:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 i0vMrWGOueQQ for ; Fri, 26 Jun 2015 02:22:41 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id C58521A1B2E for ; Fri, 26 Jun 2015 02:22:41 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 888831B001BE; Fri, 26 Jun 2015 10:22:07 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 26 Jun 2015 10:21:31 +0100 Message-ID: <734fb5eae22df80e67a71fde5ad74204.squirrel@erg.abdn.ac.uk> Date: Fri, 26 Jun 2015 10:21:31 +0100 From: gorry@erg.abdn.ac.uk To: taps@ietf.org 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: Cc: stein@ifi.uio.no, michawe@ifi.uio.no Subject: [Taps] Comments on draft-gjessing-taps-minset-00 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, 26 Jun 2015 09:22:43 -0000 Thanks for submitting this. I like the idea of trying to get a handle on the minimal transport services that TAPS can support. Detailed comments on: https://tools.ietf.org/html/draft-gjessing-taps-minset-00 In Section 1: I think the word "non-functional" is a little awkward, since it suggests "dysfunctional" and we probably should seek a different word for clarity. In Section 3: My initial comments are on the list of features (this may have to be fed back to the 1st TAPS ID, but it is more clear here at the moment, so I'll comment here and see what people think: o unicast: TCP SCTP UDP-Lite DCCP NORM - Add UDP-Lite o IPv6 multicast and anycast: UDP - Add UDP-Lite o multicast: NORM - ??? Is this reliable, the multicast part includes UDP, UDP-Lite (as non-reliable) o unidirectional: UDP - Add UDP-Lite o bidirectional: TCP - Add DCCP, SCTP o IPv6 jumbograms: UDP - Add UDP-Lite o 2-tuple endpoints: UDP - Add UDP-Lite o error detection (checksum): TCP UDP - Add UDP-Lite, DCCP o error detection (UDP checksum): NORM -??? I see this is via UDP, but is it a real difference, NORM is only specified over UDP o strong error detection (CRC32C): SCTP - Possible with TCP option, or AUTH or TLS (and possible with UDP/UDP-Lite/DCCP using DTLS o congestion control: TCP SCTP NORM - Add DCCP o no congestion control: UDP - Add UDP-Lite On section 4 I can offer more comments later, but initially I just note that I think the Service Code in DCCP *IS* specified by the Application in the same way that the port is chosen. Gorry From nobody Fri Jun 26 03:07:20 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47881A89D3 for ; Fri, 26 Jun 2015 03:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bigyRxSGJqwT for ; Fri, 26 Jun 2015 03:07:16 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3541A89B5 for ; Fri, 26 Jun 2015 03:07:16 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Z8QXS-0007fX-5A; Fri, 26 Jun 2015 12:07:14 +0200 Received: from 16.79-161-30.customer.lyse.net ([79.161.30.16] helo=[10.0.1.3]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user steing (Exim 4.80) (envelope-from ) id 1Z8QXR-0006lR-JN; Fri, 26 Jun 2015 12:07:14 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Stein Gjessing X-Priority: 3 (Normal) In-Reply-To: <734fb5eae22df80e67a71fde5ad74204.squirrel@erg.abdn.ac.uk> Date: Fri, 26 Jun 2015 12:07:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <734fb5eae22df80e67a71fde5ad74204.squirrel@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1878.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 14022 max rcpts/h 43 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4EB493DBCF95DBA584CF7A019093C383BE763D17 X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 79.161.30.16 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 1516 max/h 32 blacklist 0 greylist 1 ratelimit 0 Archived-At: Cc: taps@ietf.org, Michael Welzl , Stein Gjessing Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00 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, 26 Jun 2015 10:07:19 -0000 Hi Gorry, Thank you very much for your feedback. We will add what you point out that we have missed in Section 3. Some more comments in-line. On 26 Jun 2015, at 11:21, gorry@erg.abdn.ac.uk wrote: >=20 > Thanks for submitting this. I like the idea of trying to get a handle = on > the minimal transport services that TAPS can support. >=20 > Detailed comments on: > https://tools.ietf.org/html/draft-gjessing-taps-minset-00 >=20 > In Section 1: >=20 > I think the word "non-functional" is a little awkward, since it = suggests > "dysfunctional" and we probably should seek a different word for = clarity. You are the english speaking person her, so you are probably right. However =93non-functional=94 has a technical meaning in software design, = and that is what I meant here. See e.g.. = https://en.wikipedia.org/wiki/Functional_requirement >=20 > In Section 3: >=20 > My initial comments are on the list of features (this may have to be = fed > back to the 1st TAPS ID, but it is more clear here at the moment, so = I'll > comment here and see what people think: >=20 > o unicast: TCP SCTP UDP-Lite DCCP NORM > - Add UDP-Lite >=20 > o IPv6 multicast and anycast: UDP > - Add UDP-Lite >=20 > o multicast: NORM > - ??? Is this reliable, the multicast part includes UDP, UDP-Lite (as > non-reliable) I am not sure what you mean here. Does not NORM implement multicast? There is no statement about it being reliable or not (but may be it = should?) >=20 > o unidirectional: UDP > - Add UDP-Lite >=20 > o bidirectional: TCP > - Add DCCP, SCTP >=20 > o IPv6 jumbograms: UDP > - Add UDP-Lite >=20 > o 2-tuple endpoints: UDP > - Add UDP-Lite >=20 > o error detection (checksum): TCP UDP > - Add UDP-Lite, DCCP >=20 > o error detection (UDP checksum): NORM > -??? I see this is via UDP, but is it a real difference, NORM is only > specified over UDP Yes, so if we want to include NORM (or may be we should not in the = initial minimal version?)=20 then we must include that it supports error detection as in UDP (?). >=20 > o strong error detection (CRC32C): SCTP > - Possible with TCP option, or AUTH or TLS (and possible with > UDP/UDP-Lite/DCCP using DTLS >=20 > o congestion control: TCP SCTP NORM > - Add DCCP >=20 > o no congestion control: UDP > - Add UDP-Lite >=20 > On section 4 >=20 > I can offer more comments later, but initially I just note that I = think > the Service Code in DCCP *IS* specified by the Application in the same = way > that the port is chosen. OK, so we have to include this. Cheers, Stein >=20 > Gorry >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 26 03:15:36 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D4A1A8BBD for ; Fri, 26 Jun 2015 03:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vf9uqKTVa_cF for ; Fri, 26 Jun 2015 03:15:32 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 86EAA1A8AFE for ; Fri, 26 Jun 2015 03:15:32 -0700 (PDT) Received: from erg.abdn.ac.uk (galactica.erg.abdn.ac.uk [139.133.210.32]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 401BA1B00139; Fri, 26 Jun 2015 11:14:52 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by erg.abdn.ac.uk with HTTP; Fri, 26 Jun 2015 11:14:23 +0100 Message-ID: In-Reply-To: References: <734fb5eae22df80e67a71fde5ad74204.squirrel@erg.abdn.ac.uk> Date: Fri, 26 Jun 2015 11:14:23 +0100 From: gorry@erg.abdn.ac.uk To: "Stein Gjessing" 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: Cc: gorry@erg.abdn.ac.uk, Stein Gjessing , Michael Welzl , taps@ietf.org Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00 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, 26 Jun 2015 10:15:34 -0000 See in-line, Gorry > Hi Gorry, > > Thank you very much for your feedback. > We will add what you point out that we have missed in Section 3. > > Some more comments in-line. > > On 26 Jun 2015, at 11:21, gorry@erg.abdn.ac.uk wrote: > >> >> Thanks for submitting this. I like the idea of trying to get a handle on >> the minimal transport services that TAPS can support. >> >> Detailed comments on: >> https://tools.ietf.org/html/draft-gjessing-taps-minset-00 >> >> In Section 1: >> >> I think the word "non-functional" is a little awkward, since it suggests >> "dysfunctional" and we probably should seek a different word for >> clarity. > > You are the english speaking person her, so you are probably right. > However “non-functional” has a technical meaning in software design, and > that is what I > meant here. See e.g.. > https://en.wikipedia.org/wiki/Functional_requirement > Yes I see this use, but still wonder if this is the best word. >> >> In Section 3: >> >> My initial comments are on the list of features (this may have to be fed >> back to the 1st TAPS ID, but it is more clear here at the moment, so >> I'll >> comment here and see what people think: >> >> o unicast: TCP SCTP UDP-Lite DCCP NORM >> - Add UDP-Lite >> >> o IPv6 multicast and anycast: UDP >> - Add UDP-Lite >> >> o multicast: NORM >> - ??? Is this reliable, the multicast part includes UDP, UDP-Lite (as >> non-reliable) > > I am not sure what you mean here. Does not NORM implement multicast? > There is no statement about it being reliable or not (but may be it > should?) > What I intended to say was: The set of transports supporting multicast IPv4 or IPv6 is {UDP, UDP-Lite, NORM} And hence NORM supports this over UDP, and adds reliability (in various forms). >> >> o unidirectional: UDP >> - Add UDP-Lite >> >> o bidirectional: TCP >> - Add DCCP, SCTP >> >> o IPv6 jumbograms: UDP >> - Add UDP-Lite >> >> o 2-tuple endpoints: UDP >> - Add UDP-Lite >> >> o error detection (checksum): TCP UDP >> - Add UDP-Lite, DCCP >> >> o error detection (UDP checksum): NORM >> -??? I see this is via UDP, but is it a real difference, NORM is only >> specified over UDP > > Yes, so if we want to include NORM (or may be we should not in the initial > minimal version?) > then we must include that it supports error detection as in UDP (?). > Yes - NORM is over UDP, and hence I think its error *detection* model is the same as UDP. >> >> o strong error detection (CRC32C): SCTP >> - Possible with TCP option, or AUTH or TLS (and possible with >> UDP/UDP-Lite/DCCP using DTLS >> >> o congestion control: TCP SCTP NORM >> - Add DCCP >> >> o no congestion control: UDP >> - Add UDP-Lite >> >> On section 4 >> >> I can offer more comments later, but initially I just note that I think >> the Service Code in DCCP *IS* specified by the Application in the same >> way >> that the port is chosen. > > OK, so we have to include this. > > Cheers, > Stein > >> >> Gorry >> >> >> >> _______________________________________________ >> 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 Jun 26 07:44:19 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379501B300A for ; Fri, 26 Jun 2015 07:44:18 -0700 (PDT) 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 YwBP928252Ki for ; Fri, 26 Jun 2015 07:44:16 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 C147F1B3006 for ; Fri, 26 Jun 2015 07:44:15 -0700 (PDT) Received: from macsimus.itd.nrl.navy.mil (macsimus.itd.nrl.navy.mil [132.250.92.151]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t5QEhcXD005783 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 26 Jun 2015 10:43:38 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0216B530-48FE-4315-AD16-CFBC6F09EB87" From: Brian Adamson X-Priority: 3 (Normal) In-Reply-To: Date: Fri, 26 Jun 2015 10:43:37 -0400 Message-Id: <3C9E35F3-1E24-4D93-A6B5-51CED1586E96@nrl.navy.mil> References: <734fb5eae22df80e67a71fde5ad74204.squirrel@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.2098) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Cc: taps@ietf.org, Michael Welzl , Stein Gjessing Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00 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, 26 Jun 2015 14:44:18 -0000 --Apple-Mail=_0216B530-48FE-4315-AD16-CFBC6F09EB87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes - the error detection for NORM since it rides on top of UDP is the = same as UDP and you would not want to run NORM over UDP-Lite as NORM=92s = use of FEC is for packet erasure filling and not error correction. = I.e., it assumes any messages received are error-free. >>=20 >> Yes, so if we want to include NORM (or may be we should not in the = initial >> minimal version?) >> then we must include that it supports error detection as in UDP (?). >>=20 > Yes - NORM is over UDP, and hence I think its error *detection* model = is > the same as UDP. --Apple-Mail=_0216B530-48FE-4315-AD16-CFBC6F09EB87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Yes - the error detection for NORM since it rides on top = of UDP is the same as UDP and you would not want to run NORM over = UDP-Lite as NORM=92s use of FEC is for packet erasure filling and not = error correction.  I.e., it assumes any messages received are = error-free.


Yes, so if we = want to include NORM (or may be we should not in the initial
minimal version?)
then we must include that it = supports error detection as in UDP (?).

Yes - NORM is over = UDP, and hence I think its error *detection* model is
the same as UDP.

= --Apple-Mail=_0216B530-48FE-4315-AD16-CFBC6F09EB87-- From nobody Fri Jun 26 18:53:49 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64F01A19FA for ; Fri, 26 Jun 2015 18:53:47 -0700 (PDT) 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 r024Q7FnuqOx for ; Fri, 26 Jun 2015 18:53:46 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577F71A19F2 for ; Fri, 26 Jun 2015 18:53:46 -0700 (PDT) Received: by iebrt9 with SMTP id rt9so86209201ieb.2 for ; Fri, 26 Jun 2015 18:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SWzsxQPq1aKO2yy4VpH03WdQA3RCMKx7fbqihu9sYK8=; b=Wvz5Z81n9PXihQBkAjrlvumHJhPVKnrXZzYpUOlVo9FxuogGMgcSDuyF2URYYQei1e u2aw5cqHpFvJg/9JULzjkp+0lVc4vBu4iesFL3wCL7IoGJ0kvlmdIY/atT3bpYTO8aQL CoUdWVvdlmpjFAmlDJ1vh/YfFI0uy69Q8l+6t62teN16zG4C/hpCgozIe1fkrTuEzIjW zQTYAUSizVjRnlFLNKaiE9NSS/j2PPB991JRW9/w1QWv1fhf0V1798ZTScATRxQhS/sN 7oLVbW1KoDH7FecnZxA15eWAoQ8NyWe5XttoEQwZ32+IrrjFJRnL18Nju8uRqGmwrG+7 0SNA== MIME-Version: 1.0 X-Received: by 10.50.117.106 with SMTP id kd10mr1243449igb.24.1435370025717; Fri, 26 Jun 2015 18:53:45 -0700 (PDT) Received: by 10.64.59.225 with HTTP; Fri, 26 Jun 2015 18:53:45 -0700 (PDT) In-Reply-To: <20150626235513.5508.51327.idtracker@ietfa.amsl.com> References: <20150626235513.5508.51327.idtracker@ietfa.amsl.com> Date: Fri, 26 Jun 2015 21:53:45 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=089e0139fb6281165c0519762068 Archived-At: Subject: [Taps] Fwd: taps - Requested session has been scheduled for IETF 93 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, 27 Jun 2015 01:53:47 -0000 --089e0139fb6281165c0519762068 Content-Type: text/plain; charset=UTF-8 ---------- Forwarded message ---------- From: *"IETF Secretariat"* Date: Friday, June 26, 2015 Subject: taps - Requested session has been scheduled for IETF 93 To: smccammon@amsl.com Cc: taps-ads@tools.ietf.org, aaron.falk@gmail.com Dear Stephanie McCammon, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (1:30:00) Thursday, Afternoon Session I 1300-1500 Room Name: Karlin I/II size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: tcpm iccrg tsvwg ippm rmcat aqm tsvarea appsawg apparea Second Priority: httpbis icnrg mptcp nvo3 ppsp tcpinc webpush Third Priority: mmusic tram Special Requests: --------------------------------------------------------- -- Sent from Gmail Mobile --089e0139fb6281165c0519762068 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

---------- Forwarded message ----------
From: "IETF Secr= etariat" <agenda@ietf.org>
Date: Friday, June 26, 2015
Subject: taps - Requested session h= as been scheduled for IETF 93
To: = smccammon@amsl.com
Cc: ta= ps-ads@tools.ietf.org, aaron.fa= lk@gmail.com


Dear Stephanie McCammon,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

taps Session 1 (1:30:00)
=C2=A0 =C2=A0 Thursday, Afternoon Session I 1300-1500
=C2=A0 =C2=A0 Room Name: Karlin I/II size: 125
=C2=A0 =C2=A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name: Transport Services
Area Name: Transport Area
Session Requester: Stephanie McCammon

Number of Sessions: 1
Length of Session(s):=C2=A0 1.5 Hours
Number of Attendees: 80
Conflicts to Avoid:
=C2=A0First Priority: tcpm iccrg tsvwg ippm rmcat aqm tsvarea appsawg appar= ea
=C2=A0Second Priority: httpbis icnrg mptcp nvo3 ppsp tcpinc webpush
=C2=A0Third Priority: mmusic tram


Special Requests:

---------------------------------------------------------




--
Sent from Gmail Mobile
--089e0139fb6281165c0519762068--