Re: [hops] Proposal for HOPS RG

Mirja Kühlewind <> Fri, 22 May 2015 14:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F2211ACCC7 for <>; Fri, 22 May 2015 07:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.91
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z1D-W0h7BDQL for <>; Fri, 22 May 2015 07:25:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AB1EF1A0364 for <>; Fri, 22 May 2015 07:25:10 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74B85D9303; Fri, 22 May 2015 16:25:09 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 7P6JImq8EtzJ; Fri, 22 May 2015 16:25:09 +0200 (MEST)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by (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: <>
Date: Fri, 22 May 2015 16:25:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: "Eggert, Lars" <>
X-Mailer: Apple Mail (2.2098)
Archived-At: <>
Cc: "" <>, Brian Trammell <>
Subject: Re: [hops] Proposal for HOPS RG
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’t 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’t believe that all middleboxes will suddenly disappear or at least not do any ‚stupid‘ 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’s 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’s really not a short-term goal. Maybe we can spell out this part more explicitly in the charter as well.


> Am 22.05.2015 um 16:06 schrieb Eggert, Lars <>om>:
> 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