Re: [E-impact] Metrics for E-Impact and Sustainability -- Summary and Next Steps

Hesham ElBakoury <helbakoury@gmail.com> Fri, 16 June 2023 10:29 UTC

Return-Path: <helbakoury@gmail.com>
X-Original-To: e-impact@ietfa.amsl.com
Delivered-To: e-impact@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8F5C151B16 for <e-impact@ietfa.amsl.com>; Fri, 16 Jun 2023 03:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPYNL5pCeDDg for <e-impact@ietfa.amsl.com>; Fri, 16 Jun 2023 03:29:12 -0700 (PDT)
Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2998CC15108A for <e-impact@ietf.org>; Fri, 16 Jun 2023 03:29:12 -0700 (PDT)
Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-25bf7568f73so467951a91.2 for <e-impact@ietf.org>; Fri, 16 Jun 2023 03:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686911351; x=1689503351; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hQzAC+CYJOXbfKjmaNsGoOVb4tA94RH8VuujtPR9XnU=; b=Tc7IByvPgFJmx3CDcgcF1A6Fp4z+xEkti7CUJPK/DtCIZyk8o/fpUtSt1TA6YZ6pau tZVyVz7MKYwlZx+VBr4bDJYa6OX/J64ZIaUEz4vT/oPwdp3OMtBDYq2zcxN+o2lQiEZ9 XMggeaQmdacuYVkovJD2W8lIETwgQm0v+7fpgIyJ+EzxBAoj8mnBedBWPz0ErCGRB9za /ayLSiXMEZUiCKcom641vMbbPqR71/46gyeUw6Cujso/rLCO5+p9VJqNOrKu/8BJ98yQ 7wFseTxNFEB/1PbOxF+ipGuib8lIEE1btVEi2by2YPwuCiUD7aIjwLnJDU0UlhMtRa3s ykRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686911351; x=1689503351; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hQzAC+CYJOXbfKjmaNsGoOVb4tA94RH8VuujtPR9XnU=; b=FnQnSmhC9pcC5Sh5PADDG6oQCLhtpglYS7KZyoPJ6n2QIzETISSz7ShpLsjA+Dd88O OLQGJqjqvFBjuq1wscKNC1hEF3bfxomonG+san46gIvjFyXXok69M6X5UgUwzK3r5Rtk 8xLNPM0mbBARv8aJWXZfh9uvurQ2k5HjdBwe8OzMq4pi6vX63/xuStUF+mm7oo9YLuus DGQFnCJ2xtOZjkkRF709xTMtXcaDXmi5eFrXKAEQ8lm9ln7pT0u/e76zzWAZ/xabeiUF jRIHN32iWxEHl4Zbbspq97CWgxS8V3iDA5smMUPQYFOzln5X2Yv+y+/JAZEPc5FPdoej AD+Q==
X-Gm-Message-State: AC+VfDxMOzH6Pyr28Mz5puvlU9D4/fgpqiyIUkHUQqT7vV6TeDmZevtO l/Kn2bp0LFl4vRJABmCpH8rqzE9h1IBTSsjyB00B8oK3
X-Google-Smtp-Source: ACHHUZ5QbwHAvj2T3Nac8ciRHQ3hShU94WuhIFaBIuKVwVIyfghrHhOhLU9G8Hw40yNToRFuYff822JmaZ1JUPLkWKE=
X-Received: by 2002:a17:90b:3e8e:b0:25e:ae28:ea64 with SMTP id rj14-20020a17090b3e8e00b0025eae28ea64mr1426202pjb.23.1686911351085; Fri, 16 Jun 2023 03:29:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAPWZuK=9jgfH5b6Crfxd7yds=+gzus=6rm9M82hH9++-9nTMmA@mail.gmail.com> <E3ED7DBE-2EFF-4A45-B0B7-70B427A25CB5@id3as.co.uk> <bc7587fc-02b0-dc54-c221-abe70bd83197@ethz.ch> <000E5159-7648-43C7-AC11-603D8B07B75E@cisco.com>
In-Reply-To: <000E5159-7648-43C7-AC11-603D8B07B75E@cisco.com>
From: Hesham ElBakoury <helbakoury@gmail.com>
Date: Fri, 16 Jun 2023 03:28:59 -0700
Message-ID: <CAFvDQ9pPVhHWP3K7nu1joVQ-6p5Emtw8jpu1+LtYzX1rHaww6g@mail.gmail.com>
To: "Carlos Pignataro (cpignata)" <cpignata=40cisco.com@dmarc.ietf.org>
Cc: Romain Jacob <jacobr@ethz.ch>, e-impact@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d95fe205fe3ca78f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/3HTsgOABFLbv24JUQyDwLACJQ-4>
Subject: Re: [E-impact] Metrics for E-Impact and Sustainability -- Summary and Next Steps
X-BeenThere: e-impact@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Environmental impacts of the Internet <e-impact.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e-impact>, <mailto:e-impact-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e-impact/>
List-Post: <mailto:e-impact@ietf.org>
List-Help: <mailto:e-impact-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e-impact>, <mailto:e-impact-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jun 2023 10:29:16 -0000

The following 3 documents are relevant to this discussion.

"*Measurement and modeling the power consumption of router interface"* [
https://ieeexplore.ieee.org/document/6779082] It uses CISCO 7609 edge
router to evaluate the effect of the packet size and the routing protocols
onto the power consumption of an edge router interface.
The diagrams shows the power consumption of router interface by calculating
the  difference between the idle state power and the measured power.

"*Energy Benchmarks: A Detailed Analysis*"
[
https://www.researchgate.net/publication/221561404_Energy_benchmarks_A_detailed_analysis]
It describes computer systems (e.g. servers) benchmarking metrics that are
developed by standard organizations such as Transaction Processing
Performance Council (TPC) where TPC-Energy uses metrics such as *Watts per
Performance*.

ITU-T L.1310 "*Energy metrics and measurements methods for
telecommunication equipment"*

Hesham

On Thu, Jun 15, 2023, 9:51 AM Carlos Pignataro (cpignata) <cpignata=
40cisco.com@dmarc.ietf.org> wrote:

> Hi, Romain, Dom,
>
> On Jun 15, 2023, at 3:21 AM, Romain Jacob <jacobr@ethz.ch> wrote:
>
> Hi Dom,
>
> I think you make an important point: we must differentiate between
> proportionality in _traffic_  and _network capacity._
>
>
> This is indeed a crucial distinction, which was conflated (at least in
> some of the language *I* used for descriptions). Although I was thinking
> about _traffic_ and _capacity_ distinctively, likely I used some
> amalgamating terms.
>
> (Which, BTW, reminds me that capturing these terms in a draft would be
> most valuable to cite cross-area)
>
> And borrowing this reply to also checkpoint, these are some of what I saw
> (adds/corrections welcome)
> * Energy / (max) network capacity —> device or admin domain level?
> * Energy / traffic (e.g., as used by Operators in EU) —> useful to
> understand no-traffic, mean-traffic, and max-traffic points? (Math “mean”
> and not as in unkind :-)
> * Energy / port; Energy / user —> Rudolf, checking that was what you meant.
> * Important point re/ Servers (thanks Michael) —> I did not translate to a
> metric.
>
> Thanks!
>
> Carlos Pignataro (He/Him)
>
> I've been arguing for research to improve energy proportionality within
> the network (L2 and L3). But what I have in mind is not "reducing the
> traffic volume to save energy" (as pointed out many times, there are only
> little gains here). Rather, I'm thinking about "dynamic capacity
> modulation" in ways that yield energy savings.
>
> What I mean by "capacity modulation" is, e.g., turning off ports when you
> don't need them. Another example is adjusting the capacity of the
> transceivers (e.g., by changing the modulation scheme, use fewer
> frequencies/wavelengths, playing with the laser power, etc.). It's really
> unclear how much savings this can yield, but I think it's worth
> considering. I've done some initial research in that direction; the first
> results will be presented at HotCarbon in a couple of weeks (I'm working on
> the final paper at the moment).
>
> [ And thanks Carlos for the constructive warp-up! ]
>
> Best,
> --
> Romain
> On 15/06/2023 09:02, Dom Robinson wrote:
>
> This cisco blog talks about ‘G’
>
> Looks to me like Gbps. If so its a measure of capacity provisioning not
> traffic use. It would only be comparable to GB at 100% utilisation. At 100%
> utilisation there is no ‘proportionality’ anyway so its a distraction to
> infer that that report correlates traffic to energy.
>
> This collective attempt to find traffic / energy proportionality ‘at all
> costs’ seems lazy. Why do we NEED to wed our energy efficiency to designs
> revolving around data optimisation?
>
> Is it because economic systems are prolific that measure data transfer for
> billing and its then easy / lazy to conjure some CO2 correlation? Certainly
> i believe this is part of the appeal. Its a quick (apparent) win.
>
> I now an convinced that ‘NOT sending data does NOT save any energy’ in
> transmission networks. The energy quanta scales with provisioning capacity.
> No one anywhere has convinced me otherwise.
>
> I am and remain wide open to being convinced.
>
> But no one has.
>
> A further part of the problem is conflating layers. Layer 4 has high
> energy proportionality but in IETF terms that is the ‘ends’ of the
> end-to-end principle and out of scope.
>
> Layer 3 (IETF home land) is abstract and exists conceptually but is really
> a point of interop between layer 2 and 4.
>
> Layer 2 is variable. Some radio network have a proportionality with on /
> off but in practice the requirement for 24/7 signal path availability
> generally means the on time dominates.
>
> And layer 1 is all about CO2e which is a)certainly capacity provisioning
> related and not traffic-elastic and b) something of a different
> conversation from an IETF ‘protocol development’ perspective.
>
> So until someone highlights a good report showing any energy
> proportionality with traffic I remain focussed on how we are provisioning
> capacity to layer3 rather than on ‘reducing traffic’.
>
> However I also think that there is MUCH that is energy proportional in
> Layer 4: Not encoding. Not storing. Not background pre-processing.. all
> these ‘nots’ DO reduce energy requirements and measurably.
>
> However they are not proportional to traffic signalled over the internet
> in Layer3.
>
>
>
> --
> Dom Robinson
> www.id3as.co.uk
> www.greeningofstreaming.org
> uk.linkedin.com/in/domrobinson
> Meet >> https://calendly.com/id3as
>
> On 15 Jun 2023, at 02:12, Rudolf van der Berg <rudolfvanderberg@gmail.com>
> <rudolfvanderberg@gmail.com> wrote:
>
> 
> That i shouldn't respond this late on a mobile phone. Too many errors and
> mixed temperature and traffic in one sentence
>
> But first proposal; please get us some real data on energy use of
> equipment and show what effect several parameters have on energy use
>
> Op do 15 jun. 2023 02:58 schreef Carlos Pignataro (cpignata) <
> cpignata@cisco.com>:
>
>> So the useful proposal is?
>>
>> More later as well :-)
>>
>> Carlos Pignataro (He/Him)
>>
>> On Jun 14, 2023, at 8:54 PM, Rudolf van der Berg <
>> rudolfvanderberg@gmail.com> wrote:
>>
>> Thanks!! This is awesome. It is also way past my bed time, so I will
>> respond later. I do see I wrote traffic lights, where I meant street
>> lighting! That said it is about their energy use, which certainly for most
>> street lights is not proportional to traffic and likely not much either for
>> traffic lights, though maybe with some demand response systems it might
>> affect the distribution of red, green and orange and their number.
>>
>> When it comes to cat videos, given that they form much of what some
>> family members communicat(e) some people lack an understanding of utility
>> functions, cats trump IAB any day of the week. It is not up to us to
>> clarify bits. It is my ISPs job to push them and respect my privacy and net
>> neutrality and certainly not to assume what is valuable. If your net worth
>> beats Grumpy Cat or Taylor Swift's cat than maybe what you do may be more
>> valuable than cat videos. So no the point of the Internet is not to push
>> bits. It is to interconnect. To be connected. The amount of bits and how
>> they are pushed is not relevant for the value of being connected. a PSTN
>> line was powered 24/7 for good reason. So is my parents FTTH or my FTTH.
>>
>> So yes relating these to desired effect is to relate them to being
>> connected. What the bits are and do and your opinion of the context of the
>> bits is irrelevant (and should you actually peek in the packets, a criminal
>> offense) So if you look for a metric relative to something, try per user or
>> port.
>>
>> With regards to there being absolutely no correlation between bita
>> transferred and energy consumption, you caught me, I was using a style
>> figur, known as a hyperbole. I had hoped that someone, maybe at a router
>> manufacturer (Juniper, Nokia, Arista etc.) would actually show real data on
>> how power use of a router varies under load in real life situations. I used
>> to use this Cisco report that said energy use under load vs idle was at
>> most 20W, which was 1% for A 6509 with 150 ports, but it is old and it may
>> just not be the case anymore.
>>   Cisco 6509 energy.pdf
>> <https://drive.google.com/file/d/1isfRXxVnXdZycyMx2-slubPbMutsqBYc/view?usp=drivesdk>
>> But pls point me to resources that have better data. The blog you point
>> to doesn't provide data. I can't see what relative effects are and how this
>> is affected by traffic shifted over a day, peak levels and duration of
>> use,  traffic load, number of users, outside temperature, humidity or
>> geographic spread.
>>
>> With regards to logical fallacy. Of geographic spread causes such
>> differentiation that the statistics aren't comparable between operators,
>> than would it not be realistic for us to factor that in into the metrics?
>> Maybe the IAB can advise people to all live in a country as densily
>> populated as the Netherlands. However, even if geography determines energy
>> use, I would still like to have the relatie impact of traffic levels in
>> this equation too! I also take negative correlations, such as the one where
>> KPN lowered energy use by 50 over the last decade, but increased traffic 20
>> times!!  I am also willing to admit defeat and incompetence If you show
>> that yes overall energy flow decreased but all of that was from electricity
>> use of peripheral systems and not the actual network it self.
>>
>> How comparability is a logical fallacy is beyond me and defies every
>> tenet of methods and techniwques of academic social science research I had
>> in my freshman year. It is exactly by comparing whether the same traffic as
>> well as different levels of traffic on the same network or other networks
>> under differing conditions actually changes the results. eg; when traffic
>> is the same in same nerworke and difference in temperature is 5 degrees, if
>> energy use changes, we can attribute the changes to traffic.if traffic
>> grows 20% and energy use is same at the same temp as well as the higher
>> temp, then traffic may not be relevant. Or we may see minimal changes in
>> energy use etc. You know, like in the Cisco article where energy use per
>> capacity is not stable across routers of varying sizes, which suggests
>> capacity is only one, but not very dominant factor...
>>
>> More to come later
>>
>> Op do 15 jun. 2023 00:23 schreef Carlos Pignataro (cpignata) <cpignata=
>> 40cisco.com@dmarc.ietf.org>:
>>
>>> Hi, E-impact,
>>>
>>> After re-reading and parsing through the thread
>>> <https://mailarchive.ietf.org/arch/msg/e-impact/t9lzF7j2DQWi4EDp7Pe2JKlcQdg/>,
>>> I wanted to offer a summary set of highlights and observations, hopefully
>>> with a bias towards usefulness to the IETF-driven outcomes, removing
>>> underlying assumptions, and way finding common grounds and next steps.
>>>
>>>
>>> *Desired effect, resources, and comparability: *
>>>
>>> On May 15, 2023, at 5:35 PM, Rudolf van der Berg <
>>> rudolfvanderberg@gmail.com> wrote:
>>>
>>> Ok, I will be pedantic... efficient is defined as achieving a desired
>>> effect while not wasting resources.
>>>
>>>
>>> First, if a key desired effect of the Internet (roughly paraphrasing §2
>>> of RFC 3935) is achieving various types of communications between parties
>>> connected to it, bits and traffic are a vehicle towards that goal. Avoiding
>>> here the judgement or qualification of usefulness just yet — Michael
>>> Richardson rightly pointed out that Spam and cat videos are not of the same
>>> usefulness value. So, packets/bits pushed is an important outcome.
>>>
>>
>>> On May 15, 2023, at 5:36 PM, Dom Robinson <dom@id3as.co.uk> wrote:
>>>
>>> “ kWh consumption by operator is somewhat meaningless as well”
>>>
>>> I have to disagree with that, since the absolute amount of energy that
>>> they use, regardless of the number of subscribers or distribution, is it
>>> direct measure in the drain on energy resources.
>>>
>>>
>>> Also, electrical energy is a key resource — and for now also not
>>> considering emission factors, etc., as Lars had suggested the ‘all is bad’
>>> approach for simplicity.
>>>
>>> From these two points, I would consider it not unreasonable to ratio
>>> resources per unit of desired effect — even starting at the network level.
>>>
>>> Taking this as a (potentially unpolished) start, there seem to be at
>>> least a couple of conflicting points, primarily or summed up as
>>>
>>> On May 15, 2023, at 3:26 PM, Rudolf van der Berg <
>>> rudolfvanderberg@gmail.com> wrote:
>>>
>>> the simple reality is that energy use and data traffic have no
>>> correlation in fixed and mobile broadband networks. It is like measuring
>>> the efficiency of cars based on wiper fluid use. Or traffic lights energy
>>> use based on the number of cars that drive by.
>>>
>>>
>>> The first sentence here expresses an absolute that does not match my
>>> experience. While clearly the relationship is not linear with zero
>>> intercept, the blog
>>> <https://blogs.cisco.com/sp/assessing-the-real-world-environmental-impact-of-routers> referenced
>>> before explains how, within a networking device, router, switch, etc.,
>>> different modules have different characteristics of power consumption.
>>>
>>>    - Some require constant power independent of traffic flow — but can
>>>    be turned off in the absence of traffic
>>>    - Some are simply idle power and independent of traffic load
>>>    - Some are dependent of packet load (pps)
>>>    - Others correlate to and are a function of bit load and bandwidth
>>>    (bps)
>>>
>>>
>>> Now, this tells me there is *some* correlation — might not be linear
>>> with zero intercept, but there is some. Even if idle power is a high
>>> percentage, there’s a variable depending on data traffic.
>>>
>>> The danger of making ~ “no correlation” bold absolute statements, is
>>> that a simple counter-example and #houseofcards...
>>>
>>> [as an aside, knowing nothing about traffic light planning, but I can
>>> find sensibility in the relationship between traffic lights🚦and number of
>>> cars 🚗 driving by, and would not ridicule such measuring of the efficiency
>>> of a traffic light system — more 🚗🚙🚕🏎️ for a single 🚥 versus 🚦🚦🚦🚦]
>>>
>>> Op ma 15 mei 2023 17:25 schreef Rob Wilton (rwilton) <rwilton@cisco.com
>>> >:
>>>
>>>> I struggle to understand how “traffic and energy use are in no way and
>>>> have never been related”.
>>>>
>>> I struggled as well…
>>>
>>> On May 15, 2023, at 3:26 PM, Rudolf van der Berg <
>>> rudolfvanderberg@gmail.com> wrote:
>>>
>>> As I explained there is no scientific basis for the metric. If you look
>>> at the work by professor Manner, you will see that using the metric to make
>>> prognosis about the Finnish mobile networks electricity use leads to
>>> estimates 3 times higher than the official figures.
>>>
>>>
>>> The issue of comparability seems to be the fallacy on the logic.
>>>
>>> As it was mentioned already by many, same traffic on a more geo
>>> spread-out network, versus a dense metro network versus Ecuador versus
>>> Canada temperatures versus…
>>>
>>>
>>> On May 26, 2023, at 3:52 AM, Dom Robinson <dom@id3as.co.uk> wrote:
>>>
>>> I agree that taking an holistic view is paramount.
>>>
>>> +
>>>
>>> On Jun 9, 2023, at 10:12 AM, Romain Jacob <jacobr@ethz.ch> wrote:
>>>
>>> We discussed several times on this mailing list that we have a rather
>>> poor understanding of the energy consumed by switches and routers depending
>>> on their load and configuration. One way to address this problem is to
>>> perform "black box" measurement of the power drawn by such device and fit a
>>> power model for it.
>>>
>>>
>>> One thing I’d expect we might agree is that the problem space is highly
>>> complex, brutally interdependent, and deeply nuanced.
>>> In this, RFC 1925, truth #5 came to mind.
>>>
>>> Instead of decomposing a routing system, taking a ‘black box’ approach
>>> shows some relationship of traffic <-> energy.
>>> The scope of comparison might be narrow, and as someone suggested could
>>> even be limited to a given deployment as f(time).
>>>
>>> We could define the most realistic variations, including:
>>>
>>>    - kWh/GB Optics excluded
>>>    - kWh/GB including storage to transport, etc.
>>>
>>>
>>> Or:
>>>
>>> On Jun 9, 2023, at 10:12 AM, Romain Jacob <jacobr@ethz.ch> wrote:
>>>
>>>    - energy efficiency, measured as "maximum power consumed divided by
>>>       the maximum capacity"
>>>       - energy proportionality index, capturing how far the device is
>>>       from being perfectly power-proportional to the load: (max_power -
>>>       idle_power)/ max_power
>>>
>>> But:
>>>
>>> On May 15, 2023, at 6:07 PM, Brian E Carpenter <
>>> brian.e.carpenter@gmail.com> wrote:
>>>
>>> All very interesting but how does this help the IETF improve its
>>> protocol designs?
>>>
>>>
>>> Suggesting and anchoring on a small number of relevant metrics, as per
>>> above (as a start), instead of attempting to “ban” others.
>>>
>>> And also benchmarking power measurement.
>>>
>>> Thanks!
>>>
>>> Carlos Pignataro (He/Him)
>>>
>>> --
>>> E-impact mailing list
>>> E-impact@ietf.org
>>> https://www.ietf.org/mailman/listinfo/e-impact
>>>
>>
>> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
>
>
> --
> Romain JACOB
> Postdoctoral Researcher
> ETH Zurich
> Networked Systems Group (NSG)
> Lead: Prof. Laurent Vanbever
> www.romainjacob.net
> @RJacobPartner <https://twitter.com/RJacobPartner>
> @jacobr@discuss.systems <https://discuss.systems/@jacobr>
> Gloriastrasse 35, ETZ G81
> 8092 Zurich
> +41 7 68 16 88 22
> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
>
>
> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
>