Re: [hops] Proposal for HOPS RG
Aaron Falk <aaron.falk@gmail.com> Wed, 24 June 2015 20:00 UTC
Return-Path: <aaron.falk@gmail.com>
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 2E3771A8AF6 for <hops@ietfa.amsl.com>; Wed, 24 Jun 2015 13:00:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.001
X-Spam-Level: *
X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 WTc7SZSHWusI for <hops@ietfa.amsl.com>; Wed, 24 Jun 2015 13:00:28 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (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 3E8BF1A8AF9 for <hops@ietf.org>; Wed, 24 Jun 2015 13:00:28 -0700 (PDT)
Received: by iecvh10 with SMTP id vh10so40697314iec.3 for <hops@ietf.org>; Wed, 24 Jun 2015 13:00:27 -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=1tjQ71uI0zbpjgpqshwiVRSK1Y94FkcwgtO8ALrZ0ko=; b=Ey0uyXixv58b/zoVUKRjl3vfj+ojo5jxDLH6KN1YXWKrvAhsvPwjfH/Kfee3e00pUi sH5JZI0qgsOrmC73UP7H+3lvW3Dhwrvbmvbj6FBL8Dhbpnk0mdgF4BWhy1MceHLL4WcD v6Sktteg3s8t+9mmd6tPrfU2eQJM9zQgEKWsJ0a5Lov8hmJurCxjx73ubj4QGaxgoVor glIO7W6Ey0wM9R40OXrOf2VWb88IElCc/G5Ycz0oklL8uF8fn1Ic//A8h0QCIdL5VfdJ kK1whbLzc3ArWseZKG/GF9oVd+YJrgMbQWK/mcoA83VrrFekbfx/O0qQZHghe1O9Hp7q goSA==
MIME-Version: 1.0
X-Received: by 10.42.81.201 with SMTP id a9mr26406690icl.9.1435176027667; Wed, 24 Jun 2015 13:00:27 -0700 (PDT)
Received: by 10.64.59.225 with HTTP; Wed, 24 Jun 2015 13:00:27 -0700 (PDT)
In-Reply-To: <8F66DB52-438A-4F4B-8BD1-666391F28DA9@viagenie.ca>
References: <A8A13A5E-ECF7-475D-A18B-E78E409C16AA@tik.ee.ethz.ch> <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> <8F66DB52-438A-4F4B-8BD1-666391F28DA9@viagenie.ca>
Date: Wed, 24 Jun 2015 16:00:27 -0400
Message-ID: <CAD62q9W9HnX8-ji_MGsikgHduQsTfSugd54CAVHD6Kj-h+zfRw@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: "Eggert, Lars" <lars@netapp.com>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>
Content-Type: multipart/alternative; boundary="90e6ba614ed251c41f051948f586"
Archived-At: <http://mailarchive.ietf.org/arch/msg/hops/2KtICxt0ZtJsm5BDfCLf-B7t7E8>
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 <hops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hops>, <mailto:hops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hops/>
List-Post: <mailto:hops@ietf.org>
List-Help: <mailto:hops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hops>, <mailto:hops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jun 2015 20:00:30 -0000
Lars, Mirja, Brian- Is there any update on this discussion? Has there been a proposal for a HOPS RG BoF in Prague? --aaron On Fri, May 22, 2015 at 10:43 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote: > > > 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 <mirja.kuehlewind@tik.ee.ethz.ch> >>> 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 >> > > _______________________________________________ > hops mailing list > hops@ietf.org > https://www.ietf.org/mailman/listinfo/hops >
- [hops] Proposal for HOPS RG Mirja Kühlewind
- Re: [hops] Proposal for HOPS RG Eggert, Lars
- Re: [hops] Proposal for HOPS RG Mirja Kühlewind
- Re: [hops] Proposal for HOPS RG Eggert, Lars
- Re: [hops] Proposal for HOPS RG Eggert, Lars
- Re: [hops] Proposal for HOPS RG Mirja Kühlewind
- Re: [hops] Proposal for HOPS RG Mirja Kühlewind
- Re: [hops] Proposal for HOPS RG marcelo bagnulo braun
- Re: [hops] Proposal for HOPS RG Mirja Kühlewind
- Re: [hops] Proposal for HOPS RG Marc Blanchet
- Re: [hops] Proposal for HOPS RG Aaron Falk
- Re: [hops] Proposal for HOPS RG Eggert, Lars