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
>