From nobody Sun Feb 1 12:48: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 ABA841A8F48 for ; Sun, 1 Feb 2015 12:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 tD3kqJQt1dwM for ; Sun, 1 Feb 2015 12:48:38 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BB11A1B2B for ; Sun, 1 Feb 2015 12:48:37 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YI1RX-0002oe-QO; Sun, 01 Feb 2015 21:48:31 +0100 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 1YI1RX-00075Z-6x; Sun, 01 Feb 2015 21:48:31 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_F8A68FEA-8ABA-4497-8073-948DA0414EDE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: Date: Sun, 1 Feb 2015 21:48:29 +0100 Message-Id: References: To: "gorry@erg.abdn.ac.uk (erg)" 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 1 total rcpts 25468 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 361768482B0AD2D03EE4BEA53D3B49998BD9E783 X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 237 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Wolfgang Beck , =?utf-8?Q?Mirja_K=C3=83=C2=BChlewind?= , taps@ietf.org Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2015 20:48:40 -0000 --Apple-Mail=_F8A68FEA-8ABA-4497-8073-948DA0414EDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1. feb. 2015, at 08.51, gorry@erg.abdn.ac.uk wrote: >=20 >> Would it make sense to include statements about latency? >>=20 > I think if we come to think about the API that could be presented by = TAPS > to the application, we'll need to focus on what characteristics the = Apps > expect from the network. Low latency is clearly one service that many = apps > will desire. Then again, we may decide to reserve this for doc #2? My thinking was that this should be the home of such generalization = (which is one way to reduce the number of services exposed). >> We recently had a discussion with one of our suppliers about = application >> layer timeouts that fired while the request was still stuck in the = send >> queue. >>=20 >> There were statements like 'UDP never queues' or 'we can't control = the TCP >> send buffer size'. >>=20 >> Maybe some general discussion of the interactions between application >> layer >> timers and transport layer retransmission strategies (like Nagle) = would be >> useful. >>=20 > I agree, some words on the Latency introduced by mechanisms would be = good. If you go that way, here=E2=80=99s one of the drafts preceding the BOF, = and written for the purpose of this group, as possible for input: http://tools.ietf.org/html/draft-petlund-latency-transport-services-00 = Cheers, Michael --Apple-Mail=_F8A68FEA-8ABA-4497-8073-948DA0414EDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 1. feb. 2015, at 08.51, gorry@erg.abdn.ac.uk = wrote:

Would it make sense to = include statements about latency?

I think if we come to think about the API that = could be presented by TAPS
to the application, we'll need = to focus on what characteristics the Apps
expect from the = network. Low latency is clearly one service that many apps
will desire.

Then again, we may decide to reserve this for doc = #2?
My thinking was that this should be the home of such = generalization (which is one way to reduce the number of services = exposed).


We recently had a discussion with one of our suppliers about = application
layer timeouts that fired while the request = was still stuck in the send
queue.

There were statements like 'UDP never queues' or 'we can't = control the TCP
send buffer size'.

Maybe some general discussion of the interactions between = application
layer
timers and transport layer = retransmission strategies (like Nagle) would be
useful.

I agree, some words on the = Latency introduced by mechanisms would be good.

If you go = that way, here=E2=80=99s one of the drafts preceding the BOF, and = written for the purpose of this group, as possible for = input:

Cheers,
Michael

= --Apple-Mail=_F8A68FEA-8ABA-4497-8073-948DA0414EDE-- From nobody Mon Feb 2 10:04:23 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E181A8829 for ; Mon, 2 Feb 2015 10:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.711 X-Spam-Level: X-Spam-Status: No, score=-4.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 h6z6palLPSQm for ; Mon, 2 Feb 2015 10:04:19 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268FC1A87B9 for ; Mon, 2 Feb 2015 10:04:19 -0800 (PST) Received: from [128.9.176.28] (c1-vpn2.isi.edu [128.9.176.28]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id t12I3oLa029505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Feb 2015 10:03:50 -0800 (PST) Message-ID: <54CFBC05.40606@isi.edu> Date: Mon, 02 Feb 2015 10:03:49 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Wolfgang Beck , =?windows-1252?Q?Mirj?= =?windows-1252?Q?a_K=FChlewind?= References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed 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] I-D Action: draft-ietf-taps-transports-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:04:21 -0000 On 1/30/2015 7:20 AM, Wolfgang Beck wrote: > Would it make sense to include statements about latency? Yes, but I'm not sure what at this point. Latency is a multidimensional property; it depends on the interaction of a variety of factors, so even if you wanted to have the application say "I want low latency", that's not well-defined. > We recently had a discussion with one of our suppliers about application > layer timeouts that fired while the request was still stuck in the send > queue. > > There were statements like 'UDP never queues' or 'we can't control the > TCP send buffer size'. UDP doesn't queue, but UDP implementations do. The interface between applications and UDP does too. > Maybe some general discussion of the interactions between application > layer timers and transport layer retransmission strategies (like Nagle) > would be useful. That's a really good example of how poorly understood this problem is. Nagle should be off for multi-byte transaction protocols using TCP, but TCP isn't a low-latency protocol to start with. Nagle is as much about minimizing short packets as it is about the effect on transaction interaction delay. However, it's also well-understood that Nagle should be off for transactions involving multiple bytes - whether that's because the transaction itself is larger (e.g., web transactions) or because the character encoding is larger (e.g., telnet using Unicode rather than ASCII). (J. Heidemann, K. Obraczka, J. Touch, “Modeling the Performance of HTTP Over Several Transport Protocols,” IEEE/ACM Transactions on Networking, V5, N5, Oct. 1997, pp.616-630.) The fact that TCP doesn't have a way for the application to signal a transaction boundary (it's a byte stream model) means that the entire issue of latency of transactions over TCP is questionable. -- So, in summary, yes, an API from transport to the service layer should have an indication of latency, but this is a very complex, *bidirectional* interface. So other than saying that this should be addressed in the future, anything said now will be at best woefully incomplete, and at worst, wrong. Joe From nobody Mon Feb 2 12:48: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 08D411A8F35 for ; Mon, 2 Feb 2015 12:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUFZGp5OLfVB for ; Mon, 2 Feb 2015 12:48:52 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BA21A8F34 for ; Mon, 2 Feb 2015 12:48:51 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YINvB-0008Sv-83; Mon, 02 Feb 2015 21:48:37 +0100 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 1YINvA-0000rf-O2; Mon, 02 Feb 2015 21:48:37 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Welzl In-Reply-To: <54CFBC05.40606@isi.edu> Date: Mon, 2 Feb 2015 21:48:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54CFBC05.40606@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2070.6) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 5 sum rcpts/h 12 sum msgs/h 6 total rcpts 25502 max rcpts/h 44 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: 91BCBB76E63F27788E62E00DACBFBAEFA04ABB8D X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 247 max/h 13 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Wolfgang Beck , =?windows-1252?Q?Mirja_K=FChlewind?= , taps@ietf.org Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 20:48:54 -0000 > On 2. feb. 2015, at 19.03, Joe Touch wrote: >=20 >=20 >=20 > On 1/30/2015 7:20 AM, Wolfgang Beck wrote: >> Would it make sense to include statements about latency? >=20 > Yes, but I'm not sure what at this point. >=20 > Latency is a multidimensional property; it depends on the interaction = of a variety of factors, so even if you wanted to have the application = say "I want low latency", that's not well-defined. >=20 >> We recently had a discussion with one of our suppliers about = application >> layer timeouts that fired while the request was still stuck in the = send >> queue. >>=20 >> There were statements like 'UDP never queues' or 'we can't control = the >> TCP send buffer size'. >=20 > UDP doesn't queue, but UDP implementations do. The interface between = applications and UDP does too. >=20 >> Maybe some general discussion of the interactions between application >> layer timers and transport layer retransmission strategies (like = Nagle) >> would be useful. >=20 > That's a really good example of how poorly understood this problem is. >=20 > Nagle should be off for multi-byte transaction protocols using TCP, = but TCP isn't a low-latency protocol to start with. Nagle is as much = about minimizing short packets as it is about the effect on transaction = interaction delay. >=20 > However, it's also well-understood that Nagle should be off for = transactions involving multiple bytes - whether that's because the = transaction itself is larger (e.g., web transactions) or because the = character encoding is larger (e.g., telnet using Unicode rather than = ASCII). (J. Heidemann, K. Obraczka, J. Touch, =93Modeling the = Performance of HTTP Over Several Transport Protocols,=94 IEEE/ACM = Transactions on Networking, V5, N5, Oct. 1997, pp.616-630.) >=20 > The fact that TCP doesn't have a way for the application to signal a = transaction boundary (it's a byte stream model) means that the entire = issue of latency of transactions over TCP is questionable. >=20 > -- >=20 > So, in summary, yes, an API from transport to the service layer should = have an indication of latency, but this is a very complex, = *bidirectional* interface. So other than saying that this should be = addressed in the future, anything said now will be at best woefully = incomplete, and at worst, wrong. I=92m for keeping this first document correct and complete. Cheers, Michael From nobody Mon Feb 2 13:06: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 1F18A1A879A for ; Mon, 2 Feb 2015 13:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 xH6Ylrbywj_h for ; Mon, 2 Feb 2015 13:06:48 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632911A8AE3 for ; Mon, 2 Feb 2015 13:06:41 -0800 (PST) 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 t12L5xJZ006139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Feb 2015 13:05:59 -0800 (PST) Message-ID: <54CFE6B5.20906@isi.edu> Date: Mon, 02 Feb 2015 13:05:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Michael Welzl References: <54CFBC05.40606@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Wolfgang Beck , =?windows-1252?Q?Mirj?= =?windows-1252?Q?a_K=FChlewind?= , taps@ietf.org Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 21:06:52 -0000 On 2/2/2015 12:48 PM, Michael Welzl wrote: >> So, in summary, yes, an API from transport to the service layer >> should have an indication of latency, but this is a very >> complex,*bidirectional* interface. So other than saying that this >> should be addressed in the future, anything said now will be at >> best woefully incomplete, and at worst, wrong. > > I’m for keeping this first document correct and complete. In that case, I suggest that latency issues be listed under "TBD". The only way to deal with them currently is via interfaces that describe HOW an existing mechanism is to be configured, not WHAT the goal of that configuration is. Joe From nobody Wed Feb 4 08:59:52 2015 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337B91A1A54 for ; Wed, 4 Feb 2015 08:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5gdDZ8bj4wf for ; Wed, 4 Feb 2015 08:59:42 -0800 (PST) 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 3DCF11A8F38 for ; Wed, 4 Feb 2015 08:59:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id BC12DD9309; Wed, 4 Feb 2015 17:59:27 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C2P8UaaWPQbd; Wed, 4 Feb 2015 17:59:27 +0100 (MET) 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 6C274D9305; Wed, 4 Feb 2015 17:59:27 +0100 (MET) Message-ID: <54D24FEE.3010904@tik.ee.ethz.ch> Date: Wed, 04 Feb 2015 17:59:26 +0100 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Joe Touch , Brian Trammell , taps WG , Gorry Fairhurst References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <549365CF.7020604@isi.edu> <54CB6F1F.90507@tik.ee.ethz.ch> <54CBDA16.30005@isi.edu> In-Reply-To: <54CBDA16.30005@isi.edu> 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-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 16:59:49 -0000 Hi Joe. see below... On 30.01.2015 20:23, Joe Touch wrote: > Hi, Mirja, > > On 1/30/2015 3:46 AM, Mirja Kühlewind wrote: >> Hi Joe, >> >> I reply to the TCP part in this mail... see below. >> >> On 19.12.2014 00:39, Joe Touch wrote: >>> Some feedback below. Although I focus on some TCP and UDP specifics, >>> some observations apply to other transports as well. >>> >>> Joe >>> >>> ----- >>> >>> 3.1.1 >>> TCP segments fit into IP packets, but those packets are not >>> necessarily constrained to fit into a lower-layer frame. >>> They can be source fragmented. > > >> Yes, but this is handled by IP and not by the transport. Therefore I >> believe that does not need to be mention here...? > > The problem is in the first sentence: > > TCP partitions a continuous stream of bytes into segments, sized to > fit in IP packets, constrained by the maximum size of lower layer > frame. > > The first part is true (TCP fits into IP), but the second is not (IP is > NOT constrained by the max size of the lower-layer frame). IP is > constrained only by the ability of IP (i.e., of L3 to reassemble at the > destination). Okay, I've just removed the second part of the sentence to avoid confusion because it is actually not important in this doc. That's okay for you? > >>> PathMTU discovery is supported by TCP but may be inhibited >>> by network conditions (ICMP blocking); PLMTUD is supposed >>> to be supported as well. > > >> I added PLMTUD separately as well as the respective RFCs for both. >> However, I'm not sure if we actually need to distinguish which mechanism >> is used than rather just saying TCP supports path MTU discovery. (The >> notation in the draft current is PathMTU discovery which references to a >> specific mechanism but that be changes...). > > "Path MTU discovery" is ambiguous; it can refer to any mechanism that > allows the path MTU to be known, or it can refer to the specific > mechanism by that name in RFC 1191. > > If you mean the more general concept, it would be better to use a term > that is unambiguous in referring to both (e.g., discovery of the path > MTU). Once you tie the words together as "path MTU discovery", it could > be misinterpreted as meaning only RFC 1191. > > However, IMO, in this doc it would be better to be more clear and > explicit by naming both mechanisms. K. Done. > > ... >>> 3.1.3 >>> TCP provides a byte-ordered reliable stream. How that >>> is delivered - e.g., by segments - is irrelevant, if only >>> because TCP can change those segment boundaries during >>> operation (e.g., with path MTU updates). > > >> Yes but it is still something that TCP implements as a component. > > TCP definitely does not. There is no required correlation between SEND > boundaries and segment boundaries. > > Some TCP implementations do, but there is nothing to ensure that > boundaries controlled by the sending application are exposed to the > receiving application. > > I don't think this doc should discuss how implementations go astray in > this way. I think this is again a terminology problem. We agreed that a (transport protocol) component is something that a transport protocol implements. I don't think there are any TCP implementations that do not implement segmentation...? So it's a component. A transport feature is something that you would reveal to the application. This is currently not the case and will probably also in future not be the case for segmentation. (However if you would want to reveal it, the functionality is already there you just need a different API...) However, in this document we should still list all TCP components and then add a discussion which of these components should be revealed to the app and in which from. This discussion is not there yet, because I'd like to get the first step right for as much protocols as possible first. Does this make sense to you? > > ... >>> additionally, the ports ought to be discussed in more detail. >>> ports in the SYN have a different meaning that ports in other >>> segments. The SYN destination port indicates the receiving >>> ` service, which typically involves BOTH demuxing to a process >>> within a host AND indicating the format of the stream. Ports >>> there and in all other segments are only demultiplexing >>> indicators. > > >> Added one sentence in section 3.1.1. and extended the connection setup >> up point to >> >> "connection setup with feature negotiation and application-to-port >> mapping" >> >> Does that make sense to you? > > The sentence does, but that doesn't sufficiently (IMO) address the > feedback I gave above. > > TCP has two portions: > - connection establishment > feature negotiation > service-to-port mapping > connection identification > > - established connection data transfer > which continues to use the connection identifier At this point in the document it is not important for me anymore to have in mind with bit in the header is used for with kind of functionality. Therefore being able to identify a connection (or as we named it: 'port multiplexing') is one component while 'connection establishment' is another. As in your list 'connection identification' shows up in both bullets, I'd say it's sensible to list this as an own component. However, 'negotiation' and 'service-to-port mapping' are always bounded to the setup. Therefore it's not an own component. We already discussed if we need a finer granularity than components; Brian has been calling this an aspect... I'm still not convinced that declaring another confusion term will make our life easier... So the only real different that see to what you propose above is that the currently list does not name 'data transfer' as a component. For me that's implicit a task of every transport protocol, so I would name it explicitly. I'd like to leave it as it is for now and will be waiting for further options on this. Mirja > > Joe > > _______________________________________________ > 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 Feb 4 10:39: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 42DD31A1AE3 for ; Wed, 4 Feb 2015 10:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 JniaUpMJZowQ for ; Wed, 4 Feb 2015 10:39:35 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::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 3E2901A1A64 for ; Wed, 4 Feb 2015 10:39:35 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id le20so1148698vcb.3 for ; Wed, 04 Feb 2015 10:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7UgFe3VzNHgatfwETHi2VWa2mKJHnqVjulAz7frQcK8=; b=TH9o/GUznmyAjvTYMw5gYlkUwRMGG3YkC+mEmWvjihoIO7ERtrKz0D8jDgR1oWOp/9 BgtdWEwXesn4JXbGWD4dN/zWqBqrU2VfN+MwE2XYUigcgMUomc+dHhJdJSJu/zHc2rf9 sZhAddiZBR8vGZmpQBAYK50ni6AXsYLkbjar4EjaySXGP4toDQZWwU3VN+5iiu/3CAI9 HZvRu0CsuNTAjwj/zoy5P6n5ZjKmO/iHuS6sq/VA5P++yKdS21FrCMmBMBV1vq8HYW1U wbmwVTy730pbM/KqAb0TcSScVSxvetwVIwrp6TivrcLetRLD6OBTOHwa0KE3WuSNMP0T 9+oA== MIME-Version: 1.0 X-Received: by 10.52.103.75 with SMTP id fu11mr17155665vdb.5.1423075174328; Wed, 04 Feb 2015 10:39:34 -0800 (PST) Received: by 10.52.37.132 with HTTP; Wed, 4 Feb 2015 10:39:34 -0800 (PST) Date: Wed, 4 Feb 2015 13:39:34 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=047d7b86d9904130db050e4782cb Archived-At: Subject: [Taps] agenda topic: application - transport abstractions 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, 04 Feb 2015 18:39:37 -0000 --047d7b86d9904130db050e4782cb Content-Type: text/plain; charset=UTF-8 Thinking about how to make good use of our meeting in Dallas, I'd like to propose we take some time to (re)visit the topic of how applications can express what they want from transports by looking at a few examples and maybe comparing them to what we are coming up with in the TAPS draft. Given all the recent effort, RTCWeb seems like a timely topic and Michael Tuexen has agreed to discuss the abstractions used in the API between the javascript 'user' and the RTCWeb stack. Marie-Jose Montpetite has offered to talk about the needs of some future television applications (multisource video/TV). Sound interesting? Useful? Have another application to talk about? --aaron --047d7b86d9904130db050e4782cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thinking about how to make good use of our meeting in Dall= as, I'd like to propose we take some time to (re)visit the topic of how= applications can express what they want from transports by looking at a fe= w examples and maybe comparing them to what we are coming up with in the TA= PS draft.

Given all the recent effort, RTCWeb seems like= a timely topic and Michael Tuexen has agreed to discuss the abstractions u= sed in the API between the javascript 'user' and the RTCWeb stack.= =C2=A0 Marie-Jose Montpetite has offered to talk about the needs of some fu= ture television applications (multisource video/TV).

Sound interesting? Useful?=C2=A0 Have another application to talk about?=

--aaron
--047d7b86d9904130db050e4782cb-- From nobody Wed Feb 4 10:44: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 DD0E11A1B0A for ; Wed, 4 Feb 2015 10:44:34 -0800 (PST) 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 9sQvVQCOX1DJ for ; Wed, 4 Feb 2015 10:44:32 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6E91A0155 for ; Wed, 4 Feb 2015 10:44:32 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id t14Ihb3G015533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Feb 2015 10:43:43 -0800 (PST) Message-ID: <54D26859.8070701@isi.edu> Date: Wed, 04 Feb 2015 10:43:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , Brian Trammell , taps WG , Gorry Fairhurst References: <20141218140655.20397.13028.idtracker@ietfa.amsl.com> <549365CF.7020604@isi.edu> <54CB6F1F.90507@tik.ee.ethz.ch> <54CBDA16.30005@isi.edu> <54D24FEE.3010904@tik.ee.ethz.ch> In-Reply-To: <54D24FEE.3010904@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-01.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 18:44:35 -0000 Hi, Mirja, On 2/4/2015 8:59 AM, Mirja Kühlewind wrote: > Hi Joe. > > see below... > > On 30.01.2015 20:23, Joe Touch wrote: >> Hi, Mirja, >> >> On 1/30/2015 3:46 AM, Mirja Kühlewind wrote: >>> Hi Joe, >>> >>> I reply to the TCP part in this mail... see below. >>> >>> On 19.12.2014 00:39, Joe Touch wrote: >>>> Some feedback below. Although I focus on some TCP and UDP specifics, >>>> some observations apply to other transports as well. >>>> >>>> Joe >>>> >>>> ----- >>>> >>>> 3.1.1 >>>> TCP segments fit into IP packets, but those packets are not >>>> necessarily constrained to fit into a lower-layer frame. >>>> They can be source fragmented. >> > >>> Yes, but this is handled by IP and not by the transport. Therefore I >>> believe that does not need to be mention here...? >> >> The problem is in the first sentence: >> >> TCP partitions a continuous stream of bytes into segments, sized to >> fit in IP packets, constrained by the maximum size of lower layer >> frame. >> >> The first part is true (TCP fits into IP), but the second is not (IP is >> NOT constrained by the max size of the lower-layer frame). IP is >> constrained only by the ability of IP (i.e., of L3 to reassemble at the >> destination). > > Okay, I've just removed the second part of the sentence to avoid > confusion because it is actually not important in this doc. That's okay > for you? Sure. >>>> PathMTU discovery is supported by TCP but may be inhibited >>>> by network conditions (ICMP blocking); PLMTUD is supposed >>>> to be supported as well. >> > >>> I added PLMTUD separately as well as the respective RFCs for both. >>> However, I'm not sure if we actually need to distinguish which mechanism >>> is used than rather just saying TCP supports path MTU discovery. (The >>> notation in the draft current is PathMTU discovery which references to a >>> specific mechanism but that be changes...). >> >> "Path MTU discovery" is ambiguous; it can refer to any mechanism that >> allows the path MTU to be known, or it can refer to the specific >> mechanism by that name in RFC 1191. >> >> If you mean the more general concept, it would be better to use a term >> that is unambiguous in referring to both (e.g., discovery of the path >> MTU). Once you tie the words together as "path MTU discovery", it could >> be misinterpreted as meaning only RFC 1191. >> >> However, IMO, in this doc it would be better to be more clear and >> explicit by naming both mechanisms. > > K. Done. > >> >> ... >>>> 3.1.3 >>>> TCP provides a byte-ordered reliable stream. How that >>>> is delivered - e.g., by segments - is irrelevant, if only >>>> because TCP can change those segment boundaries during >>>> operation (e.g., with path MTU updates). >> > >>> Yes but it is still something that TCP implements as a component. >> >> TCP definitely does not. There is no required correlation between SEND >> boundaries and segment boundaries. >> >> Some TCP implementations do, but there is nothing to ensure that >> boundaries controlled by the sending application are exposed to the >> receiving application. >> >> I don't think this doc should discuss how implementations go astray in >> this way. > > I think this is again a terminology problem. We agreed that a (transport > protocol) component is something that a transport protocol implements. I > don't think there are any TCP implementations that do not implement > segmentation...? So it's a component. TAPS describes the services that transports provide to applications (as per the charter). The details of how that service is implemented internally are not relevant because they're not exported as part of that service interface. Although TCP uses segments to talk to other TCPs, TCP is not required to export or import the segment boundary to the application. > A transport feature is something that you would reveal to the > application. A transport feature is something you *can* reveal to the application. The spec for TCP allows implementations to segment data in different ways and still interconnect just fine. > This is currently not the case and will probably also in > future not be the case for segmentation. (However if you would want to > reveal it, the functionality is already there you just need a different > API...) You need a different protocol. E.g., if TCP is sending 1000B segments and learns new information about the path MTU, it can retransmit lost data using the new MTU. Similar changes in segment boundaries can occur if a small segment is sent (because of a timeout waiting for new data) and the data from that small segment is retransmitted after new data arrives, i.e., the retransmission might end up being a larger overlapping region. > However, in this document we should still list all TCP components and > then add a discussion which of these components should be revealed to > the app and in which from. RFC793 defines TCP's API. The rest of RFC793 describes how TCP interacts with other TCPs, not the API. Please don't confuse the two. The latter is not an opportunity to augment the former. >> ... >>>> additionally, the ports ought to be discussed in more detail. >>>> ports in the SYN have a different meaning that ports in other >>>> segments. The SYN destination port indicates the receiving >>>> ` service, which typically involves BOTH demuxing to a process >>>> within a host AND indicating the format of the stream. Ports >>>> there and in all other segments are only demultiplexing >>>> indicators. >> > >>> Added one sentence in section 3.1.1. and extended the connection setup >>> up point to >>> >>> "connection setup with feature negotiation and application-to-port >>> mapping" >>> >>> Does that make sense to you? >> >> The sentence does, but that doesn't sufficiently (IMO) address the >> feedback I gave above. >> >> TCP has two portions: >> - connection establishment >> feature negotiation >> service-to-port mapping >> connection identification >> >> - established connection data transfer >> which continues to use the connection identifier > > At this point in the document it is not important for me anymore to have > in mind with bit in the header is used for with kind of functionality. I said nothing about the header. Again, I'm referring to the API defined in RFC793. > Therefore being able to identify a connection (or as we named it: 'port > multiplexing') is one component It's socket multiplexing, where socket is defined in RFC793 as the local IP/port pair. > while 'connection establishment' is > another. Agreed. That's negotiation of service parameters, including whether there's a service at all. > As in your list 'connection identification' shows up in both > bullets, I'd say it's sensible to list this as an own component. > However, 'negotiation' and 'service-to-port mapping' are always bounded > to the setup. Therefore it's not an own component. But those two items are very tightly related too, i.e., there's no way (in current TCP) to decouple the service-to-port mapping' from the negotiation of the socket pair during connection establishment. (see http://datatracker.ietf.org/doc/draft-touch-tcpm-sno/ for a proposed extension that would decouple the two) Joe > We already discussed > if we need a finer granularity than components; Brian has been calling > this an aspect... I'm still not convinced that declaring another > confusion term will make our life easier... > > So the only real different that see to what you propose above is that > the currently list does not name 'data transfer' as a component. For me > that's implicit a task of every transport protocol, so I would name it > explicitly. > > I'd like to leave it as it is for now and will be waiting for further > options on this. > > Mirja > > > > >> >> Joe >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > From nobody Wed Feb 4 14:55: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 689181A8947 for ; Wed, 4 Feb 2015 14:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 vTvZ_PsOtrQR for ; Wed, 4 Feb 2015 14:55:09 -0800 (PST) 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 DA37B1A1AA3 for ; Wed, 4 Feb 2015 14:55:08 -0800 (PST) X-AuditID: 12074423-f797b6d000000cfe-f2-54d2a34b3670 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 A6.52.03326.B43A2D45; Wed, 4 Feb 2015 17:55:07 -0500 (EST) 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 t14Mt6Ti020169; Wed, 4 Feb 2015 17:55:07 -0500 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 t14Mt4lV000822; Wed, 4 Feb 2015 17:55:06 -0500 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; Wed, 4 Feb 2015 17:54:54 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.61]) by W92EXHUB14.exchange.mit.edu ([18.7.73.25]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 17:55:05 -0500 From: Marie-Jose Montpetit To: Aaron Falk Thread-Topic: [Taps] agenda topic: application - transport abstractions Thread-Index: AQHQQKnwKnyPoaxQdE+1B6IR1tGdrpzhbbcA Date: Wed, 4 Feb 2015 22:55:04 +0000 Message-ID: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.118.234.192] Content-Type: multipart/signed; boundary="Apple-Mail=_5A84F287-03F4-4A65-ABA1-3436CF3284F7"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFJsWRmVeSWpSXmKPExsUixCmqreu9+FKIwacLyhZtv6exWtyJcWDy 2DnrLrvHkiU/mQKYorhsUlJzMstSi/TtErgy9u45z1zQY1uxtP0aSwPjGbMuRk4OCQETidVH d7ND2GISF+6tZ+ti5OIQEljMJPF8Ry8ThLOfUWLDyndQmWOMEqenHobKbGOU2LqwHSqzklHi +r6NrCDD2AR0JJ62LmIGsUUEVCWWvQAp4uBgFlCW2P+0FiQsLOAmcXnjUqgSd4lbc5qZIGwj iY99v8BsFgEViSNnJjOC2LwCVhI7jj1hA7GFBAIkFkzeAGZzCgRKdH9aAGYzAv3w/dQasF5m AXGJW0/mM0H8JiLx8OJpNpg//+16CGUrSUy8cwnsfmaBKYwSn14ehlomKHFy5hOWCYwSs5DM moWsbhaSOoiiJInz32YxQdjaEssWvmaGsDUl9ncvZ8EU15Do/DaRFcI2lXh99CMjhG0tMePX QTYIW1FiSvdD9gWM3KsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfRyM0v0UlNKNzGCkgW7i/IO xj8HlQ4xCnAwKvHwCuRfDBFiTSwrrsw9xCjJwaQkynt75qUQIb6k/JTKjMTijPii0pzU4kOM KkC7Hm1YfYFRiiUvPy9VSYQ3qxKojjclsbIqtSgfpkyag0VJnHfTD74QIYH0xJLU7NTUgtQi mKwMB4eSBC/bIqBGwaLU9NSKtMycEoQ0EwfnIUYJDh6g4Z4gNbzFBYm5xZnpEPlTjIpS4ry8 IAkBkERGaR5cLyzJv2IUB3pLmDcXpIoHmCHgul8BDWYCGix78QLI4JJEhJRUA6MJ95KVT349 6LjhumF1Z2BxTDVP/a8TTX+TxULtPhmsl2VUWqRgwWxg5LQikKNRcGnySo/9Uzbnbq1WnVrG 9b+DP+Dd/zSZ/O/tz/gMWgSYxZwnGllvD90ZPL+DP2Hnh4tf2NT2hO+9IlEksFZA2qRC21xh 1aYrLTo5UxK3rPYpdputf8H0tBJLcUaioRZzUXEiAEdm2cDNAwAA Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] agenda topic: application - transport abstractions 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, 04 Feb 2015 22:55:11 -0000 --Apple-Mail=_5A84F287-03F4-4A65-ABA1-3436CF3284F7 Content-Type: multipart/alternative; boundary="Apple-Mail=_A128A649-D384-49E6-8792-BD6E3211FF9F" --Apple-Mail=_A128A649-D384-49E6-8792-BD6E3211FF9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well one reason I started being interested in TAPS was because of the = video and of course the multisource version (video for example combining = streaming, download, multimedia and social networking). For these use = cases you need to be able to specify delay, loss (to avoid or minimize = buffering events) adI could think in extreme cases even path (or = multipath). So a way to abstract the services that could be summarized = into =E2=80=9Cgive me the best video now=E2=80=9D would be very useful = for all new video-based apps out there. Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Feb 4, 2015, at 1:39 PM, Aaron Falk wrote: >=20 > Thinking about how to make good use of our meeting in Dallas, I'd like = to propose we take some time to (re)visit the topic of how applications = can express what they want from transports by looking at a few examples = and maybe comparing them to what we are coming up with in the TAPS = draft. >=20 > Given all the recent effort, RTCWeb seems like a timely topic and = Michael Tuexen has agreed to discuss the abstractions used in the API = between the javascript 'user' and the RTCWeb stack. Marie-Jose = Montpetite has offered to talk about the needs of some future television = applications (multisource video/TV). >=20 > Sound interesting? Useful? Have another application to talk about? >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_A128A649-D384-49E6-8792-BD6E3211FF9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Well one reason I started being interested in TAPS was = because of the video and of course the multisource version (video for = example combining streaming, download, multimedia and social = networking). For these use cases you need to be able to specify delay, = loss (to avoid or minimize buffering events) adI could think in extreme = cases even path (or multipath). So a way to abstract the services that = could be summarized into =E2=80=9Cgive me the best video now=E2=80=9D = would be very useful for all new video-based apps out there.


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

On Feb 4, 2015, at 1:39 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Thinking about how to make good = use of our meeting in Dallas, I'd like to propose we take some time to = (re)visit the topic of how applications can express what they want from = transports by looking at a few examples and maybe comparing them to what = we are coming up with in the TAPS draft.

Given all the recent effort, RTCWeb = seems like a timely topic and Michael Tuexen has agreed to discuss the = abstractions used in the API between the javascript 'user' and the = RTCWeb stack.  Marie-Jose Montpetite has offered to talk about the = needs of some future television applications (multisource = video/TV).

Sound= interesting? Useful?  Have another application to talk = about?

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

= --Apple-Mail=_A128A649-D384-49E6-8792-BD6E3211FF9F-- --Apple-Mail=_5A84F287-03F4-4A65-ABA1-3436CF3284F7 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 CQUxDxcNMTUwMjA0MjI1NTA0WjAjBgkqhkiG9w0BCQQxFgQUd6/n90zxD1gAciW+CYK5H7Z7F7Uw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYAnZWd1nvxW3zeURNjmFebCJ/N2RsNf2PeU A1C8MdW6Gf8ghBua0+WBpzcQhay/8AQoeptoKBaF5Lhs7aogslK+DhJLME08l5Iu0ZO1RUPihiuT mQfssNkbC+wfFypK3UWE84DdcvkpXdLh7BRYa9ETwKvBgSCbH6c04mag5EsEfwAAAAAAAA== --Apple-Mail=_5A84F287-03F4-4A65-ABA1-3436CF3284F7-- From nobody Wed Feb 4 15:24: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 C09841A0029 for ; Wed, 4 Feb 2015 15:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DwG5ooyNbHpx for ; Wed, 4 Feb 2015 15:24:33 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4D21A0024 for ; Wed, 4 Feb 2015 15:24:33 -0800 (PST) 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 t14NOGhF005806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 4 Feb 2015 15:24:17 -0800 (PST) Message-ID: <54D2AA1E.2070007@isi.edu> Date: Wed, 04 Feb 2015 15:24:14 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Marie-Jose Montpetit , Aaron Falk References: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> In-Reply-To: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed 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] agenda topic: application - transport abstractions 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, 04 Feb 2015 23:24:35 -0000 On 2/4/2015 2:55 PM, Marie-Jose Montpetit wrote: > Well one reason I started being interested in TAPS was because of the > video and of course the multisource version (video for example combining > streaming, download, multimedia and social networking). For these use > cases you need to be able to specify delay, loss (to avoid or minimize > buffering events) For a streaming source, delay can be described (time offset, time offset variation). That is simple only for real-time streaming live, bidirectional content. When you start including the size of the message - whether as a single bulk transfer, or the ability to buffer large amounts of it (for recorded content), then the size of the message is inherent in the notion of latency. You can't ask the network how long something will take if you don't tell it how big it is. > I could think in extreme cases even path (or > multipath). I've said this before in MPTCP, but please don't confuse endpoint with path here. Same endpoints can mean different path, and using multiple endpoints is no guarantee of independent paths. > So a way to abstract the services that could be summarized > into “give me the best video now” would be very useful for all new > video-based apps out there. What would "give me the best video now" mean to the transport layer? Completely different things for Netflix, Vine, and Skype. In summary, we need a better way to describe the services we want before we'll ever be able to expect the transport to handle them properly. Joe From nobody Wed Feb 4 15:30: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 86BAC1A0027 for ; Wed, 4 Feb 2015 15:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwAFgZ0Pj9rs for ; Wed, 4 Feb 2015 15:29:56 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBC21A0011 for ; Wed, 4 Feb 2015 15:29:56 -0800 (PST) X-AuditID: 1209190e-f799e6d000000cfe-81-54d2ab72686c 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id 6D.51.03326.27BA2D45; Wed, 4 Feb 2015 18:29:55 -0500 (EST) 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 t14NTsXB026230; Wed, 4 Feb 2015 18:29:54 -0500 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 t14NTl7N006980; Wed, 4 Feb 2015 18:29:53 -0500 Received: from W92EXCAS21.exchange.mit.edu (18.7.71.34) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Feb 2015 18:29:03 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.61]) by W92EXCAS21.exchange.mit.edu ([18.7.71.34]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 18:29:42 -0500 From: Marie-Jose Montpetit To: Joe Touch Thread-Topic: [Taps] agenda topic: application - transport abstractions Thread-Index: AQHQQKnwKnyPoaxQdE+1B6IR1tGdrpzhbbcAgAAIJgCAAAGHAA== Date: Wed, 4 Feb 2015 23:29:42 +0000 Message-ID: References: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> <54D2AA1E.2070007@isi.edu> In-Reply-To: <54D2AA1E.2070007@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.118.234.192] Content-Type: multipart/signed; boundary="Apple-Mail=_A8EE7E44-D854-4151-A0E9-1078703A0401"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUgUYRjHe2dm13FxbFyPfd2ycrKDPCsDsegCc40ICfsSUY3uuLu1u24z q7h+Ubq8YSWVXM9MxQstpUjDzAUj7UNeIIqKikapIBJqxxbN7Hh9+z3v///8Hx7eB0flVVIl rjOaGdZI6ympDJO7egcGc01DcWEz+ognf4olERM3I1oc5dh5VNVhm3RR1dT8QlTvll9jsegN 2Rk1o9elMGzo2Tsy7UpzFTAteqfmlY5iGWDaKwe44pAMh9a1JqnIPnBgqpVnGS4nXyBwrH5k o+gGsNJm3yg+AlhX8UUiFm94JX8UiEUDgEV5DhchTEoGwfnH1ajAXqQfnHYsOd9R8hIcr7Fi AnvyPPyqdsMTDcfLHiI5AOf5IuwrDRWeMTIAthe3IgITZCTs7JpCxVllAOZV9DgFV/IInOz+ IBEY8Eus9zcj4iwFHJ+rRMTlvODM4OetRf91zmwwBQsmhpyroWQhHzrrkIrTPGBfyRxmBdC2 I8u202fb4RNNgbDu+SIqchicz16QiHwKLvauAJFPw2e/e6Qi+8PC3BmXKoA3Aj+1IS3YQOv0 HJMQzCXQRiPDBp8MMejMIYw6uQ04P9/X/S1Y7aHsgMQB5UZo7w/GySV0Cmcx2IEvjlDeREP9 UJzcPT5JbdHSnPY2m6xnODsI4GfNvmwaAErMmGRkKC/iroX3EWraksawSZu2PThGKYi2n+5x clJDm5l7DGNi2E11L45TkPjRyDd6sIyGSU3U6c3bMoK72gHE3fhwp4fgTLSB02lEvR/4KxXE kiCQgqBNNm71bh72AlDwa3kSSYLLjT/7re4FPhjhg/0GB4RgM70tKTNA+PvLyLo1ZvnR4bGS 9IPtnS36dZPM2htF6L5/zQrM2pdeENRUPnI1uvS6vZZwZF4ZSvTOz59Vhmuw0QeTHi6qUHS3 ZrgDCcrMXD701FAQqykort71DYyyDJiL/HtCdeBcelGNNjZfG5R8bTU9/sJarkWTLT0aFeNz a/+nLkU5hXFa+vgxlOXo/+lzhaazAwAA Archived-At: Cc: Aaron Falk , "taps@ietf.org" Subject: Re: [Taps] agenda topic: application - transport abstractions 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, 04 Feb 2015 23:29:58 -0000 --Apple-Mail=_A8EE7E44-D854-4151-A0E9-1078703A0401 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > snip/snip > In summary, we need a better way to describe the services we want = before we'll ever be able to expect the transport to handle them = properly. >=20 I totally agree. >=20 >=20 --Apple-Mail=_A8EE7E44-D854-4151-A0E9-1078703A0401 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 CQUxDxcNMTUwMjA0MjMyOTQyWjAjBgkqhkiG9w0BCQQxFgQUgDQIEbLgX2BdWb/VQwsXAIbgHUEw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYA0PQy7Sf1zRKZi5LtTSAP8VC7aaBCdDWPz 3ixabw+jDZUP6WRPl1Tdv2jCTr4gdlAXQrq5gS6MXxLhjnBqc+r4w/3pcsQDnbYJyHkEisxQstmh gRNtNiwLwtolZue0cDIf9sSfoRhzKJbkZv2fndqN+55m/Pe8RIGjNma90UCI1wAAAAAAAA== --Apple-Mail=_A8EE7E44-D854-4151-A0E9-1078703A0401-- From nobody Thu Feb 5 00:44: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 EB5191A00E9 for ; Thu, 5 Feb 2015 00:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYlOg4U8jS35 for ; Thu, 5 Feb 2015 00:44:49 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8FA1A00FA for ; Thu, 5 Feb 2015 00:44:47 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YJI3H-0001Es-3u; Thu, 05 Feb 2015 09:44:43 +0100 Received: from mail-ex04.exprod.uio.no ([129.240.52.7]) by mail-mx2.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YJI3G-0000cA-Ie; Thu, 05 Feb 2015 09:44:43 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex04.exprod.uio.no (2001:700:100:52::7) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 5 Feb 2015 09:44:40 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.0847.030; Thu, 5 Feb 2015 09:44:40 +0100 From: Michael Welzl To: Marie-Jose Montpetit Thread-Topic: [Taps] agenda topic: application - transport abstractions Thread-Index: AQHQQKnyzI0K3sMf60uLXcDhTq3J2A== Date: Thu, 5 Feb 2015 08:44:39 +0000 Message-ID: <5A86627C-7B17-4B09-8F54-8AB6FEFE5F9A@ifi.uio.no> References: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> <54D2AA1E.2070007@isi.edu> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="Windows-1252" Content-ID: <58BDB18A8F1D24439418622B5E04157B@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 7 sum msgs/h 2 total rcpts 25545 max rcpts/h 44 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: 943A1F08691DABA2A76CF129D1DD67C1E66A9F82 X-UiO-SPAM-Test: remote_host: 129.240.52.7 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 208 total 557329 max/h 442 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] agenda topic: application - transport abstractions 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, 05 Feb 2015 08:44:52 -0000 > On 05 Feb 2015, at 00:29, Marie-Jose Montpetit wrote: >=20 >> snip/snip >=20 >> In summary, we need a better way to describe the services we want before= we'll ever be able to expect the transport to handle them properly. >>=20 > I totally agree. We've been around the "let's specify what the application wants, not what p= rotocols can do" block a couple of times prior to creation of this group. W= e started and ended with the bottom-up'ish plan that is in the charter now. So, if you take a look at item #2 in the charter, it's rather unclear what = that item is going to look like, and in particular how we'll arrive there: "2) Specify the subset of those Transport Services, as identified=20 in item 1, that end systems supporting TAPS will provide, and=20 give guidance on choosing among available mechanisms and=20 protocols. Note that not all the capabilities of IETF Transport=20 protocols need to be exposed as Transport Services." We'll have to figure out reasonable ways to shorten the list in item #1 at = some point; this could include compiling a number of services under more ap= plication-oriented terms - such as "willing to choose low latency at the co= st of X". What this statement precisely means depends on "X", and I think w= e can get an idea of what "X" is when we create that service from the list = in item #1, not out of the blue. Does that make sense? Cheers, Michael From nobody Thu Feb 5 00:54: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 D8BC71A00A2 for ; Thu, 5 Feb 2015 00:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD0oAhTRwRnm for ; Thu, 5 Feb 2015 00:54:51 -0800 (PST) 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 58CB41A0059 for ; Thu, 5 Feb 2015 00:54:51 -0800 (PST) X-AuditID: 12074424-f791c6d000000d25-d8-54d32fd9063d 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 CA.88.03365.ADF23D45; Thu, 5 Feb 2015 03:54:50 -0500 (EST) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t158sn7k007027; Thu, 5 Feb 2015 03:54:49 -0500 Received: from W92EXEDGE5.EXCHANGE.MIT.EDU (w92exedge5.exchange.mit.edu [18.7.73.22]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id t158slLj013763; Thu, 5 Feb 2015 03:54:48 -0500 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by W92EXEDGE5.EXCHANGE.MIT.EDU (18.7.73.22) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Feb 2015 03:53:48 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.61]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0158.001; Thu, 5 Feb 2015 03:54:47 -0500 From: Marie-Jose Montpetit To: Michael Welzl Thread-Topic: [Taps] agenda topic: application - transport abstractions Thread-Index: AQHQQKnwKnyPoaxQdE+1B6IR1tGdrpzhbbcAgAAIJgCAAAGHAIAAmw6AgAAC0wA= Date: Thu, 5 Feb 2015 08:54:46 +0000 Message-ID: <78056BFB-D2B2-4453-ACF5-0E85A82C0543@mit.edu> References: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> <54D2AA1E.2070007@isi.edu> <5A86627C-7B17-4B09-8F54-8AB6FEFE5F9A@ifi.uio.no> In-Reply-To: <5A86627C-7B17-4B09-8F54-8AB6FEFE5F9A@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.118.234.192] Content-Type: multipart/signed; boundary="Apple-Mail=_CC5A8671-334D-422D-8291-CAB564959662"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA01TfUgTYRzuvbttt+HZuTRfl5IeEpjN7FssJFNqEGSE/WNFXe50q+2Uuxka WFooqNAHmujMzK9EXWVGNrOI1rdhWIaWaLbQCEdZmKn5UXc7Tf97fu/z8eOB34ujaptcgxtZ C8OxtImSqzC10idU27u2Kz585oMyIneqWBYx0dEqi+g7GHFjuhzbjularf0KXU3NJKJrbHSi uraRO9heLEG1Tc+YjCcYbm3UEZVhZrxZntoTnH67YgjNAo8D84ESh+RG+K47G5Hwctj58aY8 H6hwNVmNwPraMSANDwEsrbcrpOEpgMW/pjBpaAGw9nsFIg31AM5+tGFimJxcA4dyqlARe5Or 4Iu6RrmIUfIYrO6pdL8vI3fCrlu1c5pdsPfyWUTCe+CDuznud4wMhrmFJW4vQUbCyabJuWXZ CHRcsSpEQklGwdHiKrcZCC3G222ItMwX9g5WzLXzhs43r+TzTWfvOecwBS/2vXW3RskiAO1t g6i0zQu+LB3ELgBoXZRlXayzLtJJolB4rdKFSjgcDuUNyyS8Cbqe/gQS3gpL/jySSzgIFhU4 FVcB3gAC9OaTWjNtNPFMopZPpFmW4bRbwsxGSxijT2sG4iEoYoPt4KyDcgASB5QH8antbbxa Rp/gM8wO4IcjlA+xPrQrXu15NEWfYaB5w2EuzcTwDhAs7Prc1NgJNBibwjKUNxGCCzpCT2ec ZLiUedkKHKN8ieYJz3g1mUxbmOMMk8pw86w/jlOQKA8TjF4ck8ykJxlNlgUawZUOAHEPIbxS 1BB8Km3mjckS3w6CNL7EeZEgRcKQxv73zh/5MPAVai0jdKLKQ/gC/93DQjAiBAe86RSDLfQC pckCu6/HFtZlfrEl7Lf3JpYXf3tWoOoI+PsbPdCxOS0k5oc9+lBkXH1OYOr9yP5SGXtmQlNG v37eGre58Mm3pdOno/ynvLoH2EuY2oU5ZWO1fYmfshoGh2Na8t4f36BzDUx9/TlQdqrFavPz GXHUNUxbkvbFqVZWPhtdcm4oegeXnOmiMN5Ar1uNcjz9DxcThZy/AwAA Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] agenda topic: application - transport abstractions 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, 05 Feb 2015 08:54:54 -0000 --Apple-Mail=_CC5A8671-334D-422D-8291-CAB564959662 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 5, 2015, at 3:44 AM, Michael Welzl wrote: >=20 >=20 >> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit = wrote: >>=20 >>> snip/snip >>=20 >>> In summary, we need a better way to describe the services we want = before we'll ever be able to expect the transport to handle them = properly. >>>=20 >> I totally agree. >=20 > We've been around the "let's specify what the application wants, not = what protocols can do" block a couple of times prior to creation of this = group. We started and ended with the bottom-up'ish plan that is in the = charter now. Yes but in fact I think that you have to look at both ends: define what = the service wants can be tricky but necessary. On the other hand it also = almost implies that the mechanims or services also expose their = characteristics - if not, matching of services to transport cannot = happen. >=20 > So, if you take a look at item #2 in the charter, it's rather unclear = what that item is going to look like, and in particular how we'll arrive = there: >=20 > "2) Specify the subset of those Transport Services, as identified=20 > in item 1, that end systems supporting TAPS will provide, and=20 > give guidance on choosing among available mechanisms and=20 > protocols. Note that not all the capabilities of IETF Transport=20 > protocols need to be exposed as Transport Services." >=20 > We'll have to figure out reasonable ways to shorten the list in item = #1 at some point; this could include compiling a number of services = under more application-oriented terms - such as "willing to choose low = latency at the cost of X". What this statement precisely means depends = on "X", and I think we can get an idea of what "X" is when we create = that service from the list in item #1, not out of the blue. >=20 > Does that make sense? Yes but the issue will be in defining X - less latency at the expense of = bandwidth or more complexity in the network or ??? Each of those may = imply a different transport.=20 >=20 > Cheers, > Michael >=20 --Apple-Mail=_CC5A8671-334D-422D-8291-CAB564959662 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 CQUxDxcNMTUwMjA1MDg1NDQ2WjAjBgkqhkiG9w0BCQQxFgQU9SL9rFdRa6ogbO+lW1u9MMsAllYw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYBoaGM6DbpoKfSNl3OHaG4VkO8go4clAgQG QFWT2dpaeqaQbFOgMYaqqkT5fdrN8wlyM2wqZqYMXJANhCAuyha/J0B53ZO46ugnte3E4oZzrmqK /SonrBiteeobHucu3LSI+KtHXT7emZTF8RzeUD53QCJTLxp30/w6jH+PlznSaAAAAAAAAA== --Apple-Mail=_CC5A8671-334D-422D-8291-CAB564959662-- From nobody Thu Feb 5 01:57: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 15B7D1A01F2 for ; Thu, 5 Feb 2015 01:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXy_ZgIIZ5eO for ; Thu, 5 Feb 2015 01:57:44 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059011A01CB for ; Thu, 5 Feb 2015 01:57:43 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YJJBr-0001WY-Im; Thu, 05 Feb 2015 10:57:39 +0100 Received: from mail-ex04.exprod.uio.no ([129.240.52.7]) by mail-mx3.uio.no with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1YJJBq-00060k-Uz; Thu, 05 Feb 2015 10:57:39 +0100 Received: from mail-ex03.exprod.uio.no (2001:700:100:52::6) by mail-ex04.exprod.uio.no (2001:700:100:52::7) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 5 Feb 2015 10:57:36 +0100 Received: from mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c]) by mail-ex03.exprod.uio.no ([fe80::5889:72f9:9e7c:4a6c%19]) with mapi id 15.00.0847.030; Thu, 5 Feb 2015 10:57:36 +0100 From: Michael Welzl To: Marie-Jose Montpetit Thread-Topic: [Taps] agenda topic: application - transport abstractions Thread-Index: AQHQQKnyzI0K3sMf60uLXcDhTq3J2A== Date: Thu, 5 Feb 2015 09:57:35 +0000 Message-ID: <1EFDAC6F-34BF-476F-B53A-B1A1809FD044@ifi.uio.no> References: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> <54D2AA1E.2070007@isi.edu> <5A86627C-7B17-4B09-8F54-8AB6FEFE5F9A@ifi.uio.no> <78056BFB-D2B2-4453-ACF5-0E85A82C0543@mit.edu> In-Reply-To: <78056BFB-D2B2-4453-ACF5-0E85A82C0543@mit.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.240.169.59] Content-Type: text/plain; charset="Windows-1252" Content-ID: <475C05297A13B24C83B1CDBE89FA3800@mail.uio.no> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 25553 max rcpts/h 44 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: 259B6EBABE866399CE3A0F2D12054B2430CE9A07 X-UiO-SPAM-Test: remote_host: 129.240.52.7 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 300 total 557709 max/h 442 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] agenda topic: application - transport abstractions 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, 05 Feb 2015 09:57:46 -0000 > On 05 Feb 2015, at 09:54, Marie-Jose Montpetit wrote: >=20 >=20 >=20 >=20 >> On Feb 5, 2015, at 3:44 AM, Michael Welzl wrote: >>=20 >>=20 >>> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit wrote: >>>=20 >>>> snip/snip >>>=20 >>>> In summary, we need a better way to describe the services we want befo= re we'll ever be able to expect the transport to handle them properly. >>>>=20 >>> I totally agree. >>=20 >> We've been around the "let's specify what the application wants, not wha= t protocols can do" block a couple of times prior to creation of this group= . We started and ended with the bottom-up'ish plan that is in the charter n= ow. >=20 > Yes but in fact I think that you have to look at both ends: define what t= he service wants can be tricky but necessary. On the other hand it also alm= ost implies that the mechanims or services also expose their characteristic= s - if not, matching of services to transport cannot happen. I couldn't parse this. What do you mean? >> So, if you take a look at item #2 in the charter, it's rather unclear wh= at that item is going to look like, and in particular how we'll arrive ther= e: >>=20 >> "2) Specify the subset of those Transport Services, as identified=20 >> in item 1, that end systems supporting TAPS will provide, and=20 >> give guidance on choosing among available mechanisms and=20 >> protocols. Note that not all the capabilities of IETF Transport=20 >> protocols need to be exposed as Transport Services." >>=20 >> We'll have to figure out reasonable ways to shorten the list in item #1 = at some point; this could include compiling a number of services under more= application-oriented terms - such as "willing to choose low latency at the= cost of X". What this statement precisely means depends on "X", and I thin= k we can get an idea of what "X" is when we create that service from the li= st in item #1, not out of the blue. >>=20 >> Does that make sense? > Yes but the issue will be in defining X - less latency at the expense of = bandwidth or more complexity in the network or ??? Each of those may imply = a different transport.=20 Agreed - my point is: when we build #1, X will come. Michael From nobody Thu Feb 5 03:21: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 5F4621A1B99 for ; Thu, 5 Feb 2015 03:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DS4nfFISyR4O for ; Thu, 5 Feb 2015 03:21:53 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE251A1AAE for ; Thu, 5 Feb 2015 03:21:51 -0800 (PST) X-AuditID: 12074425-f798e6d000000d1a-0f-54d3524edb2b 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 45.49.03354.E4253D45; Thu, 5 Feb 2015 06:21:50 -0500 (EST) 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 t15BLnNl016335; Thu, 5 Feb 2015 06:21:49 -0500 Received: from w92exedge3.EXCHANGE.MIT.EDU (w92exedge3.exchange.mit.edu [18.7.73.15]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id t15BLlH1019653; Thu, 5 Feb 2015 06:21:48 -0500 Received: from OC11EXHUB11.exchange.mit.edu (18.9.3.25) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 5 Feb 2015 06:21:24 -0500 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.61]) by OC11EXHUB11.exchange.mit.edu ([18.9.3.25]) with mapi id 14.03.0158.001; Thu, 5 Feb 2015 06:21:47 -0500 From: Marie-Jose Montpetit To: Michael Welzl Thread-Topic: [Taps] agenda topic: application - transport abstractions Thread-Index: AQHQQKnwKnyPoaxQdE+1B6IR1tGdrpzhbbcAgAAIJgCAAAGHAIAAmw6AgAAC0wCAABGNgIAAF4UA Date: Thu, 5 Feb 2015 11:21:47 +0000 Message-ID: References: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> <54D2AA1E.2070007@isi.edu> <5A86627C-7B17-4B09-8F54-8AB6FEFE5F9A@ifi.uio.no> <78056BFB-D2B2-4453-ACF5-0E85A82C0543@mit.edu> <1EFDAC6F-34BF-476F-B53A-B1A1809FD044@ifi.uio.no> In-Reply-To: <1EFDAC6F-34BF-476F-B53A-B1A1809FD044@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [76.118.234.192] Content-Type: multipart/signed; boundary="Apple-Mail=_C247D040-CB9E-468E-857A-AAC1FCAE58FD"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA02Te0gUURTGu7Oz46w5Ma6aN8vCsUzyGSStViIUZQaiIUES1uhed7d2V5tZ Rf1LChMVyshe20MtH+hGmWSkRuaa5APNR6SZmSsqpJClhI/EmnHU/O937ved79wD95IyZSXh RuqMJsQZWT1D2ONKhYuPX+TJ3pjAkRs7VFf+3JKr5jpq5arBM6qniw/wMDy81vzVLrykZB4L t1hssvD6qRo8Co+1P6hGel0q4gJCz9lrG6yNRPKYd1q5rR9kginPXECSkN4Hl1oycoFCwM2w a+gZkQvsSSX9GIPmn1VyqWgAcKqsCJeKZgCHhutXihoALxV2rBQVAGZ1zduJYQTtC8eyHslE dqa9YEu5hRBZRp+Hj/uKl8+d6KOw93npiucYHLh/GZM4Ft6svY+LjNM7oW3hHSbelaJD4Mxi gjRrHIMvOz8D0aOgQ2H7+4VlPxCWmG17gkmzXOHAaCEmLecMbd3txOqiS3W2FWbg9cGe5aVl dAGAn+ZrlgWKdoStd0fxfADN67LM633mdT7J5APLiidlEgfCsZwJucRBcLL5F5D4ALyz0EhI 7AEL8mx2RYCsBO5qQ4afgdXpeZTgxyewRiPi/FT+Bp3JH6lTqoH4DOyO7HoF8q2MFdAkYBwo 1ZueGKWcTeXTDVawhcQYF4qL7I1RbopPUqdrWV57lkvRI94KdgqzRqosXcANNyYZEeNMvYgQ fJSaTc9AXNKqbSuJM65U9dymGCWtYU3oAkLJiFtVt5EkA6nWKKHRkUMalJao05v+yxipsAJI Ogjh30UPxSezBl6nkfQ24OHmSnlECwItCtoU41rv6hOfAK7CWk6URWx3ED7AWveEEIwJwe7d XWKwif0vuWWC8tm6D3mVj0J6nS/uaAt+GRa9+7VTs0LXb4s41XmVmHUwnXwYb7kNxhP+frzX 13Qi2fN4q7/l2unp4LtvhzdkpCZ6NyHNoTh5QMc3ZIw7PPtlntVkH3a0mG7q9peczq4Iq/Dp 9Jr+PTn4wDeowD0r58dM1KIa69y+MOAzFB22sbaUwXktu3ePjOPZf7yYdVO9AwAA Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] agenda topic: application - transport abstractions 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, 05 Feb 2015 11:21:55 -0000 --Apple-Mail=_C247D040-CB9E-468E-857A-AAC1FCAE58FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What I mean is defining what the apps need is not independent of also = defining what the protocols offer. Marie-Jose Montpetit, Ph.D. mariejo@mit.edu @SocialTVMIT > On Feb 5, 2015, at 4:57 AM, Michael Welzl wrote: >=20 >=20 >> On 05 Feb 2015, at 09:54, Marie-Jose Montpetit = wrote: >>=20 >>=20 >>=20 >>=20 >>> On Feb 5, 2015, at 3:44 AM, Michael Welzl = wrote: >>>=20 >>>=20 >>>> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit = wrote: >>>>=20 >>>>> snip/snip >>>>=20 >>>>> In summary, we need a better way to describe the services we want = before we'll ever be able to expect the transport to handle them = properly. >>>>>=20 >>>> I totally agree. >>>=20 >>> We've been around the "let's specify what the application wants, not = what protocols can do" block a couple of times prior to creation of this = group. We started and ended with the bottom-up'ish plan that is in the = charter now. >>=20 >> Yes but in fact I think that you have to look at both ends: define = what the service wants can be tricky but necessary. On the other hand it = also almost implies that the mechanims or services also expose their = characteristics - if not, matching of services to transport cannot = happen. >=20 > I couldn't parse this. What do you mean? >=20 >=20 >>> So, if you take a look at item #2 in the charter, it's rather = unclear what that item is going to look like, and in particular how = we'll arrive there: >>>=20 >>> "2) Specify the subset of those Transport Services, as identified=20 >>> in item 1, that end systems supporting TAPS will provide, and=20 >>> give guidance on choosing among available mechanisms and=20 >>> protocols. Note that not all the capabilities of IETF Transport=20 >>> protocols need to be exposed as Transport Services." >>>=20 >>> We'll have to figure out reasonable ways to shorten the list in item = #1 at some point; this could include compiling a number of services = under more application-oriented terms - such as "willing to choose low = latency at the cost of X". What this statement precisely means depends = on "X", and I think we can get an idea of what "X" is when we create = that service from the list in item #1, not out of the blue. >>>=20 >>> Does that make sense? >> Yes but the issue will be in defining X - less latency at the expense = of bandwidth or more complexity in the network or ??? Each of those may = imply a different transport.=20 >=20 > Agreed - my point is: when we build #1, X will come. >=20 > Michael >=20 --Apple-Mail=_C247D040-CB9E-468E-857A-AAC1FCAE58FD 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 CQUxDxcNMTUwMjA1MTEyMTQ3WjAjBgkqhkiG9w0BCQQxFgQUGNlHlg/ApQtwgRVRVylcaN2og0Qw gZIGCSsGAQQBgjcQBDGBhDCBgTBsMQswCQYDVQQGEwJVUzEWMBQGA1UECBMNTWFzc2FjaHVzZXR0 czEuMCwGA1UEChMlTWFzc2FjaHVzZXR0cyBJbnN0aXR1dGUgb2YgVGVjaG5vbG9neTEVMBMGA1UE CxMMQ2xpZW50IENBIHYxAhEA78VxlfSvH+AEEsVksSST6zCBlAYLKoZIhvcNAQkQAgsxgYSggYEw bDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3NhY2h1c2V0dHMxLjAsBgNVBAoTJU1hc3NhY2h1 c2V0dHMgSW5zdGl0dXRlIG9mIFRlY2hub2xvZ3kxFTATBgNVBAsTDENsaWVudCBDQSB2MQIRAO/F cZX0rx/gBBLFZLEkk+swDQYJKoZIhvcNAQEBBQAEgYCZpQ8AGxp17x/E7Fy7hEVQTolzqJ1HHoY+ kaMz7Qkp+ULgyRlyj5o/VnQTWoR0xJ7CY2DvbadSo67d/kf6aM67OhHuB0FQ6VNsxMnYAHl59b12 UvngHtTO29NAfktDB91oS9NV3l2S+OnCsK0moOKuHo0tDdZhyR+DiiSwoElLBwAAAAAAAA== --Apple-Mail=_C247D040-CB9E-468E-857A-AAC1FCAE58FD-- From nobody Thu Feb 5 06:28: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 2FFA91A8A4B for ; Thu, 5 Feb 2015 06:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-u2SIXM8gVF for ; Thu, 5 Feb 2015 06:27:55 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4720E1A8A23 for ; Thu, 5 Feb 2015 06:27:55 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1YJNPL-0008TP-06; Thu, 05 Feb 2015 15:27:51 +0100 Received: from 1x-193-157-222-128.uio.no ([193.157.222.128]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1YJNPK-0008AR-Az; Thu, 05 Feb 2015 15:27:50 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Welzl In-Reply-To: Date: Thu, 5 Feb 2015 15:27:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E0D81E9-2147-4CDB-BB57-F90ECFBC3949@ifi.uio.no> References: <0461BE27-648E-48C2-9CC1-86D79344A936@mit.edu> <54D2AA1E.2070007@isi.edu> <5A86627C-7B17-4B09-8F54-8AB6FEFE5F9A@ifi.uio.no> <78056BFB-D2B2-4453-ACF5-0E85A82C0543@mit.edu> <1EFDAC6F-34BF-476F-B53A-B1A1809FD044@ifi.uio.no> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.1510) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 22 sum msgs/h 11 total rcpts 25590 max rcpts/h 44 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: E62789152322123A4FD2D91DD9BBD7C17FD0BD00 X-UiO-SPAM-Test: remote_host: 193.157.222.128 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 49 max/h 11 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Aaron Falk , "taps@ietf.org" , Joe Touch Subject: Re: [Taps] agenda topic: application - transport abstractions 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, 05 Feb 2015 14:27:58 -0000 Then we agree. On Feb 5, 2015, at 12:21 PM, Marie-Jose Montpetit = wrote: > What I mean is defining what the apps need is not independent of also = defining what the protocols offer. >=20 > Marie-Jose Montpetit, Ph.D. > mariejo@mit.edu > @SocialTVMIT >=20 >> On Feb 5, 2015, at 4:57 AM, Michael Welzl wrote: >>=20 >>=20 >>> On 05 Feb 2015, at 09:54, Marie-Jose Montpetit = wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Feb 5, 2015, at 3:44 AM, Michael Welzl = wrote: >>>>=20 >>>>=20 >>>>> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit = wrote: >>>>>=20 >>>>>> snip/snip >>>>>=20 >>>>>> In summary, we need a better way to describe the services we want = before we'll ever be able to expect the transport to handle them = properly. >>>>>>=20 >>>>> I totally agree. >>>>=20 >>>> We've been around the "let's specify what the application wants, = not what protocols can do" block a couple of times prior to creation of = this group. We started and ended with the bottom-up'ish plan that is in = the charter now. >>>=20 >>> Yes but in fact I think that you have to look at both ends: define = what the service wants can be tricky but necessary. On the other hand it = also almost implies that the mechanims or services also expose their = characteristics - if not, matching of services to transport cannot = happen. >>=20 >> I couldn't parse this. What do you mean? >>=20 >>=20 >>>> So, if you take a look at item #2 in the charter, it's rather = unclear what that item is going to look like, and in particular how = we'll arrive there: >>>>=20 >>>> "2) Specify the subset of those Transport Services, as identified=20= >>>> in item 1, that end systems supporting TAPS will provide, and=20 >>>> give guidance on choosing among available mechanisms and=20 >>>> protocols. Note that not all the capabilities of IETF Transport=20 >>>> protocols need to be exposed as Transport Services." >>>>=20 >>>> We'll have to figure out reasonable ways to shorten the list in = item #1 at some point; this could include compiling a number of services = under more application-oriented terms - such as "willing to choose low = latency at the cost of X". What this statement precisely means depends = on "X", and I think we can get an idea of what "X" is when we create = that service from the list in item #1, not out of the blue. >>>>=20 >>>> Does that make sense? >>> Yes but the issue will be in defining X - less latency at the = expense of bandwidth or more complexity in the network or ??? Each of = those may imply a different transport.=20 >>=20 >> Agreed - my point is: when we build #1, X will come. >>=20 >> Michael >>=20 >=20 From nobody Sat Feb 7 04:08: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 C3A7B1A1B16; Sat, 7 Feb 2015 04:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsV7QP9Z0fLi; Sat, 7 Feb 2015 04:07:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9ED1A0141; Sat, 7 Feb 2015 04:07:05 -0800 (PST) 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: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150207120702.11245.33712.idtracker@ietfa.amsl.com> Date: Sat, 07 Feb 2015 04:07:02 -0800 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-02.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: Sat, 07 Feb 2015 12:07:07 -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-02.txt Pages : 20 Date : 2015-02-07 Abstract: This document describes services provided by existing IETF protocols and congestion control mechanisms. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-taps-transports-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-02 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 Sat Feb 7 04:41: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 238BB1A1B16 for ; Sat, 7 Feb 2015 04:41:37 -0800 (PST) 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 ipV4sdLY_iTw for ; Sat, 7 Feb 2015 04:41:35 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D1B7B1A026F for ; Sat, 7 Feb 2015 04:41:34 -0800 (PST) Received: from [IPv6:2001:470:26:9c2:5489:82de:6e7c:ff4d] (unknown [IPv6:2001:470:26:9c2:5489:82de:6e7c:ff4d]) by trammell.ch (Postfix) with ESMTPSA id 614291A030B for ; Sat, 7 Feb 2015 13:41:33 +0100 (CET) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5b4 Content-Type: multipart/signed; boundary="Apple-Mail=_CFC9A71F-249A-46BE-A4A9-5DEC3C60D7C6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sat, 7 Feb 2015 13:41:32 +0100 References: <20150207120702.11245.33712.idtracker@ietfa.amsl.com> To: taps WG Message-Id: <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: Subject: [Taps] Fwd: I-D Action: draft-ietf-taps-transports-02.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, 07 Feb 2015 12:41:37 -0000 --Apple-Mail=_CFC9A71F-249A-46BE-A4A9-5DEC3C60D7C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've submitted the -02 rev of the transports document, addressing = comments to date and including additional content for some of the = transport protocols. Markdown (kramdown-rfc2629) source and toolchain is available at = https://github.com/britram/taps-transports. Subsection authors: feel = free to send pull requests against either the markdown or XML source = (we'll convert the latter back to the former) or text to the editors via = email. We'd like to get at least one more rev of the document out before = Dallas. Not-yet-subsection-authors who would like to contribute: there are a = couple of sections we'd like to have (HTTP(S) as a pseudotransport, and = WebSockets which removes some of the "pseudo" therefrom) that don't yet = have contributors associated; additionally, if there are transport (or = transport-like) protocols we're missing here, please send text and we'll = get it integrated. Many thanks, best regards, Brian (for the editors of taps-transports). > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: > Date: 7 Feb 2015 13:07:02 CET > Cc: taps@ietf.org > Subject: [Taps] I-D Action: draft-ietf-taps-transports-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services Working Group of = the IETF. >=20 > Title : Services provided by IETF transport protocols = and congestion control mechanisms > Authors : Godred Fairhurst > Brian Trammell > Mirja Kuehlewind > Filename : draft-ietf-taps-transports-02.txt > Pages : 20 > Date : 2015-02-07 >=20 > Abstract: > This document describes services provided by existing IETF protocols > and congestion control mechanisms. It is designed to help > application and network stack programmers and to inform the work of > the IETF TAPS Working Group. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-taps-transports-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_CFC9A71F-249A-46BE-A4A9-5DEC3C60D7C6 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 iQEcBAEBCgAGBQJU1gf8AAoJENt3nsOmbNJc8lYH/231bteAnf6l2sAy58WesrBi +t37y4T+KLwxbsY5E/SSMxwTHHjWuNNO2I0D+dIMaSt+LeNieEjcUHzaleXc/tPt EhatymWv9fLT88z4FkznD54I6NqPwQ7UbqASYnYawhv1UphOre/K0lRrZGmbUK2a fZOaS4V1WJkBHMstFQ5s15yPq+bqKgJ4hkVbowZtTlS14aFPh688u3Dkv7isSzJT BUYhhdzzMvSLbNxKcxrNfEkyW42XzkO7uYxDt+Qr46oC82ZvLMAz2uZZVPLT+u9H NnK8Kahj5/4LN+TX8A+ipPCnHT03ySoTBsFq94OHi7DtPSI68J0F8z4YurBH+Lk= =PwE0 -----END PGP SIGNATURE----- --Apple-Mail=_CFC9A71F-249A-46BE-A4A9-5DEC3C60D7C6-- From nobody Mon Feb 9 09:07: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 BFE171A1B16 for ; Mon, 9 Feb 2015 08:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZsAUF8LzdOa for ; Mon, 9 Feb 2015 08:48:08 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 25F631A1B27 for ; Mon, 9 Feb 2015 08:48:08 -0800 (PST) Received: from ERG-research.local (unknown [IPv6:2001:630:241:207:21f:5bff:fe38:7354]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id C45EE1B002BD for ; Mon, 9 Feb 2015 16:48:34 +0000 (GMT) Message-ID: <54D8E4C6.9040903@erg.abdn.ac.uk> Date: Mon, 09 Feb 2015 16:48:06 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: taps WG References: <20150207120702.11245.33712.idtracker@ietfa.amsl.com> <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> In-Reply-To: <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Taps] Fwd: I-D Action: draft-ietf-taps-transports-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 16:48:10 -0000 This version includes my first go at a table, in section 4.1, I'm hoping this will stimulate some input/corrections, or even perhaps alternate list of what to see here. Please discuss, or send comments via the TAPS list. gorry straw On 07/02/2015 12:41, Brian Trammell wrote: > Greetings, all, > > We've submitted the -02 rev of the transports document, addressing comments to date and including additional content for some of the transport protocols. > > Markdown (kramdown-rfc2629) source and toolchain is available at https://github.com/britram/taps-transports. Subsection authors: feel free to send pull requests against either the markdown or XML source (we'll convert the latter back to the former) or text to the editors via email. We'd like to get at least one more rev of the document out before Dallas. > > Not-yet-subsection-authors who would like to contribute: there are a couple of sections we'd like to have (HTTP(S) as a pseudotransport, and WebSockets which removes some of the "pseudo" therefrom) that don't yet have contributors associated; additionally, if there are transport (or transport-like) protocols we're missing here, please send text and we'll get it integrated. > > Many thanks, best regards, > > Brian (for the editors of taps-transports). > >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> To: >> Date: 7 Feb 2015 13:07:02 CET >> Cc: taps@ietf.org >> Subject: [Taps] I-D Action: draft-ietf-taps-transports-02.txt >> >> >> 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-02.txt >> Pages : 20 >> Date : 2015-02-07 >> >> Abstract: >> This document describes services provided by existing IETF protocols >> and congestion control mechanisms. It is designed to help >> application and network stack programmers and to inform the work of >> the IETF TAPS Working Group. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-taps-transports-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Tue Feb 10 11:05: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 1C3631A9089 for ; Tue, 10 Feb 2015 11:05:37 -0800 (PST) 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 qcfJ6W3X9SrU for ; Tue, 10 Feb 2015 11:05:34 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F321A1BEE for ; Tue, 10 Feb 2015 11:05:34 -0800 (PST) Received: from [192.168.1.200] (p508F0658.dip0.t-ipconnect.de [80.143.6.88]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 86B281C0B3E6F; Tue, 10 Feb 2015 20:05:31 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Michael Tuexen In-Reply-To: <54D8E4C6.9040903@erg.abdn.ac.uk> Date: Tue, 10 Feb 2015 20:05:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150207120702.11245.33712.idtracker@ietfa.amsl.com> <85C822D4-18EA-4AAA-9FBE-EF1F147ED2D0@trammell.ch> <54D8E4C6.9040903@erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: taps WG Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-02.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, 10 Feb 2015 19:05:37 -0000 > On 09 Feb 2015, at 17:48, Gorry Fairhurst = wrote: >=20 >=20 >=20 > This version includes my first go at a table, in section 4.1, I'm = hoping this will stimulate some input/corrections, or even perhaps = alternate list of what to see here. Please discuss, or send comments via = the TAPS list. Hi Gorry, maybe I didn't understand the table entries correctly, but I think the = following changes improve the description of SCTP: https://github.com/britram/taps-transports/pull/1 * SCTP is message oriented, so Dgram seems to be more appropriate than = Stream. * Bundling of DATA chunks and the Nagle algorithm is supported, so = multiple user messages can fit into a single IP packet. * ECN support needs to be clarified. Best regards Michael >=20 > gorry >=20 >=20 >=20 > straw On 07/02/2015 12:41, Brian Trammell wrote: >> Greetings, all, >>=20 >> We've submitted the -02 rev of the transports document, addressing = comments to date and including additional content for some of the = transport protocols. >>=20 >> Markdown (kramdown-rfc2629) source and toolchain is available at = https://github.com/britram/taps-transports. Subsection authors: feel = free to send pull requests against either the markdown or XML source = (we'll convert the latter back to the former) or text to the editors via = email. We'd like to get at least one more rev of the document out before = Dallas. >>=20 >> Not-yet-subsection-authors who would like to contribute: there are a = couple of sections we'd like to have (HTTP(S) as a pseudotransport, and = WebSockets which removes some of the "pseudo" therefrom) that don't yet = have contributors associated; additionally, if there are transport (or = transport-like) protocols we're missing here, please send text and we'll = get it integrated. >>=20 >> Many thanks, best regards, >>=20 >> Brian (for the editors of taps-transports). >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> To: >>> Date: 7 Feb 2015 13:07:02 CET >>> Cc: taps@ietf.org >>> Subject: [Taps] I-D Action: draft-ietf-taps-transports-02.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Transport Services Working Group of = the IETF. >>>=20 >>> Title : Services provided by IETF transport = protocols and congestion control mechanisms >>> Authors : Godred Fairhurst >>> Brian Trammell >>> Mirja Kuehlewind >>> Filename : draft-ietf-taps-transports-02.txt >>> Pages : 20 >>> Date : 2015-02-07 >>>=20 >>> Abstract: >>> This document describes services provided by existing IETF = protocols >>> and congestion control mechanisms. It is designed to help >>> application and network stack programmers and to inform the work = of >>> the IETF TAPS Working Group. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-taps-transports-02 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-02 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Wed Feb 25 10: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 E82651A1B83 for ; Wed, 25 Feb 2015 10:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGzKHBW66meX for ; Wed, 25 Feb 2015 10:33:10 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::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 D01AC1A1B7A for ; Wed, 25 Feb 2015 10:33:09 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id hy4so2078691vcb.4 for ; Wed, 25 Feb 2015 10:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OktW3hurOP6TxmhFqVwX5k2OjWvPxxr5fGyY0EptCeY=; b=SXS5L3up9KTrb9OjixCudDaDHhiwdc+/Cj01Zv3aWjTf/VkSdVjooLQVQtiWu6x056 V5qEboPRfIkuew8msSCyWyCVa3aCEDjMXKkQEtvWFU+qNIV4xHjqeaHl1DS+8Oee3aCb volbH+5ZAUBfZBUf6JaR85EufqKa5qBKMNl14LIN/ms2tIPI6CV7MZljAjU0+IO8f2Fr N7ugVCuVkeUp098d7FavoOoR+o1EJhgRVLRVIWTFXKqMKIxNAh1FPqraApOrrKvAKI10 NdAkIzTERGW9i6QhTSqRajOuX/axEgNXWan4Lod1jG7Q6B+em+Dt6ofb9i1LxErqvRlc qqwg== MIME-Version: 1.0 X-Received: by 10.52.162.72 with SMTP id xy8mr5286429vdb.12.1424889189089; Wed, 25 Feb 2015 10:33:09 -0800 (PST) Received: by 10.52.37.132 with HTTP; Wed, 25 Feb 2015 10:33:09 -0800 (PST) Date: Wed, 25 Feb 2015 13:33:09 -0500 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=089e01628326f5c9e5050feddd9f Archived-At: Subject: [Taps] BarBoF: How Ossified is the Protocol Stack? [HOPS] 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, 25 Feb 2015 18:33:12 -0000 --089e01628326f5c9e5050feddd9f Content-Type: text/plain; charset=UTF-8 There has been long term and increasing interest in deploying transport protocols with alternate dynamics and behaviors to TCP and UDP. The IETF has standardized several new protocols including DCCP, UDP-lite, SCTP and several changes to TCP including ECN and LEDBAT. All of these new technologies have resulted in deployment challenges blamed on intentional and unintentional interference by middleboxes such as NATs and firewalls. This has lead to approaches such as building new protocols over UDP or HTTP to make traffic look like something a middlebox would expect. However, both these approaches have shortcomings and a variety of ameliorating engineering approaches are being considered [1], [2], [3]. What is missing is a study with more than anecdotal evidence of the nature of the problem and the portions of the network in which it manifests. One of the best analyses to date is [4] which measures from a very small number of locations: 49 residential, 17 enterprise, and 142 locations in total. In the interest of getting ground-truth data about the nature of the problem, we are organizing an informal effort starting with a meeting (BarBoF) at the March IETF in Dallas to coordinate with network stack, browser, and middlebox vendors, as well as network and service operators, on collecting and reporting statistics about middlebox impact on transport sessions. The objective is to determine a set of measurements that can be made as a side effect of the normal operation of the networking stack, and a reporting format that provides some visibility into the scope and nature of middlebox impact while addressing end-user privacy and business confidentiality concerns. The BarBoF meeting will be Sunday evening (March 22nd). Time & location to be announced on the mailing list [5]. This activity is an outcome of the recent IAB workshop on Stack Evolution in a Middlebox Internet [6]. Please forward to anyone interested in participating. -------- [1] IETF Transport Services Working Group (TAPS) [2] IAB Stack Evolution Program [3] Session Protocol for User Datagrams (SPUD) Prototype [4] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. Tokuda. Is it still possible to extend tcp? In Proc. ACM IMC, 2011. [5] Subscription link to HOPS mailing list. [6] IAB SEMI Workshop --089e01628326f5c9e5050feddd9f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There h= as been long term and increasing interest in deploying transport protocols = with alternate dynamics and behaviors to TCP and UDP. The IETF has standard= ized several new protocols including DCCP, UDP-lite, SCTP and several chang= es to TCP including ECN and LEDBAT. All of these new technologies have resu= lted in deployment challenges blamed on intentional and unintentional inter= ference by middleboxes such as NATs and firewalls. This has lead to approac= hes such as building new protocols over UDP or HTTP to make traffic look li= ke something a middlebox would expect. However, both these approaches have = shortcomings and a variety of ameliorating engineering approaches are being= considered [1], [2], [3].=C2=A0

What is missing = is a study with more than anecdotal evidence of the nature of the problem a= nd the portions of the network in which it manifests. One of the best analy= ses to date is [4] which measures from a very small number of locations: 49= residential, 17 enterprise, and 142 locations in total. In the interest of= getting ground-truth data about the nature of the problem, we are organizi= ng an informal effort starting with a meeting (BarBoF) at the March IETF in= Dallas to coordinate with network stack, browser, and middlebox vendors, a= s well as network and service operators, on collecting and reporting statis= tics about middlebox impact on transport sessions. The objective is to dete= rmine a set of measurements that can be made as a side effect of the normal= operation of the networking stack, and a reporting format that provides so= me visibility into the scope and nature of middlebox impact while addressin= g end-user privacy and business confidentiality concerns.=C2=A0

The BarBoF meeting will be Su= nday evening (March 22nd).=C2=A0 Time & location to be announced on the= mailing list [5].

This activity is an outcome of the recent IAB workshop on Stack Evolution = in a Middlebox Internet [6].=C2=A0


--089e01628326f5c9e5050feddd9f-- From nobody Fri Feb 27 04:52:27 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 025E41A1BE5; Fri, 27 Feb 2015 04:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i8dhSZxlztQ; Fri, 27 Feb 2015 04:52:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B80881A8731; Fri, 27 Feb 2015 04:52:23 -0800 (PST) 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: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150227125223.18650.57760.idtracker@ietfa.amsl.com> Date: Fri, 27 Feb 2015 04:52:23 -0800 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-03.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: Fri, 27 Feb 2015 12:52:25 -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-03.txt Pages : 25 Date : 2015-02-27 Abstract: This document describes services provided by existing IETF protocols and congestion control mechanisms. It is designed to help application and network stack programmers and to inform the work of the IETF TAPS Working Group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-taps-transports-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transports-03 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 Fri Feb 27 04:58: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 225131A8763 for ; Fri, 27 Feb 2015 04:58:54 -0800 (PST) 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 NYeGysP05v1V for ; Fri, 27 Feb 2015 04:58:52 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8C1A00F8 for ; Fri, 27 Feb 2015 04:58:52 -0800 (PST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 2DC441A0130 for ; Fri, 27 Feb 2015 13:58:51 +0100 (CET) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Feb 2015 13:58:50 +0100 References: <20150227125223.18650.88635.idtracker@ietfa.amsl.com> To: taps WG Message-Id: <901E2D80-6690-4236-9879-4016B722CCC7@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [Taps] Fwd: New Version Notification for draft-ietf-taps-transports-03.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, 27 Feb 2015 12:58:54 -0000 Greetings, all, We've posted rev -03 of the taps-transports document; this includes a = new Section 3.3. on SCTP by Michael Tuexen and a new section 3.4 on UDP = by Kevin Fall; thanks Michael and Kevin! Comments on the new sections or the structure thereof (i.e., as input to = future transport protocol sections), or indeed on anything else in the = document, are very welcome. :) Thanks, cheers, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: "Gorry Fairhurst" , "Mirja Kuehlewind" = , "Brian Trammell" , = "Mirja Kuehlewind" , "Godred Fairhurst" = , "Brian Trammell" > Subject: New Version Notification for = draft-ietf-taps-transports-03.txt > Date: 27 Feb 2015 13:52:23 CET >=20 >=20 > A new version of I-D, draft-ietf-taps-transports-03.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-ietf-taps-transports > Revision: 03 > Title: Services provided by IETF transport protocols = and congestion control mechanisms > Document date: 2015-02-27 > Group: taps > Pages: 25 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-taps-transports-03.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-taps-transports-03 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transports-03 >=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