From nobody Tue May 12 07:56:18 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3A01A890E for ; Tue, 12 May 2015 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 J4WNslk1FZrC for ; Tue, 12 May 2015 07:56:10 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCC41B2E1B for ; Tue, 12 May 2015 07:56:03 -0700 (PDT) Received: from nb-10604.ethz.ch (nb-10604.ethz.ch [82.130.102.91]) by trammell.ch (Postfix) with ESMTPSA id 640A41A05E5 for ; Tue, 12 May 2015 16:56:02 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail 2.5b6 Content-Type: multipart/signed; boundary="Apple-Mail=_56577A06-EDD2-4C05-8E4F-E97246C0F8AC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 12 May 2015 16:56:02 +0200 Message-Id: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch> To: hops@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [hops] Proposed HOPS Research Group charter X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 14:56:12 -0000 --Apple-Mail=_56577A06-EDD2-4C05-8E4F-E97246C0F8AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Following up on the successful BarBoF in Dallas, we would like to = propose a first HOPS (proposed) research group meeting in Prague. The = draft charter text is attached for comment. Cheers, Brian and Mirja How Ossified is the Protocol Stack? (HOPS) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. 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 [1] 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, the HOPS research group will provide a = discusion forum to coordinate efforts in research and industry -- such = as network stack, browser, and middlebox vendors, as well as network and = service operators -- on collecting and reporting statistics about = middlebox impact on transport sessions. [1] 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. Objective --------- The HOPS research group follows from the successful BarBoF meeting = organized by Aaron Falk at IETF92 in Dallas to bring more data on the = nature and extent of middlebox interference to protocol design and = engineering efforts. To this end, we aim to provide a forum for = discussion and exchange of measurement insights, data, and techniques = co-located with IETF meetings. The BarBoF identified the need for this = forum, with many participants wanting a place to continue these = discussions. In addition, we have identified two near-term goals to be completed = within the research group in support of this work. First is the definition of a common format for reporting on middlebox = impairments observed in the network, whether these observations are made = passively, actively, or as a side effect of some other operation, e.g. = taken from application or network stack error logs. This common format = must provide for correlation and comparison among data from disjoint = observations, and address end-user privacy and business confidentiality = concerns, e.g. using path pseudonyms instead of paths identified by AS = number and/or IP address where necessary. These measurements should be = useful not only for detecting impairments but also for assessing the = likelihood that a certain impairment will be experienced by traffic on = certain types of networks and in the Internet as a whole. Second is the specification of methods for analysis of middlebox = interference, and associated active measurement techniques, that can = scale to much larger numbers of measured paths than those presently in = the literature, while minimizing network measurement traffic load on the = network. These active measurements will be useful for targeted questions = about specific paths as well as to fill in data not available from = passive measurement. Membership ---------- Membership in the HOPS RG is open. Meetings -------- The HOPS RG will meet one to three times per year, initially always = co-located with IETF meetings, to foster exchange among researchers and = between research and industry on middlebox measurement topics. Meetings = may in the future be scheduled to provide additional interaction with = the network operations community, should operationally relevant and = useful results warrant this. We aim to hold a first meeting at IETF 93 in Prague, and already have a = number of presentation confirmed. --Apple-Mail=_56577A06-EDD2-4C05-8E4F-E97246C0F8AC 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 iQEcBAEBCgAGBQJVUhSCAAoJENt3nsOmbNJcjW4H/0UrLFJ2Atn3S67WzxbT5yKd BIjm/uz7p8dK+BAVq90Cx585JQ9vWNBEub5Peyd4BSTEwgITH4QO/mB+nveAHCQh QCP7i3itDvAQ7sKwvO6479ISCsAPQfmfeM0LE3fkBT7VVrGGTb4NNeGpzgLDxw+v FRfIIBArKqXl+kTGrSkYf0PeLDaU/KgoxEhvkk15mZQ/GkAvKi8yOhPR5iW2nXxG 05yv7lFHq8TU9wIBxoww82wD7B71u+SHAsAIHIinZnGdpeDxr+cqn+TbITYAhCHQ SczOOw10UF0YLY4E5TxcsSdE96vlji48fhsiZwZLWDoxScvOkVB2IX8uy/GsANQ= =Jy5M -----END PGP SIGNATURE----- --Apple-Mail=_56577A06-EDD2-4C05-8E4F-E97246C0F8AC-- From nobody Tue May 12 10:09:47 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B628B1ACD54 for ; Tue, 12 May 2015 10:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_fPFC_LqVWa for ; Tue, 12 May 2015 10:09:43 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717221ACD4F for ; Tue, 12 May 2015 10:09:42 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so20772078igb.0 for ; Tue, 12 May 2015 10:09:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l2cnb3FFRY7+cOleD+Zjw3bISc3yvaDlPtoSZ102MrM=; b=YhF+VEx9gffysZPSYXsrQ8tVZ3yC4efUZzoSbiXX/HYsAu7rNNZbuPkpw6iyOuzrJd zfoW6SmPi1ArujWLl2IZF3DGPyHweB4KN/J+c9E0oRh2H3AIOAyaN4IqDbqn8VOaeoUY sNKfWjSIrmnDoA1JBLMaSBIl0wug+N99LPNtLyrt2RWgkEKeHOvyrutauAVR28Wdi/m7 Gah8HY2bWr5HWpLgOtefh248UM6CzPRjdzOOc/CS9Lv2L07BjnTxOth5rVUtHZJS64CN jL10lA2MSrgl3sBwtxsXVlgNKpy2AWyIu5Gn5f3tVzEYRrvX6IGZ+A6tQGS7w30YkSrZ OZuA== MIME-Version: 1.0 X-Received: by 10.42.100.15 with SMTP id y15mr4211410icn.16.1431450581096; Tue, 12 May 2015 10:09:41 -0700 (PDT) Received: by 10.64.69.162 with HTTP; Tue, 12 May 2015 10:09:40 -0700 (PDT) In-Reply-To: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch> References: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch> Date: Tue, 12 May 2015 13:09:40 -0400 Message-ID: From: Aaron Falk To: Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=90e6ba615052665e730515e58f02 Archived-At: Cc: hops@ietf.org Subject: Re: [hops] Proposed HOPS Research Group charter X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 17:09:45 -0000 --90e6ba615052665e730515e58f02 Content-Type: text/plain; charset=UTF-8 Hi Brian & Mirja- Glad to see this work is moving forward. An RG seems like the venue. I have a couple of comments on the charter: - I believe one of the more interesting and important elements of the work we discussed was that it was going to focus on measurements made from the edge. In particular, **active client** measurements are hard to come by. I'd like to see that called out as a focus. - Along the same lines, the engagement of folks from major browser & OS distros may open up opportunities that have not been generally available to the measurement community. Might want to include that as a goal for the group. I.e., focus on active measurements that are considered feasible for inclusion in well-known end-systems (specifically including mobile & fixed, residential & enterprise). - Add a cite to the HICCUPS paper alongside the Honda paper. Some other points from the notes that might be worth including: - There may be a substantial amount of data available from clients (such as Chrome or linux) which might be useful if accessible. Statements from the RG that certain data is useful may make it more likely to be shared. - There was an expression of interest by a major network operator in test tools capable of identifying and characterizing problematic middleboxes. - There was general agreement that aggregated statistics about the frequency of middlebox behavior could also be very useful. Best regards, --aaron On Tue, May 12, 2015 at 10:56 AM, Brian Trammell wrote: > Greetings, all, > > Following up on the successful BarBoF in Dallas, we would like to propose > a first HOPS (proposed) research group meeting in Prague. The draft charter > text is attached for comment. > > Cheers, > > Brian and Mirja > > > How Ossified is the Protocol Stack? (HOPS) > ========================================== > > 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. > > 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 [1] 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, > the HOPS research group will provide a discusion forum to coordinate > efforts in research and industry -- such as network stack, browser, and > middlebox vendors, as well as network and service operators -- on > collecting and reporting statistics about middlebox impact on transport > sessions. > > [1] 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. > > > Objective > --------- > > The HOPS research group follows from the successful BarBoF meeting > organized by Aaron Falk at IETF92 in Dallas to bring more data on the > nature and extent of middlebox interference to protocol design and > engineering efforts. To this end, we aim to provide a forum for discussion > and exchange of measurement insights, data, and techniques co-located with > IETF meetings. The BarBoF identified the need for this forum, with many > participants wanting a place to continue these discussions. > > In addition, we have identified two near-term goals to be completed within > the research group in support of this work. > > First is the definition of a common format for reporting on middlebox > impairments observed in the network, whether these observations are made > passively, actively, or as a side effect of some other operation, e.g. > taken from application or network stack error logs. This common format must > provide for correlation and comparison among data from disjoint > observations, and address end-user privacy and business confidentiality > concerns, e.g. using path pseudonyms instead of paths identified by AS > number and/or IP address where necessary. These measurements should be > useful not only for detecting impairments but also for assessing the > likelihood that a certain impairment will be experienced by traffic on > certain types of networks and in the Internet as a whole. > > Second is the specification of methods for analysis of middlebox > interference, and associated active measurement techniques, that can scale > to much larger numbers of measured paths than those presently in the > literature, while minimizing network measurement traffic load on the > network. These active measurements will be useful for targeted questions > about specific paths as well as to fill in data not available from passive > measurement. > > Membership > ---------- > > Membership in the HOPS RG is open. > > Meetings > -------- > > The HOPS RG will meet one to three times per year, initially always > co-located with IETF meetings, to foster exchange among researchers and > between research and industry on middlebox measurement topics. Meetings may > in the future be scheduled to provide additional interaction with the > network operations community, should operationally relevant and useful > results warrant this. > > We aim to hold a first meeting at IETF 93 in Prague, and already have a > number of presentation confirmed. > > > _______________________________________________ > hops mailing list > hops@ietf.org > https://www.ietf.org/mailman/listinfo/hops > > --90e6ba615052665e730515e58f02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian & Mirja-

Glad to see this = work is moving forward.=C2=A0 An RG seems like the venue.=C2=A0 I have a co= uple of comments on the charter:
  • =C2=A0I believe one of t= he more interesting and important elements of the work we discussed was tha= t it was going to focus on measurements made from the edge.=C2=A0 In partic= ular, **active client** measurements are hard to come by.=C2=A0 I'd lik= e to see that called out as a focus.

  • Along the same lines, = the engagement of folks from major browser & OS distros may open up opp= ortunities that have not been generally available to the measurement commun= ity.=C2=A0 Might want to include that as a goal for the group.=C2=A0 I.e., = focus on active measurements that are considered feasible for inclusion in = well-known end-systems (specifically including mobile & fixed, resident= ial & enterprise).

  • Add a cite to the HICCUPS paper alon= gside the Honda paper.

Some other po= ints from the notes that might be worth including:
  • There = may be a substantial amount of data available from clients (such as Chrome = or linux) which might be useful if accessible.=C2=A0 Statements from the RG= that certain data is useful may make it more likely to be shared.

    <= /li>
  • There was an expression of interest by a major network operator in = test tools capable of identifying and characterizing problematic middleboxe= s.=C2=A0

  • There was general agreement that aggregated statis= tics about the frequency of middlebox behavior could also be very useful. = =C2=A0

Best regards,

<= /div>
--aaron



On Tue, May 12, 2015 at 10:= 56 AM, Brian Trammell <ietf@trammell.ch> wrote:
Greetings, all,

Following up on the successful BarBoF in Dallas, we would like to propose a= first HOPS (proposed) research group meeting in Prague. The draft charter = text is attached for comment.

Cheers,

Brian and Mirja


How Ossified is the Protocol Stack? (HOPS)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

There has been long term and increasing interest in deploying transport pro= tocols with alternate dynamics and behaviors to TCP and UDP. The IETF has s= tandardized several new protocols including DCCP, UDP-lite, SCTP and severa= l changes to TCP including ECN and LEDBAT. All of these new technologies ha= ve resulted in deployment challenges blamed on intentional and unintentiona= l 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 approache= s have shortcomings and a variety of ameliorating engineering approaches ar= e being considered.

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 o= f the best analyses to date is [1] 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,= the HOPS research group will provide a discusion forum to coordinate effor= ts in research and industry -- such as network stack, browser, and middlebo= x vendors, as well as network and service operators -- on collecting and re= porting statistics about middlebox impact on transport sessions.

[1] M. Honda, Y. Nishida, C. Raiciu, A. Greenhalgh, M. Handley, and H. Toku= da.
Is it still possible to extend tcp? In Proc. ACM IMC, 2011.
<http://conferences.sigcomm.org/imc/2011/docs/p181.pdf><= br>
Objective
---------

The HOPS research group follows from the successful BarBoF meeting organize= d by Aaron Falk at IETF92 in Dallas to bring more data on the nature and ex= tent of middlebox interference to protocol design and engineering efforts. = To this end, we aim to provide a forum for discussion and exchange of measu= rement insights, data, and techniques co-located with IETF meetings. The Ba= rBoF identified the need for this forum, with many participants wanting a p= lace to continue these discussions.

In addition, we have identified two near-term goals to be completed within = the research group in support of this work.

First is the definition of a common format for reporting on middlebox impai= rments observed in the network, whether these observations are made passive= ly, actively, or as a side effect of some other operation, e.g. taken from = application or network stack error logs. This common format must provide fo= r correlation and comparison among data from disjoint observations, and add= ress end-user privacy and business confidentiality concerns, e.g. using pat= h pseudonyms instead of paths identified by AS number and/or IP address whe= re necessary. These measurements should be useful not only for detecting im= pairments but also for assessing the likelihood that a certain impairment w= ill be experienced by traffic on certain types of networks and in the Inter= net as a whole.

Second is the specification of methods for analysis of middlebox interferen= ce, and associated active measurement techniques, that can scale to much la= rger numbers of measured paths than those presently in the literature, whil= e minimizing network measurement traffic load on the network. These active = measurements will be useful for targeted questions about specific paths as = well as to fill in data not available from passive measurement.

Membership
----------

Membership in the HOPS RG is open.

Meetings
--------

The HOPS RG will meet one to three times per year, initially always co-loca= ted with IETF meetings, to foster exchange among researchers and between re= search and industry on middlebox measurement topics. Meetings may in the fu= ture be scheduled to provide additional interaction with the network operat= ions community, should operationally relevant and useful results warrant th= is.

We aim to hold a first meeting at IETF 93 in Prague, and already have a num= ber of presentation confirmed.


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


--90e6ba615052665e730515e58f02-- From nobody Wed May 13 02:28:21 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0ED1ACE08 for ; Wed, 13 May 2015 02:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf4kZC2j3Szz for ; Wed, 13 May 2015 02:28:15 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C231ACDFE for ; Wed, 13 May 2015 02:28:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id C9E6BD9309; Wed, 13 May 2015 11:28:13 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IdNA+OAQN7h2; Wed, 13 May 2015 11:28:13 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 64651D9305; Wed, 13 May 2015 11:28:13 +0200 (MEST) Message-ID: <5553192D.6050705@tik.ee.ethz.ch> Date: Wed, 13 May 2015 11:28:13 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Aaron Falk , hops@ietf.org References: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Brian Trammell Subject: Re: [hops] Proposed HOPS Research Group charter X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 09:28:19 -0000 Hi Aaron, thanks for your feedback. I think I have addressed all your comments. Find a new version below! Mirja ------------------------------------------ How Ossified is the Protocol Stack? (HOPS) ========================================== 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. 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 [1] which measures from a very small number of locations: 49 residential, 17 enterprise, and 142 locations in total. There are two more recent studies: [2] is focusing on TCP in-band testing while using PlanetLab as a measurement testbed; [2] use crowd-sourcing with in total 1,165 workers from 53 different countries covering a larger set of access networks including mobile access for TLS testing [3]. However, to be able to draw conclusions about the significance of a certain middlebox interference problem more data form a large variety of access networks is needed. In the interest of getting ground-truth data about the nature of the problem, the HOPS research group will provide a discussion forum to coordinate efforts in research and industry -- such as network stack, browser, and middlebox vendors, as well as network and service operators -- on collecting and reporting statistics about middlebox impact on transport sessions. [1] 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. [2] R. Craven, R. Beverly, and M. Allman. A middlebox-cooperative TCP for a non end-to-end Internet. In Proc. ACM SIGCOMM, 2014. [3] A. M. Mandalari, M. Bagnulo, A. Lutu. Informing Protocol Design Through Crowdsourcing: the Case of Pervasive Encryption. ACM SIGCOMM Workshop on Crowdsourcing and crowdsharing of Big (Internet) Data (C2B(I)D), 2015. Objective --------- The HOPS research group follows from the successful BarBoF meeting organized by Aaron Falk at IETF92 in Dallas to bring more data on the nature and extent of middlebox interference to protocol design and engineering efforts. To this end, we aim to provide a forum for discussion and exchange of measurement insights, data, and techniques co-located with IETF meetings. The BarBoF identified the need for this forum, with many participants wanting a place to continue these discussions. In addition, we have identified two near-term goals to be completed within the research group in support of this work. First is the definition of a common format for reporting on middlebox impairments observed in the network, whether these observations are made passively, actively, or as a side effect of some other operation, e.g. taken from application or network stack error logs. This common format must provide for correlation and comparison among data from disjoint observations, and address end-user privacy and business confidentiality concerns, e.g. using path pseudonyms instead of paths identified by AS number and/or IP address where necessary. These measurements should be useful not only for detecting impairments but also for assessing the likelihood that a certain impairment will be experienced by traffic on certain types of networks and in the Internet as a whole. For this purpose aggregated statistics on the prevalence of certain middblebox behaviors are useful, even without revealing the underlying measurement data. Second is the specification of methods for analysis of middlebox interference, and associated active measurement techniques, that can scale to much larger numbers of measured paths than those presently in the literature, while minimizing network measurement traffic load on the network. Similar techniques could be used for middlebox benchmarking. Focusing on active measurements that are considered feasible for inclusion in well-known end-systems (e.g. in browsers or the OS) has been identified as way forward to collect more data and reach a high coverage of different access networks, specifically including mobile and fixed, residential, as well as enterprise network. These active measurements will be useful for targeted questions about specific paths as well as to fill in data not available from passive measurement. Further, providing guidelines on with measurement and analysis techniques are needed to detect and classify certain impairments may increase the willingness of industry to share data that is already available. Membership ---------- Membership in the HOPS RG is open. Meetings -------- The HOPS RG will meet one to three times per year, initially always co-located with IETF meetings, to foster exchange among researchers and between research and industry on middlebox measurement topics. Meetings may in the future be scheduled to provide additional interaction with the network operations community, should operationally relevant and useful results warrant this. We aim to hold a first meeting at IETF 93 in Prague, and already have a number of presentation confirmed. On 12.05.2015 19:09, Aaron Falk wrote: > Hi Brian & Mirja- > > Glad to see this work is moving forward. An RG seems like the venue. I have a > couple of comments on the charter: > > * I believe one of the more interesting and important elements of the work > we discussed was that it was going to focus on measurements made from the > edge. In particular, **active client** measurements are hard to come by. > I'd like to see that called out as a focus. > > * Along the same lines, the engagement of folks from major browser & OS > distros may open up opportunities that have not been generally available to > the measurement community. Might want to include that as a goal for the > group. I.e., focus on active measurements that are considered feasible for > inclusion in well-known end-systems (specifically including mobile & fixed, > residential & enterprise). > > * Add a cite to the HICCUPS paper alongside the Honda paper. > > > Some other points from the notes that might be worth including: > > * There may be a substantial amount of data available from clients (such as > Chrome or linux) which might be useful if accessible. Statements from the > RG that certain data is useful may make it more likely to be shared. > > * There was an expression of interest by a major network operator in test > tools capable of identifying and characterizing problematic middleboxes. > > * There was general agreement that aggregated statistics about the frequency > of middlebox behavior could also be very useful. > > > Best regards, > > --aaron > > > > On Tue, May 12, 2015 at 10:56 AM, Brian Trammell > wrote: > > Greetings, all, > > Following up on the successful BarBoF in Dallas, we would like to propose a > first HOPS (proposed) research group meeting in Prague. The draft charter > text is attached for comment. > > Cheers, > > Brian and Mirja > > > How Ossified is the Protocol Stack? (HOPS) > ========================================== > > 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. > > 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 [1] 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, the > HOPS research group will provide a discusion forum to coordinate efforts in > research and industry -- such as network stack, browser, and middlebox > vendors, as well as network and service operators -- on collecting and > reporting statistics about middlebox impact on transport sessions. > > [1] 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. > > > Objective > --------- > > The HOPS research group follows from the successful BarBoF meeting organized > by Aaron Falk at IETF92 in Dallas to bring more data on the nature and > extent of middlebox interference to protocol design and engineering efforts. > To this end, we aim to provide a forum for discussion and exchange of > measurement insights, data, and techniques co-located with IETF meetings. > The BarBoF identified the need for this forum, with many participants > wanting a place to continue these discussions. > > In addition, we have identified two near-term goals to be completed within > the research group in support of this work. > > First is the definition of a common format for reporting on middlebox > impairments observed in the network, whether these observations are made > passively, actively, or as a side effect of some other operation, e.g. taken > from application or network stack error logs. This common format must > provide for correlation and comparison among data from disjoint > observations, and address end-user privacy and business confidentiality > concerns, e.g. using path pseudonyms instead of paths identified by AS > number and/or IP address where necessary. These measurements should be > useful not only for detecting impairments but also for assessing the > likelihood that a certain impairment will be experienced by traffic on > certain types of networks and in the Internet as a whole. > > Second is the specification of methods for analysis of middlebox > interference, and associated active measurement techniques, that can scale > to much larger numbers of measured paths than those presently in the > literature, while minimizing network measurement traffic load on the > network. These active measurements will be useful for targeted questions > about specific paths as well as to fill in data not available from passive > measurement. > > Membership > ---------- > > Membership in the HOPS RG is open. > > Meetings > -------- > > The HOPS RG will meet one to three times per year, initially always > co-located with IETF meetings, to foster exchange among researchers and > between research and industry on middlebox measurement topics. Meetings may > in the future be scheduled to provide additional interaction with the > network operations community, should operationally relevant and useful > results warrant this. > > We aim to hold a first meeting at IETF 93 in Prague, and already have a > number of presentation confirmed. > > > _______________________________________________ > hops mailing list > hops@ietf.org > https://www.ietf.org/mailman/listinfo/hops > > -- ------------------------------------------ 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 May 20 02:03:13 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9411A1BEF for ; Wed, 20 May 2015 02:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.21 X-Spam-Level: X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhyq1cbDrTOU for ; Wed, 20 May 2015 02:03:07 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916A21B2EEF for ; Wed, 20 May 2015 02:03:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 9F133D9304 for ; Wed, 20 May 2015 11:03:05 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GuDXYhWVCI5C for ; Wed, 20 May 2015 11:03:05 +0200 (MEST) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2E829D9303 for ; Wed, 20 May 2015 11:03:05 +0200 (MEST) Message-ID: <555C4DC8.8060008@tik.ee.ethz.ch> Date: Wed, 20 May 2015 11:03:04 +0200 From: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: hops@ietf.org References: <7DDA5783-A6C7-4524-9F76-CFE948461811@trammell.ch> <5553192D.6050705@tik.ee.ethz.ch> In-Reply-To: <5553192D.6050705@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hops] Proposed HOPS Research Group charter X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 09:03:12 -0000 Hi all, I think the charter is ready to be sent out. In parallel we also already contacted people to present something at a potential first RG meeting. The plan is to propose the charter together with a tentative agenda for a first meeting in Prague. Here is what we have so far for the agenda: 1) Welcome and Intro 2) Passive Measurement Data - "Results from deployment of QUIC, a UDP-based transport" Jana Iyengar (Google) - Dave Plonka (Akamai) (not fully confirmed yet) 3) Active Measurements - Robert Kisteleki (RIPE) (title tbd) - "Lessons learnt from middlebox measurement” Michio Honda (NetApp) 4) Measurement Methodology - "Tracking Middleboxes with Tracebox" Korian Edeline (Université de Liège) Let me know if you have any further comments. Otherwise I'll send out the proposal to Lars by the end of the week! Mirja On 13.05.2015 11:28, Mirja Kühlewind wrote: > Hi Aaron, > > thanks for your feedback. I think I have addressed all your comments. Find a new > version below! > > Mirja > > > ------------------------------------------ > > How Ossified is the Protocol Stack? (HOPS) > ========================================== > > 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. > > 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 [1] which measures from a very small number of > locations: 49 residential, 17 enterprise, and 142 locations in total. There are > two more recent studies: [2] is focusing on TCP in-band testing while using > PlanetLab as a measurement testbed; [2] use crowd-sourcing with in total 1,165 > workers from 53 different countries covering a larger set of access networks > including mobile access for TLS testing [3]. However, to be able to draw > conclusions about the significance of a certain middlebox interference problem > more data form a large variety of access networks is needed. In the interest of > getting ground-truth data about the nature of the problem, the HOPS research > group will provide a discussion forum to coordinate efforts in research and > industry -- such as network stack, browser, and middlebox vendors, as well as > network and service operators -- on collecting and reporting statistics about > middlebox impact on transport sessions. > > [1] 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. > > > [2] R. Craven, R. Beverly, and M. Allman. > A middlebox-cooperative TCP for a non end-to-end Internet. In Proc. ACM SIGCOMM, > 2014. > > > [3] A. M. Mandalari, M. Bagnulo, A. Lutu. > Informing Protocol Design Through Crowdsourcing: the Case of Pervasive Encryption. > ACM SIGCOMM Workshop on Crowdsourcing and crowdsharing of Big (Internet) Data > (C2B(I)D), 2015. > > > Objective > --------- > > The HOPS research group follows from the successful BarBoF meeting organized by > Aaron Falk at IETF92 in Dallas to bring more data on the nature and extent of > middlebox interference to protocol design and engineering efforts. To this end, > we aim to provide a forum for discussion and exchange of measurement insights, > data, and techniques co-located with IETF meetings. The BarBoF identified the > need for this forum, with many participants wanting a place to continue these > discussions. > > In addition, we have identified two near-term goals to be completed within the > research group in support of this work. > > First is the definition of a common format for reporting on middlebox > impairments observed in the network, whether these observations are made > passively, actively, or as a side effect of some other operation, e.g. taken > from application or network stack error logs. This common format must provide > for correlation and comparison among data from disjoint observations, and > address end-user privacy and business confidentiality concerns, e.g. using path > pseudonyms instead of paths identified by AS number and/or IP address where > necessary. These measurements should be useful not only for detecting > impairments but also for assessing the likelihood that a certain impairment will > be experienced by traffic on certain types of networks and in the Internet as a > whole. For this purpose aggregated statistics on the prevalence of certain > middblebox behaviors are useful, even without revealing the underlying > measurement data. > > Second is the specification of methods for analysis of middlebox interference, > and associated active measurement techniques, that can scale to much larger > numbers of measured paths than those presently in the literature, while > minimizing network measurement traffic load on the network. Similar techniques > could be used for middlebox benchmarking. Focusing on active measurements that > are considered feasible for inclusion in well-known end-systems (e.g. in > browsers or the OS) has been identified as way forward to collect more data and > reach a high coverage of different access networks, specifically including > mobile and fixed, residential, as well as enterprise network. These active > measurements will be useful for targeted questions about specific paths as well > as to fill in data not available from passive measurement. Further, providing > guidelines on with measurement and analysis techniques are needed to detect and > classify certain impairments may increase the willingness of industry to share > data that is already available. > > Membership > ---------- > > Membership in the HOPS RG is open. > > Meetings > -------- > > The HOPS RG will meet one to three times per year, initially always co-located > with IETF meetings, to foster exchange among researchers and between research > and industry on middlebox measurement topics. Meetings may in the future be > scheduled to provide additional interaction with the network operations > community, should operationally relevant and useful results warrant this. > > We aim to hold a first meeting at IETF 93 in Prague, and already have a number > of presentation confirmed. > > > > On 12.05.2015 19:09, Aaron Falk wrote: >> Hi Brian & Mirja- >> >> Glad to see this work is moving forward. An RG seems like the venue. I have a >> couple of comments on the charter: >> >> * I believe one of the more interesting and important elements of the work >> we discussed was that it was going to focus on measurements made from the >> edge. In particular, **active client** measurements are hard to come by. >> I'd like to see that called out as a focus. >> >> * Along the same lines, the engagement of folks from major browser & OS >> distros may open up opportunities that have not been generally available to >> the measurement community. Might want to include that as a goal for the >> group. I.e., focus on active measurements that are considered feasible for >> inclusion in well-known end-systems (specifically including mobile & fixed, >> residential & enterprise). >> >> * Add a cite to the HICCUPS paper alongside the Honda paper. >> >> >> Some other points from the notes that might be worth including: >> >> * There may be a substantial amount of data available from clients (such as >> Chrome or linux) which might be useful if accessible. Statements from the >> RG that certain data is useful may make it more likely to be shared. >> >> * There was an expression of interest by a major network operator in test >> tools capable of identifying and characterizing problematic middleboxes. >> >> * There was general agreement that aggregated statistics about the frequency >> of middlebox behavior could also be very useful. >> >> >> Best regards, >> >> --aaron >> >> >> >> On Tue, May 12, 2015 at 10:56 AM, Brian Trammell > > wrote: >> >> Greetings, all, >> >> Following up on the successful BarBoF in Dallas, we would like to propose a >> first HOPS (proposed) research group meeting in Prague. The draft charter >> text is attached for comment. >> >> Cheers, >> >> Brian and Mirja >> >> >> How Ossified is the Protocol Stack? (HOPS) >> ========================================== >> >> 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. >> >> 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 [1] 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, the >> HOPS research group will provide a discusion forum to coordinate efforts in >> research and industry -- such as network stack, browser, and middlebox >> vendors, as well as network and service operators -- on collecting and >> reporting statistics about middlebox impact on transport sessions. >> >> [1] 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. >> >> >> Objective >> --------- >> >> The HOPS research group follows from the successful BarBoF meeting organized >> by Aaron Falk at IETF92 in Dallas to bring more data on the nature and >> extent of middlebox interference to protocol design and engineering efforts. >> To this end, we aim to provide a forum for discussion and exchange of >> measurement insights, data, and techniques co-located with IETF meetings. >> The BarBoF identified the need for this forum, with many participants >> wanting a place to continue these discussions. >> >> In addition, we have identified two near-term goals to be completed within >> the research group in support of this work. >> >> First is the definition of a common format for reporting on middlebox >> impairments observed in the network, whether these observations are made >> passively, actively, or as a side effect of some other operation, e.g. taken >> from application or network stack error logs. This common format must >> provide for correlation and comparison among data from disjoint >> observations, and address end-user privacy and business confidentiality >> concerns, e.g. using path pseudonyms instead of paths identified by AS >> number and/or IP address where necessary. These measurements should be >> useful not only for detecting impairments but also for assessing the >> likelihood that a certain impairment will be experienced by traffic on >> certain types of networks and in the Internet as a whole. >> >> Second is the specification of methods for analysis of middlebox >> interference, and associated active measurement techniques, that can scale >> to much larger numbers of measured paths than those presently in the >> literature, while minimizing network measurement traffic load on the >> network. These active measurements will be useful for targeted questions >> about specific paths as well as to fill in data not available from passive >> measurement. >> >> Membership >> ---------- >> >> Membership in the HOPS RG is open. >> >> Meetings >> -------- >> >> The HOPS RG will meet one to three times per year, initially always >> co-located with IETF meetings, to foster exchange among researchers and >> between research and industry on middlebox measurement topics. Meetings may >> in the future be scheduled to provide additional interaction with the >> network operations community, should operationally relevant and useful >> results warrant this. >> >> We aim to hold a first meeting at IETF 93 in Prague, and already have a >> number of presentation confirmed. >> >> >> _______________________________________________ >> hops mailing list >> hops@ietf.org >> https://www.ietf.org/mailman/listinfo/hops >> >> > -- ------------------------------------------ Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlewind@tik.ee.ethz.ch ------------------------------------------ From nobody Fri May 22 04:14:32 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F341B2B95 for ; Fri, 22 May 2015 04:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsNOduVXYGzm for ; Fri, 22 May 2015 04:14:26 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE711B2B8A for ; Fri, 22 May 2015 04:14:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 873E7D9303; Fri, 22 May 2015 13:14:24 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id v49wBj9+rPJL; Fri, 22 May 2015 13:14:24 +0200 (MEST) Received: from [192.168.178.33] (x5f7009d4.dyn.telefonica.de [95.112.9.212]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1685BD9302; Fri, 22 May 2015 13:14:24 +0200 (MEST) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 22 May 2015 13:14:25 +0200 Message-Id: To: "Eggert, Lars (lars@netapp.com)" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Cc: hops@ietf.org, Brian Trammell Subject: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 11:14:30 -0000 Hi Lars, as you might have seen in the mean time, we would like to propose a new = HOPS research group. Based on the fruitful discuss we had at the BarBoF = in Dallas and further discussions with individuals we think that this = topic is appropriate for a research group and send a proposed charter = text with this mail (see below). Our goal would be to provide a forum to = exchange and discuss measurement results and methodology on middlebox = impairments. Further we=E2=80=99d also like work on a common data format = that can be used to specify impairment tests to achieve comparable = results from different existing and new data sets independent of the = technique that was used to collect this data. We think that a research = group is also the appropriate form for this activity. See further = details below. In parallel we=E2=80=99ve been also talking to people how indicated = interest at the BarBoF as well as further people from the research = community to figure out if there is interest in giving a presentation at = a potential rg meeting. We have received large interest and are positive = that people will be able to actually present data at such a meeting. See = a tentative agenda for a potentially first meeting in Prague below. Let us know what you think or if you have any further questions! Brian and Mirja ------------------------------------------ How Ossified is the Protocol Stack? (HOPS) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. 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 [1] which measures from a = very small number of locations: 49 residential, 17 enterprise, and 142 = locations in total. There are two more recent studies: [2] is focusing = on TCP in-band testing while using PlanetLab as a measurement testbed; = [2] use crowd-sourcing with in total 1,165 workers from 53 different = countries covering a larger set of access networks including mobile = access for TLS testing [3]. However, to be able to draw conclusions = about the significance of a certain middlebox interference problem more = data form a large variety of access networks is needed. In the interest = of getting ground-truth data about the nature of the problem, the HOPS = research group will provide a discussion forum to coordinate efforts in = research and industry -- such as network stack, browser, and middlebox = vendors, as well as network and service operators -- on collecting and = reporting statistics about middlebox impact on transport sessions. [1] 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. [2] R. Craven, R. Beverly, and M. Allman. A middlebox-cooperative TCP for a non end-to-end Internet. In Proc. ACM = SIGCOMM, 2014. [3] A. M. Mandalari, M. Bagnulo, A. Lutu. Informing Protocol Design Through Crowdsourcing: the Case of Pervasive = Encryption. ACM SIGCOMM Workshop on Crowdsourcing and crowdsharing of Big (Internet) = Data (C2B(I)D), 2015. Objective --------- The HOPS research group follows from the successful BarBoF meeting = organized by Aaron Falk at IETF92 in Dallas to bring more data on the = nature and extent of middlebox interference to protocol design and = engineering efforts. To this end, we aim to provide a forum for = discussion and exchange of measurement insights, data, and techniques = co-located with IETF meetings. The BarBoF identified the need for this = forum, with many participants wanting a place to continue these = discussions. In addition, we have identified two near-term goals to be completed = within the research group in support of this work. First is the definition of a common format for reporting on middlebox = impairments observed in the network, whether these observations are made = passively, actively, or as a side effect of some other operation, e.g. = taken from application or network stack error logs. This common format = must provide for correlation and comparison among data from disjoint = observations, and address end-user privacy and business confidentiality = concerns, e.g. using path pseudonyms instead of paths identified by AS = number and/or IP address where necessary. These measurements should be = useful not only for detecting impairments but also for assessing the = likelihood that a certain impairment will be experienced by traffic on = certain types of networks and in the Internet as a whole. For this = purpose aggregated statistics on the prevalence of certain middblebox = behaviors are useful, even without revealing the underlying measurement = data. Second is the specification of methods for analysis of middlebox = interference, and associated active measurement techniques, that can = scale to much larger numbers of measured paths than those presently in = the literature, while minimizing network measurement traffic load on the = network. Similar techniques could be used for middlebox benchmarking. = Focusing on active measurements that are considered feasible for = inclusion in well-known end-systems (e.g. in browsers or the OS) has = been identified as way forward to collect more data and reach a high = coverage of different access networks, specifically including mobile and = fixed, residential, as well as enterprise network. These active = measurements will be useful for targeted questions about specific paths = as well as to fill in data not available from passive measurement. = Further, providing guidelines on with measurement and analysis = techniques are needed to detect and classify certain impairments may = increase the willingness of industry to share data that is already = available. Membership ---------- Membership in the HOPS RG is open. Meetings -------- The HOPS RG will meet one to three times per year, initially always = co-located with IETF meetings, to foster exchange among researchers and = between research and industry on middlebox measurement topics. Meetings = may in the future be scheduled to provide additional interaction with = the network operations community, should operationally relevant and = useful results warrant this. We aim to hold a first meeting at IETF 93 in Prague, and already have a = number of presentation confirmed leading to the following tentative = agenda: 1) Welcome and Intro 2) Passive Measurement Data - "Results from deployment of QUIC, a UDP-based transport" Jana = Iyengar (Google) - Dave Plonka (Akamai) (not fully confirmed yet) 3) Active Measurements - Robert Kisteleki (RIPE) (title tbd) - "Lessons learnt from middlebox measurement=E2=80=9D Michio Honda = (NetApp) 4) Measurement Methodology - "Tracking Middleboxes with Tracebox" Korian Edeline (Universit=C3=A9 = de Li=C3=A8ge) From nobody Fri May 22 06:21:43 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059C01B2BCE for ; Fri, 22 May 2015 06:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.712 X-Spam-Level: X-Spam-Status: No, score=-4.712 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, 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 pdFGce6mosC8 for ; Fri, 22 May 2015 06:21:40 -0700 (PDT) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7481B2BD8 for ; Fri, 22 May 2015 06:21:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,475,1427785200"; d="asc'?scan'208";a="45193868" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 22 May 2015 06:21:19 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 22 May 2015 06:21:19 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com ([10.122.105.34]) by hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) with mapi id 15.00.1076.000; Fri, 22 May 2015 06:21:19 -0700 From: "Eggert, Lars" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: Proposal for HOPS RG Thread-Index: AQHQlIB3N4briqkfT0238Ir58nYNJZ2IcLaA Date: Fri, 22 May 2015 13:21:18 +0000 Message-ID: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2100) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_C5B7B3B2-DF9F-47E6-9F60-A41CE3E2147B"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "hops@ietf.org" , Brian Trammell Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 13:21:42 -0000 --Apple-Mail=_C5B7B3B2-DF9F-47E6-9F60-A41CE3E2147B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2015-5-22, at 13:14, Mirja K=C3=BChlewind = wrote: > Our goal would be to provide a forum to exchange and discuss = measurement results and methodology on middlebox impairments. Further = we=E2=80=99d also like work on a common data format that can be used to = specify impairment tests to achieve comparable results from different = existing and new data sets independent of the technique that was used to = collect this data. that seems like a reasonable goal. Which projects are doing these measurements at the moment and into the = future, and do you have buy-in from them? A lot of work in this space is = one-off measurement activities that end as soon as a paper was = published. Lars --Apple-Mail=_C5B7B3B2-DF9F-47E6-9F60-A41CE3E2147B 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----- iEYEARECAAYFAlVfLU4ACgkQIWcjmsUTWRp6kgCfWU0AmMzZok0x0kAINNeAEBGj XJgAoOe63I80BgvHK3Ip1OU2u26eh2fl =LJ+h -----END PGP SIGNATURE----- --Apple-Mail=_C5B7B3B2-DF9F-47E6-9F60-A41CE3E2147B-- From nobody Fri May 22 06:46:57 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C851A002A for ; Fri, 22 May 2015 06:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjNRQ9a4yxJ7 for ; Fri, 22 May 2015 06:46:53 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875EC1A1A54 for ; Fri, 22 May 2015 06:46:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 198E5D9303; Fri, 22 May 2015 15:46:52 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t4kxhHMTyWAb; Fri, 22 May 2015 15:46:51 +0200 (MEST) Received: from [192.168.178.33] (x4d02e3b3.dyn.telefonica.de [77.2.227.179]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A3A45D9302; Fri, 22 May 2015 15:46:51 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> Date: Fri, 22 May 2015 15:46:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "hops@ietf.org" , Brian Trammell Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 13:46:56 -0000 Hi Lars, there are people from RIPE who are interested in this work and were = already at the BarBoF. Further we are also in contact which the people = from CAIDA. And, as you can see on the agenda, we are also talking to = Google and Akamai with people who were also at the BarBoF and it = actually seems to be possible that theyl will release some data. In fact = we also don=E2=80=99t necessarily need the data itself. If we come up = with a common format where we can specific tests, it is probably = sufficient to release the final evaluated results.=20 Regarding one-off measurement, these are definitely also useful if = comparable to other results. Further if the raw data can be made = available, it might be possible to apply further tests to the collected = data at a later time. I personally don=E2=80=99t know if this activity and interest, we see = right now, will stay for long. However, even if this might not lead to a = long-time research group, I think it is worth it to use the momentum and = collect (and analyze) the data we can get right now. Mirja > Am 22.05.2015 um 15:21 schrieb Eggert, Lars : >=20 > Hi, >=20 > On 2015-5-22, at 13:14, Mirja K=C3=BChlewind = wrote: >> Our goal would be to provide a forum to exchange and discuss = measurement results and methodology on middlebox impairments. Further = we=E2=80=99d also like work on a common data format that can be used to = specify impairment tests to achieve comparable results from different = existing and new data sets independent of the technique that was used to = collect this data. >=20 > that seems like a reasonable goal. >=20 > Which projects are doing these measurements at the moment and into the = future, and do you have buy-in from them? A lot of work in this space is = one-off measurement activities that end as soon as a paper was = published. >=20 > Lars > _______________________________________________ > hops mailing list > hops@ietf.org > https://www.ietf.org/mailman/listinfo/hops From nobody Fri May 22 07:11:21 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF081B2BEE for ; Fri, 22 May 2015 07:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, 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 SsOCOh3casaJ for ; Fri, 22 May 2015 07:11:16 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DB81AD36F for ; Fri, 22 May 2015 07:11:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,475,1427785200"; d="asc'?scan'208";a="44497875" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx144-out.netapp.com with ESMTP; 22 May 2015 07:06:15 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 22 May 2015 07:06:15 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com ([10.122.105.34]) by hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) with mapi id 15.00.1076.000; Fri, 22 May 2015 07:06:15 -0700 From: "Eggert, Lars" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [hops] Proposal for HOPS RG Thread-Index: AQHQlIB3N4briqkfT0238Ir58nYNJZ2IcLaAgAAHJICAAAVrAA== Date: Fri, 22 May 2015 14:06:14 +0000 Message-ID: <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> In-Reply-To: <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2100) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_1366DEAA-FE1D-4A25-B13E-5E4FE343731C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "hops@ietf.org" , Brian Trammell Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:11:19 -0000 --Apple-Mail=_1366DEAA-FE1D-4A25-B13E-5E4FE343731C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2015-5-22, at 15:46, Mirja K=C3=BChlewind = wrote: > there are people from RIPE who are interested in this work and were = already at the BarBoF. Further we are also in contact which the people = from CAIDA. And, as you can see on the agenda, we are also talking to = Google and Akamai with people who were also at the BarBoF so that's promising, but not actually a large number of folks. I wonder = if a discussion among four groups really needs an RG established. Isn't = this something that might as well be handled ad hoc? A second concern I have is that the topic here is fairly narrow in scope = ("let's discuss data around how bad middleboxes break things"), and = rather short-lived (i.e., once that is done, the group is done). The = IRTF tries to charter groups that are long-lived and try to tackle = problem areas of substantial size, and I wonder if this is the case = here. (Since I was not at the bar BOF, I may be fundamentally misunderstanding = something about this proposal. I'm only going on what is in the charter = text proposal.) Lars --Apple-Mail=_1366DEAA-FE1D-4A25-B13E-5E4FE343731C 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----- iEYEARECAAYFAlVfN9YACgkQIWcjmsUTWRqutQCgpnPVegNqXY0ES3rsQpbnb7HA EUcAoP2OLVoSeUSZoHgsORhUUEUi9UWy =qkNT -----END PGP SIGNATURE----- --Apple-Mail=_1366DEAA-FE1D-4A25-B13E-5E4FE343731C-- From nobody Fri May 22 07:24:04 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3751A00B1 for ; Fri, 22 May 2015 07:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.611 X-Spam-Level: X-Spam-Status: No, score=-6.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, 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 tDd6BMzFp7qk for ; Fri, 22 May 2015 07:24:02 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04E51A010F for ; Fri, 22 May 2015 07:24:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,475,1427785200"; d="asc'?scan'208";a="42929587" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 22 May 2015 07:19:01 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 22 May 2015 07:19:01 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com ([10.122.105.34]) by hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) with mapi id 15.00.1076.000; Fri, 22 May 2015 07:19:01 -0700 From: "Eggert, Lars" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [hops] Proposal for HOPS RG Thread-Index: AQHQlIB3N4briqkfT0238Ir58nYNJZ2IcLaAgAAHJICAAAVrAIAAA5CA Date: Fri, 22 May 2015 14:19:00 +0000 Message-ID: <7213000C-789D-432C-A954-9EA82AC7EA0C@netapp.com> References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> In-Reply-To: <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2100) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_B40080CF-FEC7-4A9A-8722-0D015AB16457"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "hops@ietf.org" , Brian Trammell Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:24:03 -0000 --Apple-Mail=_B40080CF-FEC7-4A9A-8722-0D015AB16457 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi again, I should probably clarify that I'm *not* pushing back on you guys having = a meeting in Prague and possibly later IETFs to see if a community = forms. I will definitely approve rooms. Take my comments as early feedback on the charter text you sent. The = actual chartering discussion will happen after you've tried to meet a = few times and we see what has happened in those meetings. Lars On 2015-5-22, at 16:06, Eggert, Lars wrote: > On 2015-5-22, at 15:46, Mirja K=C3=BChlewind = wrote: >> there are people from RIPE who are interested in this work and were = already at the BarBoF. Further we are also in contact which the people = from CAIDA. And, as you can see on the agenda, we are also talking to = Google and Akamai with people who were also at the BarBoF >=20 > so that's promising, but not actually a large number of folks. I = wonder if a discussion among four groups really needs an RG established. = Isn't this something that might as well be handled ad hoc? >=20 > A second concern I have is that the topic here is fairly narrow in = scope ("let's discuss data around how bad middleboxes break things"), = and rather short-lived (i.e., once that is done, the group is done). The = IRTF tries to charter groups that are long-lived and try to tackle = problem areas of substantial size, and I wonder if this is the case = here. >=20 > (Since I was not at the bar BOF, I may be fundamentally = misunderstanding something about this proposal. I'm only going on what = is in the charter text proposal.) >=20 > Lars > _______________________________________________ > hops mailing list > hops@ietf.org > https://www.ietf.org/mailman/listinfo/hops --Apple-Mail=_B40080CF-FEC7-4A9A-8722-0D015AB16457 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----- iEYEARECAAYFAlVfOtMACgkQIWcjmsUTWRrrYACgvkBGSLTUcpTpG628houMBFsB jSkAoMoPFr7erntcA3zo6Wmgl0UqoQU4 =d9qM -----END PGP SIGNATURE----- --Apple-Mail=_B40080CF-FEC7-4A9A-8722-0D015AB16457-- From nobody Fri May 22 07:25:26 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2211ACCC7 for ; Fri, 22 May 2015 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1D-W0h7BDQL for ; Fri, 22 May 2015 07:25:13 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1EF1A0364 for ; Fri, 22 May 2015 07:25:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 74B85D9303; Fri, 22 May 2015 16:25:09 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7P6JImq8EtzJ; Fri, 22 May 2015 16:25:09 +0200 (MEST) Received: from [192.168.178.33] (x4d02e54e.dyn.telefonica.de [77.2.229.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 1830BD9302; Fri, 22 May 2015 16:25:09 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> Date: Fri, 22 May 2015 16:25:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5B8D7E98-8C70-4949-8138-7FDF36628544@tik.ee.ethz.ch> References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "hops@ietf.org" , Brian Trammell Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:25:19 -0000 Hi Lars, if things run well, I don=E2=80=99t consider this as a short-term group. = The goal of collecting and providing this measurement data is two-fold: = 1) this data should provide input for future protocol specification. As = I don=E2=80=99t believe that all middleboxes will suddenly disappear or = at least not do any =E2=80=9Astupid=E2=80=98 things anymore, I see this = as a long-termn project because data needs to be updated continuously. = Further as we are just at the beginning, it=E2=80=99s not only about = collecting the data but in many cases also about developing the = appropriate measurement methodology/technique to actually detect the = impairments. And 2) it not only about detecting which impairments exist = and how likely it is that traffic we experience these impairment. I also = see as a goal to detect broken middleboxes and start activities to get = them removed. I guess that=E2=80=99s really not a short-term goal. Maybe = we can spell out this part more explicitly in the charter as well. Mirja =20 > Am 22.05.2015 um 16:06 schrieb Eggert, Lars : >=20 > Hi, >=20 > On 2015-5-22, at 15:46, Mirja K=C3=BChlewind = wrote: >> there are people from RIPE who are interested in this work and were = already at the BarBoF. Further we are also in contact which the people = from CAIDA. And, as you can see on the agenda, we are also talking to = Google and Akamai with people who were also at the BarBoF >=20 > so that's promising, but not actually a large number of folks. I = wonder if a discussion among four groups really needs an RG established. = Isn't this something that might as well be handled ad hoc? >=20 > A second concern I have is that the topic here is fairly narrow in = scope ("let's discuss data around how bad middleboxes break things"), = and rather short-lived (i.e., once that is done, the group is done). The = IRTF tries to charter groups that are long-lived and try to tackle = problem areas of substantial size, and I wonder if this is the case = here. >=20 > (Since I was not at the bar BOF, I may be fundamentally = misunderstanding something about this proposal. I'm only going on what = is in the charter text proposal.) >=20 > Lars From nobody Fri May 22 07:27:11 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8501ACE4A for ; Fri, 22 May 2015 07:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxxaBbBNsykG for ; Fri, 22 May 2015 07:27:09 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0D71ACCC7 for ; Fri, 22 May 2015 07:27:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 45601D9303; Fri, 22 May 2015 16:27:08 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fYBGsjH+UKCK; Fri, 22 May 2015 16:27:08 +0200 (MEST) Received: from [192.168.178.33] (x4d02e54e.dyn.telefonica.de [77.2.229.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id DD8CBD9302; Fri, 22 May 2015 16:27:07 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <7213000C-789D-432C-A954-9EA82AC7EA0C@netapp.com> Date: Fri, 22 May 2015 16:27:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> <7213000C-789D-432C-A954-9EA82AC7EA0C@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "hops@ietf.org" , Brian Trammell Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:27:11 -0000 Hi Lars, thanks, that=E2=80=99s absolutely in line with what we have in mind. We = see a to of activity and interest at the moment and potential for a = longer-term research group. However, you can never say if people will be = able to actually release data and how and so we would like to have a few = meeting and see if we ca come up with continuous work we would like to = do here. Mirja > Am 22.05.2015 um 16:19 schrieb Eggert, Lars : >=20 > Hi again, >=20 > I should probably clarify that I'm *not* pushing back on you guys = having a meeting in Prague and possibly later IETFs to see if a = community forms. I will definitely approve rooms. >=20 > Take my comments as early feedback on the charter text you sent. The = actual chartering discussion will happen after you've tried to meet a = few times and we see what has happened in those meetings. >=20 > Lars >=20 > On 2015-5-22, at 16:06, Eggert, Lars wrote: >> On 2015-5-22, at 15:46, Mirja K=C3=BChlewind = wrote: >>> there are people from RIPE who are interested in this work and were = already at the BarBoF. Further we are also in contact which the people = from CAIDA. And, as you can see on the agenda, we are also talking to = Google and Akamai with people who were also at the BarBoF >>=20 >> so that's promising, but not actually a large number of folks. I = wonder if a discussion among four groups really needs an RG established. = Isn't this something that might as well be handled ad hoc? >>=20 >> A second concern I have is that the topic here is fairly narrow in = scope ("let's discuss data around how bad middleboxes break things"), = and rather short-lived (i.e., once that is done, the group is done). The = IRTF tries to charter groups that are long-lived and try to tackle = problem areas of substantial size, and I wonder if this is the case = here. >>=20 >> (Since I was not at the bar BOF, I may be fundamentally = misunderstanding something about this proposal. I'm only going on what = is in the charter text proposal.) >>=20 >> Lars >> _______________________________________________ >> hops mailing list >> hops@ietf.org >> https://www.ietf.org/mailman/listinfo/hops >=20 From nobody Fri May 22 07:39:12 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580A31A023E for ; Fri, 22 May 2015 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.831 X-Spam-Level: X-Spam-Status: No, score=-101.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 9R8kfVs74fk6 for ; Fri, 22 May 2015 07:39:08 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 C7CB91A0354 for ; Fri, 22 May 2015 07:39:07 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so49646869wic.0 for ; Fri, 22 May 2015 07:39:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mcYcR6ZyR5+Gw+kyQ3dVFua29BccRwm1b4min+gmgLs=; b=e5uEOQ1j7UklcqWZV4Os18dVAAsSRPu8RAk8ELor8NANPoDv0CsRC/5NZR32xsXutd /1LdJMyVRWNOirCFZqznJRlUdZSDgeNfic2yPLIFYk5TpEGXxg/eUeCkM07N26qJXBk2 p77GAJiCwdYxJHTUwa5ulh44upchAnrTHWvJabxvOV6g4zIQeF3hLkFoIQHJpZXXHkXw B23iHA0SPxIAc67ZYW2d/4rP7C4x9N+737PsLFAZwYj5ZUazUleHFMqZ86L2MoDRvmHJ nhuCXspKefUQQxfgJD6M2JAiiVS2h5wxDIZZ/BfW7NQSXANU4kzjakC3DiFlnCA4Sx+I i8aA== X-Gm-Message-State: ALoCoQkNS5AwgmF1hLK+Y2BhPuyIrfAkJ9L3PWCgDlr4r2JJgQ2CQPNGJAec8nxTOnLd3z3770EM X-Received: by 10.194.205.37 with SMTP id ld5mr16141805wjc.14.1432305546402; Fri, 22 May 2015 07:39:06 -0700 (PDT) Received: from Macintosh-2.local (158.218.221.87.dynamic.jazztel.es. [87.221.218.158]) by mx.google.com with ESMTPSA id x3sm8010792wiy.20.2015.05.22.07.39.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2015 07:39:05 -0700 (PDT) Message-ID: <555F3F7D.6090806@it.uc3m.es> Date: Fri, 22 May 2015 16:38:53 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: hops@ietf.org References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> In-Reply-To: <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:39:11 -0000 I dont think this should be a short lived effort. I mean, at the IETF there is plenty of times that we try to design a protocol or protocol extension and we dont really have the data to perform an informed decision. think the HOPS RG could be a starting point for many protocol design efforts. For instance, in the TCPINC BOF, the question about whether encrypted TCP connection would fly over different ports was raised and there was no data available. (and it was a fundamental question to understand if the whole effort was worthwhile) Similar questions now are raised in TCPM when designing the extended option format. And again, there is little data around (at least for some aspects of it). It would be nice to have a place where people that want to work on design can gather data about what works and what doesnt. It would be nice if that was the HOPS RG, i guess. In other words, one way of doing this is for the HOPS RG t be a venue for people with interesting questions and people who want to measure intersting things (or for people with interesting questions and people who has data that can help them answer the questions) So, imho, something like HOPS is really missing in the IETF protocol design approach. But maybe it is just me. El 22/05/15 a las 16:06, Eggert, Lars escribi: > Hi, > > On 2015-5-22, at 15:46, Mirja Khlewind wrote: >> there are people from RIPE who are interested in this work and were already at the BarBoF. Further we are also in contact which the people from CAIDA. And, as you can see on the agenda, we are also talking to Google and Akamai with people who were also at the BarBoF > so that's promising, but not actually a large number of folks. I wonder if a discussion among four groups really needs an RG established. Isn't this something that might as well be handled ad hoc? > > A second concern I have is that the topic here is fairly narrow in scope ("let's discuss data around how bad middleboxes break things"), and rather short-lived (i.e., once that is done, the group is done). The IRTF tries to charter groups that are long-lived and try to tackle problem areas of substantial size, and I wonder if this is the case here. > > (Since I was not at the bar BOF, I may be fundamentally misunderstanding something about this proposal. I'm only going on what is in the charter text proposal.) > > Lars > > > _______________________________________________ > hops mailing list > hops@ietf.org > https://www.ietf.org/mailman/listinfo/hops From nobody Fri May 22 07:40:08 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E951A0354 for ; Fri, 22 May 2015 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcrBJ-3vXNOm for ; Fri, 22 May 2015 07:40:04 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9FCE1B2C10 for ; Fri, 22 May 2015 07:40:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 94BF5D9303; Fri, 22 May 2015 16:40:02 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w30v0P2sm9eR; Fri, 22 May 2015 16:40:02 +0200 (MEST) Received: from [192.168.178.33] (x5f70196a.dyn.telefonica.de [95.112.25.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 3E893D9302; Fri, 22 May 2015 16:40:02 +0200 (MEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> Date: Fri, 22 May 2015 16:40:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "hops@ietf.org" , Brian Trammell Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:40:07 -0000 Hi Lars again, one more point: it=E2=80=99s not only these four groups.=20 There was quite a large number of people at the BarBoF and we had some = really good discussion. Initially the goal for the barBoF was not at all = to start a research group. We actually only wanted to find a way to = integrate passive measurements into e.g. browser traffic as those = application often already perform certain fallbacks and so on to find a = working connection. In these cases it would have been simply nice to = collect =E2=80=9Areports=E2=80=98 about failures that were experienced = in operation. This would be a much more limited scope and would not need = a research group.=20 However, there was much broader interest in middlebox measurements at = the barBoF and we do think that it would be nice to have an official = discuss forum for this work. We=E2=80=99ve only discussed with the = mention people to far to organize a potential first meeting and I think = we already have more people that are interest and will to present = something that we have time in the first meeting. Further as the goal is = to make measurement more comparable by using a common data format, we = see it as our task to actively invite further people doing measurements = and therefore provide a connection between research and the IETF. Mirja =20 > Am 22.05.2015 um 16:06 schrieb Eggert, Lars : >=20 > Hi, >=20 > On 2015-5-22, at 15:46, Mirja K=C3=BChlewind = wrote: >> there are people from RIPE who are interested in this work and were = already at the BarBoF. Further we are also in contact which the people = from CAIDA. And, as you can see on the agenda, we are also talking to = Google and Akamai with people who were also at the BarBoF >=20 > so that's promising, but not actually a large number of folks. I = wonder if a discussion among four groups really needs an RG established. = Isn't this something that might as well be handled ad hoc? >=20 > A second concern I have is that the topic here is fairly narrow in = scope ("let's discuss data around how bad middleboxes break things"), = and rather short-lived (i.e., once that is done, the group is done). The = IRTF tries to charter groups that are long-lived and try to tackle = problem areas of substantial size, and I wonder if this is the case = here. >=20 > (Since I was not at the bar BOF, I may be fundamentally = misunderstanding something about this proposal. I'm only going on what = is in the charter text proposal.) >=20 > Lars From nobody Fri May 22 07:43:56 2015 Return-Path: X-Original-To: hops@ietfa.amsl.com Delivered-To: hops@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0B61A01BA for ; Fri, 22 May 2015 07:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1wspFXF-j-w for ; Fri, 22 May 2015 07:43:54 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D319F1A0163 for ; Fri, 22 May 2015 07:43:53 -0700 (PDT) Received: from [206.123.31.98] (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9AD1645D10; Fri, 22 May 2015 10:43:55 -0400 (EDT) From: "Marc Blanchet" To: "marcelo bagnulo braun" Date: Fri, 22 May 2015 10:43:42 -0400 Message-ID: <8F66DB52-438A-4F4B-8BD1-666391F28DA9@viagenie.ca> In-Reply-To: <555F3F7D.6090806@it.uc3m.es> References: <6A2D3D6E-672B-40D9-9FA8-2D8C5A931461@netapp.com> <247E1336-C757-43C6-8D3F-75EA2B91FDB0@tik.ee.ethz.ch> <11548E99-061E-454D-8014-9FA4B5D620FF@netapp.com> <555F3F7D.6090806@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate Trial (1.9.1r5084) Archived-At: Cc: hops@ietf.org Subject: Re: [hops] Proposal for HOPS RG X-BeenThere: hops@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Measuring deployability of new transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 14:43:55 -0000 On 22 May 2015, at 10:38, marcelo bagnulo braun wrote: > I dont think this should be a short lived effort. > I mean, at the IETF there is plenty of times that we try to design a > protocol or protocol extension and we dont really have the data to > perform an informed decision. think the HOPS RG could be a starting > point for many protocol design efforts. > For instance, in the TCPINC BOF, the question about whether encrypted > TCP connection would fly over different ports was raised and there was > no data available. (and it was a fundamental question to understand if > the whole effort was worthwhile) > Similar questions now are raised in TCPM when designing the extended > option format. And again, there is little data around (at least for > some aspects of it). agree. others I can think of, such as multi path tcp, many rai protocols, > It would be nice to have a place where people that want to work on > design can gather data about what works and what doesnt. It would be > nice if that was the HOPS RG, i guess. > > In other words, one way of doing this is for the HOPS RG t be a venue > for people with interesting questions and people who want to measure > intersting things (or for people with interesting questions and people > who has data that can help them answer the questions) > > So, imho, something like HOPS is really missing in the IETF protocol > design approach. But maybe it is just me. not. count me in! deployability has not been so much considered. Many protocols have been designed and then a fallback to http/443 was added later which makes the protocol brittle. Marc. > > > > > El 22/05/15 a las 16:06, Eggert, Lars escribió: >> Hi, >> >> On 2015-5-22, at 15:46, Mirja Kühlewind >> wrote: >>> there are people from RIPE who are interested in this work and were >>> already at the BarBoF. Further we are also in contact which the >>> people from CAIDA. And, as you can see on the agenda, we are also >>> talking to Google and Akamai with people who were also at the BarBoF >> so that's promising, but not actually a large number of folks. I >> wonder if a discussion among four groups really needs an RG >> established. Isn't this something that might as well be handled ad >> hoc? >> >> A second concern I have is that the topic here is fairly narrow in >> scope ("let's discuss data around how bad middleboxes break things"), >> and rather short-lived (i.e., once that is done, the group is done). >> The IRTF tries to charter groups that are long-lived and try to >> tackle problem areas of substantial size, and I wonder if this is the >> case here. >> >> (Since I was not at the bar BOF, I may be fundamentally >> misunderstanding something about this proposal. I'm only going on >> what is in the charter text proposal.) >> >> Lars >> >> >> _______________________________________________ >> hops mailing list >> hops@ietf.org >> https://www.ietf.org/mailman/listinfo/hops > > _______________________________________________ > hops mailing list > hops@ietf.org > https://www.ietf.org/mailman/listinfo/hops