From nobody Mon Jun 6 01:16:59 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEF312D0CB for ; Mon, 6 Jun 2016 01:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 RpnybPZ9i8Mx for ; Mon, 6 Jun 2016 01:16:55 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12AF212B009 for ; Mon, 6 Jun 2016 01:16:54 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b9piO-0000NV-6c for taps@ietf.org; Mon, 06 Jun 2016 10:16:52 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b9piN-00006K-C4 for taps@ietf.org; Mon, 06 Jun 2016 10:16:52 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> Date: Mon, 6 Jun 2016 10:16:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4276F9CA-AFB7-4347-95CB-0BA7FA0C9370@ifi.uio.no> References: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> To: "taps@ietf.org" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 4 sum msgs/h 2 total rcpts 42627 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3D03398230A8683575CB1CEC3BED9C9AFF40E003 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 10230 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] About the draft-ietf-taps-transports-usage rules X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 08:16:57 -0000 Hi all, Following up on this email, here's an extra thought. First, a quick summary of the long text below: - the goal is to enable automation - to make good use of protocols other than TPC or UDP *some* things must = be exposed, or else they can never be used (e.g. unordered message = delivery and partial reliability). These are the ones that we call = "functional" in draft-gjessing-taps-minset. - however, eventually a TAPS system should be able to hide as much as = possible (just not these "functional" things); therefore, including = primitives that are not covered in RFCs may be ok to do but is also = maybe not super important, depending on whether the primitives are = "functional" or not (and most of the ones that exist in implementations = but not in RFCs probably aren't). Second, the extra thought. With the rules I laid out for = draft-ietf-taps-transports-usage, I exclude Experimental RFCs and = primitives that MAY be implemented by a protocol. This removes MPTCP completely, which is probably just plain stupid. I = want to be strict for good reasons, but I don't want to be just plain = stupid :) Also, TFO requires a functional API change, yet it's Experimental... a = TAPS system can never make use of TFO unless its API change is = supported. That also seems just plain stupid to me. =3D> I think we should allow these things, but put them in an extra = section or an appendix (just like I said below about stuff coming from = code but not RFCs). One note: For the protocols that will be included in it, = draft-ietf-taps-transports-usage tries to cover *all* the SHOULD / MUST = primitives from standards-track RFCs. I definitely don't want to make a = rule that requires covering ALL the Experimental / MAY implement ... = etc. primtives - but it should be allowed to include them in the draft. Thoughts? Cheers, Michael > On 27 Apr 2016, at 10:16, Michael Welzl wrote: >=20 > Hi all, >=20 > This is mainly about criticism from Toerless. I thought of sending him = a private email (after I wanted to have a chat with him in Buenos Aires = but ran out of time), but thinking some more, I decided that this is = probably a matter of general interest: it's about the bigger picture of = TAPS. >=20 > Toerless has repeatedly criticized the use of RFCs as a basis for = developing the API in TAPS, when we have newer, better APIs available. >=20 >=20 > ***side note*** >=20 > Before continuing, let me pause and diverge a bit: much of Toerless' = criticism was related to the UDP API, and, as far as I understand, = multicast in particular (which isn't the focus of TAPS). Some of his = concrete points may be absolutely right and, not knowing enough, I = definitely don't take issue with them. Speaking for my own documents = (drafts I'm co-authoring), I also do not want to be *religious* about = using only the RFCs as a basis when it simply doesn't make sense - = however I would like to use them as much as possible and consider = diverging from my rules an exception, meaning that text should be marked = or even put in an appendix. The reason for being so attached to the RFCs = is that OSes have different concrete APIs, for good reason, and I think = we want to maintain the freedom developers have in implementing their = APIs as they wish. >=20 >=20 >=20 > ***main point of this email*** >=20 > Thinking about Toerless' general point of using more modern APIs made = me think of the bigger picture again. For example, one cool recent = feature in TCP APIs is the SO_SNDLOWAT socket option, which allows = better control of the sender buffer. Not including it in an API document = "sucks" and it IS nice to include it in a description of an API. >=20 > It is, however, also pretty irrelevant to the point of TAPS. Anyone is = free to implement the SO_SNDLOWAT socket option today, we don't need = TAPS for that. Neither do we need to change TCP for that. It's not even = necessary to describe it for TCP to be able to use it (won't hurt but = also won't gain us much). >=20 > I started the TAPS effort to ENABLE AUTOMATION. >=20 > This actually means *hiding* as much as possible. Today's stacks are = highly optimized and a lot of automation happens - but some things are = IMPOSSIBLE to automatize unless they are exposed in an API and an = application uses them. SCTP contains some obvious examples: unordered = delivery of messages and partial reliability. Try doing this to an = application that expects a reliable byte stream. So, no system even = tries to automatically use SCTP underneath the socket layer because many = of its benefits could never be utilized. >=20 > This is why we need to do something. This is why TAPS exists - to = specify that an API really should contain these transport service = features (as we call them), so that more (richer) automation becomes = possible. That's the whole point here. These are the transport service = features that, in draft-gjessing-taps-minset, we call "functional". >=20 > At the last meeting, we authors of draft-gjessing-taps-minset got the = feedback that we shouldn't put so much effort into trying to minimize = the number of exposed services. I agree with this feedback, but here = nevertheless I explain WHY we tried to minimize the number of services = and why the charter says "the subset of those Transport Services, as = identified in item 1, that end systems supporting TAPS will provide" - = because, to me (and in line with the charter, I claim), the REAL goal of = TAPS is to identify all these functional transport service features and = explain how a TAPS system providing them could be implemented. I agree = it makes sense to document more but I want to stress that that's not the = main point. In other words, I think if we'd end up with a list of ONLY = the functional transport service features of all the protocols we = consider, and then explain how they can be provided, then TAPS has = reached its goal: it would enable benefiting from other-than-TCP-or-UDP = protocols. >=20 > It's my impression that discussions in TAPS are perhaps too much = fueled by thinking about what modern APIs can do (as opposed to the old = RFCs). I think there's no harm in that and it can be useful, but the = REAL value comes from something else and we shouldn't lose focus on what = really matters here. In other words, I believe that Toerless' criticism = may be about things that aren't really very relevant to the goal of TAPS = (because implementing them is not related to increasing the ability to = automatize usage of mechanisms provided by protocols other than TCP and = UDP - just like SO_SNDLOWAT can be implemented today, using TCP, and = doesn't change anything about the intended automation). Note that I say = may, because perhaps I AM missing the point as I didn't understand = enough about the UDP API things he talked about, I do apologize if this = is all just me misunderstanding him! >=20 > Thoughts? > (I am a little worried that nothing that I wrote is new to people, = everyone agrees with me, and this is just me not getting Toerless' = points :( ) >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Jun 6 01:17:37 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2408E12B009 for ; Mon, 6 Jun 2016 01:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 19dW_AhR1qLZ for ; Mon, 6 Jun 2016 01:17:34 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919B412D0B9 for ; Mon, 6 Jun 2016 01:17:34 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b9pj2-0005zc-HW; Mon, 06 Jun 2016 10:17:32 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b9pj2-00006K-6V; Mon, 06 Jun 2016 10:17:32 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <57212E5E.1010201@isi.edu> Date: Mon, 6 Jun 2016 10:17:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <587A5745-96EC-4BE6-AE12-A3A467607B2E@ifi.uio.no> References: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> <57212E5E.1010201@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 6 sum msgs/h 3 total rcpts 42629 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.646, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0C3EAB86DEDE0E97C54843B119F9889E5C2E3203 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 10231 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] About old APIs from RFCs, and TAPS' real goal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 08:17:36 -0000 > On 27 Apr 2016, at 23:25, Joe Touch wrote: >=20 >=20 >=20 > On 4/27/2016 1:16 AM, Michael Welzl wrote: >> Thinking about Toerless' general point of using more modern APIs made >> me think of the bigger picture again. For example, one cool recent >> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows >> better control of the sender buffer. Not including it in an API >> document "sucks" and it IS nice to include it in a description of an >> API. >=20 > This is an interesting example. It affects how a user-level process > interacts with the protocol implementation inside the OS but has = NOTHING > to do with TCP. >=20 > I'm not sure where I would put that. It clearly isn't part of the TCP > API. Nor, e.g., would be the "nice" level of the process that's = feeding > data to TCP -- yet both could affect performance between two = applications. >=20 > It seems like there's a gap here you could drive a truck through that > needs to be addressed. I'm not sure where, though - i.e., whether this > is part of TAPS or not. Not part of TAPS I think, because it's not related to automatizing the = use of protocols other than TCP or UDP. Cheers, Michael From nobody Mon Jun 6 10:15:54 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E8512D861 for ; Mon, 6 Jun 2016 10:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 cIyoMDu3aJLa for ; Mon, 6 Jun 2016 10:15:50 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 5CC5B12D868 for ; Mon, 6 Jun 2016 10:15:50 -0700 (PDT) Received: from [128.9.184.141] ([128.9.184.141]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u56HFEEh023295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Jun 2016 10:15:14 -0700 (PDT) To: Michael Welzl References: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> <57212E5E.1010201@isi.edu> <587A5745-96EC-4BE6-AE12-A3A467607B2E@ifi.uio.no> From: Joe Touch Message-ID: <5755AF9F.1070904@isi.edu> Date: Mon, 6 Jun 2016 10:15:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <587A5745-96EC-4BE6-AE12-A3A467607B2E@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] About old APIs from RFCs, and TAPS' real goal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 17:15:51 -0000 On 6/6/2016 1:17 AM, Michael Welzl wrote: >> On 27 Apr 2016, at 23:25, Joe Touch wrote: >> >> >> >> On 4/27/2016 1:16 AM, Michael Welzl wrote: >>> Thinking about Toerless' general point of using more modern APIs made >>> me think of the bigger picture again. For example, one cool recent >>> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows >>> better control of the sender buffer. Not including it in an API >>> document "sucks" and it IS nice to include it in a description of an >>> API. >> This is an interesting example. It affects how a user-level process >> interacts with the protocol implementation inside the OS but has NOTHING >> to do with TCP. >> >> I'm not sure where I would put that. It clearly isn't part of the TCP >> API. Nor, e.g., would be the "nice" level of the process that's feeding >> data to TCP -- yet both could affect performance between two applications. >> >> It seems like there's a gap here you could drive a truck through that >> needs to be addressed. I'm not sure where, though - i.e., whether this >> is part of TAPS or not. > Not part of TAPS I think, because it's not related to automatizing the use of protocols other than TCP or UDP. Please explain why you think that's true. AFAICT, it's fundamental to how any protocol interacts with the OS. Joe From nobody Mon Jun 6 11:20:41 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F30E12D53B for ; Mon, 6 Jun 2016 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 6pS2OH-Y0QbM for ; Mon, 6 Jun 2016 11:20:35 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9405C12D0ED for ; Mon, 6 Jun 2016 11:20:34 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1b9z8a-000150-NT; Mon, 06 Jun 2016 20:20:32 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.102]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1b9z8a-0003R9-6p; Mon, 06 Jun 2016 20:20:32 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: <5755AF9F.1070904@isi.edu> Date: Mon, 6 Jun 2016 20:20:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5A26B41D-416D-4A6B-8B0F-6F79C21A721B@ifi.uio.no> References: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> <57212E5E.1010201@isi.edu> <587A5745-96EC-4BE6-AE12-A3A467607B2E@ifi.uio.no> <5755AF9F.1070904@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 42683 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 28550E76E3601A8E9131229E27CDA75DDF4EE617 X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1227 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] About old APIs from RFCs, and TAPS' real goal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:20:37 -0000 > On 6. jun. 2016, at 19.15, Joe Touch wrote: >=20 >=20 >=20 > On 6/6/2016 1:17 AM, Michael Welzl wrote: >>> On 27 Apr 2016, at 23:25, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 4/27/2016 1:16 AM, Michael Welzl wrote: >>>> Thinking about Toerless' general point of using more modern APIs = made >>>> me think of the bigger picture again. For example, one cool recent >>>> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows >>>> better control of the sender buffer. Not including it in an API >>>> document "sucks" and it IS nice to include it in a description of = an >>>> API. >>> This is an interesting example. It affects how a user-level process >>> interacts with the protocol implementation inside the OS but has = NOTHING >>> to do with TCP. >>>=20 >>> I'm not sure where I would put that. It clearly isn't part of the = TCP >>> API. Nor, e.g., would be the "nice" level of the process that's = feeding >>> data to TCP -- yet both could affect performance between two = applications. >>>=20 >>> It seems like there's a gap here you could drive a truck through = that >>> needs to be addressed. I'm not sure where, though - i.e., whether = this >>> is part of TAPS or not. >> Not part of TAPS I think, because it's not related to automatizing = the use of protocols other than TCP or UDP. >=20 > Please explain why you think that's true. >=20 > AFAICT, it's fundamental to how any protocol interacts with the OS. Yes it is, but it=92s also orthogonal to the choice of protocol - as you = said, it really has nothing to do with TCP. Using my typical example again: you can=92t use an SCTP mechanism like = e.g. unordered message delivery without knowing that the application = wants it, or else you=92ll break the semantics of the application data = stream. It's is a mechanism of SCTP that simply cannot be used unless it=92s = chosen via an API. Can you say the same about this SO_SNDLOWAT stuff? As far as I=92m = concerned such send buffer management is an implementation detail - you = could implement this very well or extremely badly for every protocol - = but even an implementation that gives you almost no choice of what goes = on in the buffer does not prohibit you from using a mechanism that a = protocol provides. It=92s a different matter, because the semantics stay = unaltered: if you set the buffer very small with SO_SNDLOWAT, TCP will = just fail on you. It=92s not going to lose any packets, it stays = reliable. If you could make it lose packets by changing SO_SNDLOWAT, = that would be a different matter I think... Cheers, Michael From nobody Mon Jun 6 11:34:58 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8740912D528 for ; Mon, 6 Jun 2016 11:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 5cmU5nPwMeUL for ; Mon, 6 Jun 2016 11:34:55 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 20DE312D526 for ; Mon, 6 Jun 2016 11:34:55 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id u56IYZKO014454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Jun 2016 11:34:35 -0700 (PDT) To: Michael Welzl References: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> <57212E5E.1010201@isi.edu> <587A5745-96EC-4BE6-AE12-A3A467607B2E@ifi.uio.no> <5755AF9F.1070904@isi.edu> <5A26B41D-416D-4A6B-8B0F-6F79C21A721B@ifi.uio.no> From: Joe Touch Message-ID: Date: Mon, 6 Jun 2016 11:34:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5A26B41D-416D-4A6B-8B0F-6F79C21A721B@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 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] About old APIs from RFCs, and TAPS' real goal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 18:34:56 -0000 On 6/6/2016 11:20 AM, Michael Welzl wrote: >> On 6. jun. 2016, at 19.15, Joe Touch wrote: >> >> >> >> On 6/6/2016 1:17 AM, Michael Welzl wrote: >>>> On 27 Apr 2016, at 23:25, Joe Touch wrote: >>>> >>>> >>>> >>>> On 4/27/2016 1:16 AM, Michael Welzl wrote: >>>>> Thinking about Toerless' general point of using more modern APIs made >>>>> me think of the bigger picture again. For example, one cool recent >>>>> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows >>>>> better control of the sender buffer. Not including it in an API >>>>> document "sucks" and it IS nice to include it in a description of an >>>>> API. >>>> This is an interesting example. It affects how a user-level process >>>> interacts with the protocol implementation inside the OS but has NOTHING >>>> to do with TCP. >>>> >>>> I'm not sure where I would put that. It clearly isn't part of the TCP >>>> API. Nor, e.g., would be the "nice" level of the process that's feeding >>>> data to TCP -- yet both could affect performance between two applications. >>>> >>>> It seems like there's a gap here you could drive a truck through that >>>> needs to be addressed. I'm not sure where, though - i.e., whether this >>>> is part of TAPS or not. >>> Not part of TAPS I think, because it's not related to automatizing the use of protocols other than TCP or UDP. >> Please explain why you think that's true. >> >> AFAICT, it's fundamental to how any protocol interacts with the OS. > Yes it is, but it’s also orthogonal to the choice of protocol - as you said, it really has nothing to do with TCP. Yes, but configuration of the OS interface isn't orthogonal to that choice. I.e., constraints of the OS interface may play into the decision of which transport to use, and which transport is chosen may affect the configuration of that OS interface. > Using my typical example again: you can’t use an SCTP mechanism like e.g. unordered message delivery without knowing that the application wants it, or else you’ll break the semantics of the application data stream. > It's is a mechanism of SCTP that simply cannot be used unless it’s chosen via an API. > > Can you say the same about this SO_SNDLOWAT stuff? As far as I’m concerned such send buffer management is an implementation detail - you could implement this very well or extremely badly for every protocol The way the OS relays information to the transport IS a protocol - just not one that involves communication on the wire. It significantly affects the way in which the transport operates. > - but even an implementation that gives you almost no choice of what goes on in the buffer does not prohibit you from using a mechanism that a protocol provides. Sure, but if you're trying to set TCP to very low latency and use a huge socket buffer, you could easily be creating huge delays and jitter in the interaction between the process scheduling to fill the buffer and the transfer of info into TCP. > It’s a different matter, because the semantics stay unaltered: if you set the buffer very small with SO_SNDLOWAT, TCP will just fail on you. It’s not going to lose any packets, it stays reliable. If you could make it lose packets by changing SO_SNDLOWAT, that would be a different matter I think... It might not affect TCP, but it could affect a protocol that can choose between ARQ and FEC and use ARQ only where the latency budget permits. Joe From nobody Mon Jun 6 13:14:23 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C712D907 for ; Mon, 6 Jun 2016 13:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 zuATWWCmoOYT for ; Mon, 6 Jun 2016 13:14:19 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C323612D906 for ; Mon, 6 Jun 2016 13:14:18 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1bA0ue-0007Qx-Tt; Mon, 06 Jun 2016 22:14:16 +0200 Received: from 3.134.189.109.customer.cdi.no ([109.189.134.3] helo=[192.168.0.102]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1bA0ue-00087X-AN; Mon, 06 Jun 2016 22:14:16 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Michael Welzl In-Reply-To: Date: Mon, 6 Jun 2016 22:14:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <852E1797-38C1-46D6-8724-E29351DF2164@ifi.uio.no> <57212E5E.1010201@isi.edu> <587A5745-96EC-4BE6-AE12-A3A467607B2E@ifi.uio.no> <5755AF9F.1070904@isi.edu> <5A26B41D-416D-4A6B-8B0F-6F79C21A721B@ifi.uio.no> To: Joe Touch X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 3 total rcpts 42688 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DAD96A19EA097FC154FE6808F0B86A3A7BFB7C2C X-UiO-SPAM-Test: remote_host: 109.189.134.3 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1231 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] About old APIs from RFCs, and TAPS' real goal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:14:21 -0000 > On 6. jun. 2016, at 20.34, Joe Touch wrote: >=20 >=20 >=20 > On 6/6/2016 11:20 AM, Michael Welzl wrote: >>> On 6. jun. 2016, at 19.15, Joe Touch wrote: >>>=20 >>>=20 >>>=20 >>> On 6/6/2016 1:17 AM, Michael Welzl wrote: >>>>> On 27 Apr 2016, at 23:25, Joe Touch wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 4/27/2016 1:16 AM, Michael Welzl wrote: >>>>>> Thinking about Toerless' general point of using more modern APIs = made >>>>>> me think of the bigger picture again. For example, one cool = recent >>>>>> feature in TCP APIs is the SO_SNDLOWAT socket option, which = allows >>>>>> better control of the sender buffer. Not including it in an API >>>>>> document "sucks" and it IS nice to include it in a description of = an >>>>>> API. >>>>> This is an interesting example. It affects how a user-level = process >>>>> interacts with the protocol implementation inside the OS but has = NOTHING >>>>> to do with TCP. >>>>>=20 >>>>> I'm not sure where I would put that. It clearly isn't part of the = TCP >>>>> API. Nor, e.g., would be the "nice" level of the process that's = feeding >>>>> data to TCP -- yet both could affect performance between two = applications. >>>>>=20 >>>>> It seems like there's a gap here you could drive a truck through = that >>>>> needs to be addressed. I'm not sure where, though - i.e., whether = this >>>>> is part of TAPS or not. >>>> Not part of TAPS I think, because it's not related to automatizing = the use of protocols other than TCP or UDP. >>> Please explain why you think that's true. >>>=20 >>> AFAICT, it's fundamental to how any protocol interacts with the OS. >> Yes it is, but it=92s also orthogonal to the choice of protocol - as = you said, it really has nothing to do with TCP. > Yes, but configuration of the OS interface isn't orthogonal to that = choice. >=20 > I.e., constraints of the OS interface may play into the decision of > which transport to use, and which transport is chosen may affect the > configuration of that OS interface. >=20 >> Using my typical example again: you can=92t use an SCTP mechanism = like e.g. unordered message delivery without knowing that the = application wants it, or else you=92ll break the semantics of the = application data stream. >> It's is a mechanism of SCTP that simply cannot be used unless it=92s = chosen via an API. >>=20 >> Can you say the same about this SO_SNDLOWAT stuff? As far as I=92m = concerned such send buffer management is an implementation detail - you = could implement this very well or extremely badly for every protocol >=20 > The way the OS relays information to the transport IS a protocol - = just > not one that involves communication on the wire. It significantly > affects the way in which the transport operates. >> - but even an implementation that gives you almost no choice of what = goes on in the buffer does not prohibit you from using a mechanism that = a protocol provides.=20 > Sure, but if you're trying to set TCP to very low latency and use a = huge > socket buffer, you could easily be creating huge delays and jitter in > the interaction between the process scheduling to fill the buffer and > the transfer of info into TCP. >> It=92s a different matter, because the semantics stay unaltered: if = you set the buffer very small with SO_SNDLOWAT, TCP will just fail on = you. It=92s not going to lose any packets, it stays reliable. If you = could make it lose packets by changing SO_SNDLOWAT, that would be a = different matter I think... > It might not affect TCP, but it could affect a protocol that can = choose > between ARQ and FEC and use ARQ only where the latency budget permits. You seem to be saying =93whether a protocol is implemented efficiently = or inefficiently can affect the protocol choice=94. It can - but it doesn=92t translate into a necessity to provide = something in the API or not. E.g., you could have neither TCP nor SCTP provide something in the style = of SO_SNDLOWAT, or both - either way, which protocol is a better choice = isn=92t affected by the SO_SNDLOWAT functionality. If only one of them = implements it, it becomes less efficient to use it if the application = makes demands regarding buffer usage, and makes it a less favorable = choice. If the TCP receiver doesn=92t implement SACK, this may make TCP = a less favorable choice too. There are many such implementation details = =85 but I can=92t see what a TAPS RFC should state in order to limit = these problems or make things play out better. But now I=92m confused :-( I=92m thinking of Nagle=85 you need to offer it in the API or you can=92t = use it. Why wouldn=92t SO_SNDLOWAT be in the same category? So maybe I=92m just wrong. Cheers, Michael From nobody Mon Jun 20 11:53:57 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C512D677 for ; Mon, 20 Jun 2016 11:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 sZHwj_dvhIyK for ; Mon, 20 Jun 2016 11:53:55 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A8D12D66D for ; Mon, 20 Jun 2016 11:53:54 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id u64so207503980vkf.3 for ; Mon, 20 Jun 2016 11:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JO2f34sNq9dGET2Iqn/6ov8PKAv8GaIrM4qg5p838Ig=; b=gI41sZJjuy/ACo5gZRCP5J3GAL2mADGvxQlbyf3dydsQ9HAfiNW+7KbHtbYbGO11lA omI2cZ4Gz7cOJWDQiZ0FODa9a7bs6Vahn+PQTnP6hYWA2sNu+LIJs8r3A7n30uujGw+C CR4Evaz+LEj0aF01UQaH8hpLMbxrsSwTWiZr0kCDSoCHUfjybUx3n2pErduWpojaNZvC qdlQiU4nyGfKPmvGRWYeYKv6pBgni45d1wC6Pm6BaNIYjY45m4nw0Le+UdFilhGRzlOX lsUokhCzguEtyRYRoVf3aewMMFnM7pPj9G2n1kR6Pufc7B1/hvcP+Aaujn6Z5Fww1aBk bLCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JO2f34sNq9dGET2Iqn/6ov8PKAv8GaIrM4qg5p838Ig=; b=R6I7Na9yhj704EXjeYenhJcLR/LkWoru1EcaKcrsqyNkaPVF3l7kQpR3t2yd8H+SjC 0X6I+hOKYxqypuw0ky7dQ09iAeFft+pgjHMTdSUUzRIvYgnKBhLpRxsmrNvB3hXpIxLC Vh3PQeeMotNgnzeiiArQNbqA4GldFmrTtDbekM9GFywFXMqkVUjeAk0Ztn8JhRRhtX/i WqgIecfZT6HlWcMaPNRMwi3tQPq76Su4+qm/jn2Agjlr9KBH5k/r+WpXCzQq86BsvP5e Ws/93ACeNM2yRS2mUI6wbq0AKLnYz6xJfYQ4Y6s1YoMZRG8otvP9VB2f2M25jmrckCty PM/A== X-Gm-Message-State: ALyK8tLaBuThLbT4hbnWNehHy8T7TvyCwXBaSfFiuVy0W2ZDWRXqolUHEJxi9pePmJFd9FyML+bLpNnhUIZ+HQ== X-Received: by 10.176.5.3 with SMTP id 3mr7372707uax.52.1466448833898; Mon, 20 Jun 2016 11:53:53 -0700 (PDT) MIME-Version: 1.0 References: <20160620185240.30170.89717.idtracker@ietfa.amsl.com> In-Reply-To: <20160620185240.30170.89717.idtracker@ietfa.amsl.com> From: Aaron Falk Date: Mon, 20 Jun 2016 18:53:43 +0000 Message-ID: To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c12518cd36f550535ba39ab Archived-At: Subject: [Taps] Fwd: Publication has been requested for draft-ietf-taps-transports-10 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 18:53:56 -0000 --94eb2c12518cd36f550535ba39ab Content-Type: text/plain; charset=UTF-8 FYI. --aaron ---------- Forwarded message --------- From: Aaron Falk Date: Mon, Jun 20, 2016 at 2:52 PM Subject: Publication has been requested for draft-ietf-taps-transports-10 To: Cc: Aaron Falk , , < iesg-secretary@ietf.org> Aaron Falk has requested publication of draft-ietf-taps-transports-10 as Informational on behalf of the TAPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ -- --aaron =====Short message from my phone===== --94eb2c12518cd36f550535ba39ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--
--aaron

=3D=3D=3D=3D=3DShort message from my= phone=3D=3D=3D=3D=3D
--94eb2c12518cd36f550535ba39ab-- From nobody Wed Jun 22 14:12:28 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D223312DBD4 for ; Wed, 22 Jun 2016 14:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 YwbaLzAqC0IY for ; Wed, 22 Jun 2016 14:12:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAE212D755 for ; Wed, 22 Jun 2016 14:12:23 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-fa-576aff369afd Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.74.27088.63FFA675; Wed, 22 Jun 2016 23:12:22 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 22 Jun 2016 23:12:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LDUpc1612eVGfX24TuDuX/lOcUhSsg3PEqSraPr9Dzo=; b=es7Q/mH41G1U4g7ni0vZsPTOnEix+lXXimTapMORdvlnpLQ3tIEsVdstMgpZJva5BHhg9zSE8T2/P1lQxPsPBkIneZO/jMrYBwfx1KcgLmzJg9pOxVeQRfK8LC2uzzn6CHUegYkg/7Ff4pwLjOSakORU3P5Ei9uxDDMku+KNy0I= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB289.eurprd07.prod.outlook.com (10.242.108.148) with Microsoft SMTP Server (TLS) id 15.1.501.7; Wed, 22 Jun 2016 21:12:20 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::bdec:fa0b:43c6:f05e]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::bdec:fa0b:43c6:f05e%14]) with mapi id 15.01.0517.014; Wed, 22 Jun 2016 21:12:21 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: Please send agenda request!! Thread-Index: AdHMybiMBbL3AQxISL+I76RUCE6vwg== Date: Wed, 22 Jun 2016 21:12:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [95.109.38.59] x-ms-office365-filtering-correlation-id: b315ecd8-8e36-49bd-35c8-08d39ae1e666 x-microsoft-exchange-diagnostics: 1; AM3PR07MB289; 5:TA/GxM+7FR3D86HTWgxrH/lqJO/TyG0td6sKBGD3tmVJ1f4YEDAU/1nLXTibyyMkoa9i6bIouflM16fRqCsS9UwvHVQhRoUge2AFIyfVJZ2qzlO9mo7PM3yVssKWOqh3uiOFQy7bXVy3k2snSUIUFA==; 24:OihmkRvwKx+xSsuuFvW32Ad8VtNuddMm38vYBgGQ1NUEkKGMIh7bI+/Wzx8bl5c9+PY5nFQMUwwqvHk7MqBlrGoDQixKelK01ue2h08g2AM=; 7:MPvwEJeD5ZmwpiClEt1o7dv3NFmWWEaVB4w80XjmLPuKgp8assO5VOiq1tcL1to5JW8lAVCg1SmiAFKjVBEyX0qPOJo7SWBqt5VNaZHBzMQIjnqRVMiPMvs30aCmL4w0oC39KhUSUgYEB5SO1Kn3oGSgQ1ILPHz4pGoGPfysZPJIPjwkXXqROesRwOwThfsL x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB289; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM3PR07MB289; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB289; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(53754006)(86362001)(1730700003)(226693001)(81166006)(2906002)(33656002)(3660700001)(5640700001)(92566002)(74316001)(81156014)(5250100002)(305945005)(3280700002)(105586002)(2501003)(50986999)(54356999)(106356001)(68736007)(7846002)(7696003)(2900100001)(15975445007)(9686002)(102836003)(6116002)(3846002)(2351001)(450100001)(8936002)(5002640100001)(19580395003)(76576001)(5003600100003)(101416001)(8676002)(97736004)(66066001)(87936001)(189998001)(107886002)(3480700004)(7736002)(586003)(229853001)(110136002)(225543005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB289; H:AM3PR07MB292.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB292EC2AD3AEBBF84CC079129F2C0AM3PR07MB292eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 21:12:21.0617 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB289 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0iTURjGPfsuflqj05r6ooI2C8FsqZRFSdQfRv+kUoimQi39cLN5Yd+S jC4LNNak0Cy8UV5Sk9TEFBMvOEdapqDVxBI3lJlOLAphRkTa5pngf7/3ed5zeJ7D4ShJNePP qXK0vCZHoZax3nRl8hufg9EbWUkRk51+x2bTTqGzDQ1/RAkoxTsmg1er8nnNoZOXvZVD+nXP vFc7rjvs31gdWvAyIC8O8GGYnxr3JOwLk9Z21oC8OQl+i2CkpEtEhlEEzYujjGug8QMKptqr 3c6Uc838iybDPIKWrmrnZRzH4hiwPY9z3SvFIfB5sIN18R68HzofD1NED4O7jz4yhOXQ2Gym XEdp585KXbhLFuMUGKvvF7kYOeP9/tC6yRT2g5mFGhGJjaGhf4Ii7APLtnWG7KfDE0cRS/Rg +FJeShM+ByPDg25ep2DeGk04FnrmJpArAmAV6Nf2Efk46EvfbXYH3IbA+LXM/VyBMG39iYgx z8D70oHNQBLMw4u2IkT6+oPFfN/NgWCfHWBIgVyYKO5lSlBo1bY+Vdusqs3+u2G0coEmejjU 9q2yhA9AU90KtcXjRptou16LPF8iH4EXrmRnRkXJeY0qXRByc+Q5vPY1cn6Zoa6/ET1oeem0 CWEOyXaKgz9lJUkYRb5QkG1CwFEyqbjwn1MSZygKbvCa3Euaa2peMKEAjpb5ieOX9yZJcKZC y1/l+Txes+WKOC9/HdIO6oVdBnVf0+yF5ICKBOXFMXw0zm5r+F4+blFLx8ut92osR5jVmESu ngq66YEf/ihb8y1mDfEdFR5nUnqfttxJ7bWZYrmRxiK5Q6k2hs4VPDthPx8SVLhkKUzVtDpa bnXr/KRSY9qGzgcWIxNp8/SMqTi4OTfxdnemCsloQamIDKM0guI/VHgyZy4DAAA= Archived-At: Subject: [Taps] Please send agenda request!! X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 21:12:27 -0000 --_000_AM3PR07MB292EC2AD3AEBBF84CC079129F2C0AM3PR07MB292eurprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, As indicated in the preliminary IETF96 agenda this time we have an 1(one) h= our slot for TAPS WG. We have started planning for the meeting. Please send agenda request for TAPS WG meeting in IETF96, Berlin. BR Zahed and Aaron. --_000_AM3PR07MB292EC2AD3AEBBF84CC079129F2C0AM3PR07MB292eurprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
As indicated in the preliminary IETF96 agenda this time we have an 1(o= ne) hour slot for TAPS WG. We have started planning for the meeting.
 
Please send agenda request for TAPS WG meeting in IETF96, Berlin.
 
BR
 
Zahed and Aaron.
 
 --_000_AM3PR07MB292EC2AD3AEBBF84CC079129F2C0AM3PR07MB292eurprd_-- From nobody Fri Jun 24 09:07:34 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D40D12DD20; Fri, 24 Jun 2016 09:00:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160057.10933.49544.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:57 -0700 Archived-At: Cc: spencerdawkins.ietf@gmail.com, taps@ietf.org Subject: [Taps] taps - Requested session has been scheduled for IETF 96 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:57 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (1:30:00) Thursday, Afternoon Session III 1830-1930 Room Name: Bellevue size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: apparea appsawg tsvarea aqm rmcat ippm tsvwg iccrg tcpm dispatch Second Priority: webpush tcpinc nvo3 mptcp icnrg httpbis irtfopen Third Priority: mmusic tram Special Requests: --------------------------------------------------------- From nobody Tue Jun 28 13:52:32 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB8912D895 for ; Tue, 28 Jun 2016 13:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 0Tf_lA7ruhOG for ; Tue, 28 Jun 2016 13:52:02 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D49C12D82D for ; Tue, 28 Jun 2016 13:51:34 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-e9-5772e354be65 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 33.BB.12516.453E2775; Tue, 28 Jun 2016 22:51:32 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 28 Jun 2016 22:51:31 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9YHdUD2+v8mqzD3yuU3yeJsVm69OxNSQSjzut1MzU9M=; b=Mxo8PcOtP0AWlLU4VbUqamF6TRfDF8GdWv/Nqe0OMb5AwtbH3sBLUKT46IJY5wOrQNompe7/QxSr7C3Chc4YsBEmmLsTh2DEXGktwQi54bjQYi2DUtWqKIe+mseKI+QfFYQDtMebYSf7J/lhgoFuV4bFIy6Lp4pqEkZfs1GRyBM= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB290.eurprd07.prod.outlook.com (10.242.108.149) with Microsoft SMTP Server (TLS) id 15.1.528.16; Tue, 28 Jun 2016 20:51:29 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::bdec:fa0b:43c6:f05e]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::bdec:fa0b:43c6:f05e%14]) with mapi id 15.01.0517.016; Tue, 28 Jun 2016 20:51:29 +0000 From: Zaheduzzaman Sarker To: "taps@ietf.org" Thread-Topic: Draft agenda for IETF96 Thread-Index: AdHRfGFNV5QBZAzlTJCTELtjvHLMZg== Date: Tue, 28 Jun 2016 20:51:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [95.109.38.59] x-ms-office365-filtering-correlation-id: 9bdbb38f-bdf8-43ff-75bb-08d39f95fac1 x-microsoft-exchange-diagnostics: 1; AM3PR07MB290; 6:m7rcLgXdNJgNGcMsmf+/Tgde/5w/JCJa5IbUTqN+LFtd0yViy6LSG2+E5CMsRO37iAD+m5qvplOIhzqnCa4bm5JKCMANDFoqGL5qYuloBror98G0e326/FSJRe9TaIt0G845xWWCIoDbn82fiFOJTHiutKmi3lJ+K+OAcfkBGLBiP0TgwuLs8LH+mczXV5+Afe/kXHk9zVsGh/4vd+MhpvNfGoArnynuTsb4jy/2a1FkCREahwi18RvhDxltrK0CKTOOckkcB1GnbsYK7qKzvGj1zIyScK+//LTcfykRpcw=; 5:jISG4xHqBTbZSaB8b/ttEXR74OOab7qV0N17k8fuFPCX5XFYLIztXiD0a3NqSrhG06ZZzuWooG1qWJ0FFj4m7MvrpXB8NSHRL+QE2wCy2f65BS1nTx+0bk4B9cGNu+Luswt6ABLfiGZKDsng82PnUA==; 24:UbnUqGjqFbfDkxZQzR3/2oQvxbCHj8WKCM9sw0loob9PeKiIySPmzUGM8kDrAfK8hoLovo44DjNw3xPw4syn2E8cjmk8PpB8ns+CT0NkSX0=; 7:L2aR56uyOjsmzbHAP1pXO5YqQtTsMsZkdBB9toM3O2Yq43+p1X7xWfp/frZ73q7844DLad5VGeOZnc/5If3jr0U3C5wWri0gsSfkv97UtO7K+Gvo3SupZ4rALZ5loSQDwWMp7hcqEBudv5I/TWgt0ALPGk2ovLq7/yqCQu4YR+4ZxyS7Z1k6D2wnopngoRZu1EhWp7TTb6S+UZtE+eMQx3kPDklEzBnFGNBmA+PPqWCmqsLrDOpo3anDSpRz4gJu x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB290; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AM3PR07MB290; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB290; x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(53754006)(33656002)(107886002)(3280700002)(5640700001)(19580395003)(7696003)(5003600100003)(7736002)(7846002)(74316001)(305945005)(3660700001)(68736007)(2501003)(189998001)(66066001)(450100001)(8676002)(92566002)(5250100002)(1730700003)(110136002)(81166006)(81156014)(8936002)(11100500001)(5002640100001)(97736004)(586003)(229853001)(2906002)(2900100001)(106356001)(105586002)(6116002)(9686002)(76576001)(101416001)(86362001)(54356999)(50986999)(87936001)(102836003)(15975445007)(2351001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB290; H:AM3PR07MB292.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB292CA2EE6D974479C126B5D9F220AM3PR07MB292eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 20:51:29.4437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB290 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01Sa0hTYRju29k5O4qr43L5phJrIkLhukn6Q6ILRtFNKJqImUtPOtJNzzHL IFqkaYqV4tANIcVhZdPMLoZOc1OTiaVoqcisvEUi+qNMiWDL7Vvgv+d9Li/v8/HRhKSaDKLV mhyW06gy5JSv0BDfGhxxboZT7nbdl0U7Eg+iYybTH0EcSvCNSWUz1Lkst+tAsm96x3CNIOsD XB/WmUU61CUtRj40MJGgf1lEYLwFhr48p4qRLy1hehC09xcJ8WBHYP3VSrldQqaUgM43l7Ew iiDf3C7CwxSC5acTay6appgYmKk77Q4EMKEw8u6FJ7yZkUH3kpnCfBjMlrcgtz2AUUCpIRnv D4PpwkGBG4uZBLjbXOixo7XrVvvNHp5gAmFi9pEAX82AyTLobSCF+Rknif0poP9dQGFeBuOV ZUKMT4G5scnTEphFCm5/NyAsxMKk7SOJsRosxa0ijE+AzWIlcaARgctY6d0aAnVLDq8wQEL3 VJMnLWFYeNxYgHDjIJj8dM+LQ+CHo4PEFbTws6scPUThxnWNjOsko+cF/MFumBViXgHj+goK 451QX7tAYBwBVU6bcD1fg0QNSMqzPJ+ZtnefguXUKTyv1Sg0bE4LWvsz1ld/I96iZwuHbIih kdxP/K02WykhVbl8XqYNAU3IA8QNU5xSIk5V5d1gOe1F7moGy9tQMC2UB4rPzG9XSpg0VQ57 hWWzWO6/KqB9gnToQuYl/+kx/RPnaLfDFflAd3TZ+rnEUtWX3N+XMjm0qWNb4kD1NUv0nJNo vlMxFqc53r7iSlh2jKf7+IVvaGt7z5fYy/VnerUnY3Vk/NnDIec3JpU0rIyszpnKpFtDY3vK ZLfGFvdrV+j62t6kqE6/ZuUifST/ZvbXyIHsqNf2eLmQT1ft2UFwvOofElQnri8DAAA= Archived-At: Subject: [Taps] Draft agenda for IETF96 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 20:52:15 -0000 --_000_AM3PR07MB292CA2EE6D974479C126B5D9F220AM3PR07MB292eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Here is the draft agenda for IETF 96, Berlin meeting. Time slot : 1 Hour. 1. Chairs update - 5min 2. Update on draft-ietf-taps-transports-usage - 15 min (Naeem Khademi ) - upd= ated draft promised by the authors. 3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorr= y Fairhurst) - already updated. 4. Update on draft-gjessing-taps-minset -15 min (Michael Welzl) - updated draft pro= mised by the authors. 5. Investigation on the use on happy eyeballs for transport protocol s= election - 5 min (Anna Bruns= tr=F6m) 6. Post socket -10 min (Brian Trammell) BR Zahed and Aaron --_000_AM3PR07MB292CA2EE6D974479C126B5D9F220AM3PR07MB292eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,
 
Here is the draft agenda for IETF 96, Berlin meeting.
 
Time slot : 1 Hour.
 
  1. Chairs update - 5min
  2. Update on draf= t-ietf-taps-transports-usage - 15 min (Naeem Khademi ) ̵= 1; updated draft promised by the authors.
  3. Update on <= font color=3D"blue">draft-fairhurst-taps-transports-usage-udp= - 5 min (Gorry Fairhurst) – already updated.
  4. Update on <= a href=3D"https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/">draft-gjessing-taps-minset -15 min (Mic= hael Welzl) - updated draft promised by the authors.
  5. Investigation= on the use on happy eyeballs for transport protocol selection - 5 min (Anna Brunstr=F6m)
  6. Post socket -10 min (Brian Tra= mmell)
 
 
BR
 
Zahed and Aaron
 
 
 
--_000_AM3PR07MB292CA2EE6D974479C126B5D9F220AM3PR07MB292eurprd_-- From nobody Wed Jun 29 15:04:10 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE512D86C for ; Wed, 29 Jun 2016 15:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 rx_LXtQL5K6E for ; Wed, 29 Jun 2016 15:04:06 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (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 F392B12D5AF for ; Wed, 29 Jun 2016 15:04:00 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 30 Jun 2016 00:03:54 +0200 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 62.92.134.70 X-MDArrival-Date: Thu, 30 Jun 2016 00:03:54 +0200 X-Authenticated-Sender: anna.brunstrom@kau.se X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org To: taps@ietf.org References: From: Anna Brunstrom Message-ID: Date: Thu, 30 Jun 2016 00:03:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EC751C9D2DF9007A5BF6CA55" Archived-At: Subject: Re: [Taps] Draft agenda for IETF96 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 22:04:09 -0000 This is a multi-part message in MIME format. --------------EC751C9D2DF9007A5BF6CA55 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all, The presentation on Happy Eyeballs will be a summary of a presentation given at the Applied Networking Research Workshop (ANRW), held on the Saturday before the IETF. So if you are there on Saturday and are interested, you have a chance for a longer version. Cheers, Anna On 2016-06-28 22:51, Zaheduzzaman Sarker wrote: > Hi all, > Here is the draft agenda for IETF 96, Berlin meeting. > Time slot : 1 Hour. > > 1. Chairs update - 5min > 2. Update on _draft-ietf-taps-transports-usage_ > > - 15 min (Naeem Khademi ) – updated draft promised by the authors. > 3. Update on _draft-fairhurst-taps-transports-usage-udp_ > > - 5 min (Gorry Fairhurst) – already updated. > 4. Update on _draft-gjessing-taps-minset_ > -15 > min (Michael Welzl) - updated draft promised by the authors. > 5. Investigation on the use on _happy eyeballs for transport protocol > selection_ - 5 min > (Anna Brunström) > 6. Post socket -10 min (Brian Trammell) > > BR > Zahed and Aaron > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------EC751C9D2DF9007A5BF6CA55 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi all,

The presentation on Happy Eyeballs will be a summary of a presentation given at the Applied Networking Research Workshop (ANRW), held on the Saturday before the IETF. So if you are there on Saturday and are interested, you have a chance for a longer version.

Cheers,
Anna

On 2016-06-28 22:51, Zaheduzzaman Sarker wrote:
Hi all,
 
Here is the draft agenda for IETF 96, Berlin meeting.
 
Time slot : 1 Hour.
 
  1. Chairs update - 5min
  2. Update on draft-ietf-taps-transports-usage - 15 min (Naeem Khademi ) – updated draft promised by the authors.
  3. Update on draft-fairhurst-taps-transports-usage-udp - 5 min (Gorry Fairhurst) – already updated.
  4. Update on draft-gjessing-taps-minset -15 min (Michael Welzl) - updated draft promised by the authors.
  5. Investigation on the use on happy eyeballs for transport protocol selection - 5 min (Anna Brunström)
  6. Post socket -10 min (Brian Trammell)
 
 
BR
 
Zahed and Aaron
 
 
 
 

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

--------------EC751C9D2DF9007A5BF6CA55--