[re-ECN] Congestion Transparency (re-ECN) ad hoc BoF @Stockholm IETF

Bob Briscoe <rbriscoe@jungle.bt.co.uk> Wed, 22 July 2009 18:04 UTC

Return-Path: <rbriscoe@jungle.bt.co.uk>
X-Original-To: re-ecn@core3.amsl.com
Delivered-To: re-ecn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6973A6C11 for <re-ecn@core3.amsl.com>; Wed, 22 Jul 2009 11:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.33
X-Spam-Level:
X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ7gMduO1dmq for <re-ecn@core3.amsl.com>; Wed, 22 Jul 2009 11:04:44 -0700 (PDT)
Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C85E33A6C25 for <re-ecn@ietf.org>; Wed, 22 Jul 2009 11:03:54 -0700 (PDT)
Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 19:00:58 +0100
Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 19:00:57 +0100
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1248285657407; Wed, 22 Jul 2009 19:00:57 +0100
Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n6MI0s9a006678 for <re-ecn@ietf.org>; Wed, 22 Jul 2009 19:00:54 +0100
Message-Id: <200907221800.n6MI0s9a006678@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 22 Jul 2009 19:00:39 +0100
To: re-ECN unIETF list <re-ecn@ietf.org>
From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
X-OriginalArrivalTime: 22 Jul 2009 18:00:57.0755 (UTC) FILETIME=[5D54C6B0:01CA0AF6]
Subject: [re-ECN] Congestion Transparency (re-ECN) ad hoc BoF @Stockholm IETF
X-BeenThere: re-ecn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/re-ecn>
List-Post: <mailto:re-ecn@ietf.org>
List-Help: <mailto:re-ecn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/re-ecn>, <mailto:re-ecn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2009 18:04:51 -0000

Folks,

I'd like to get together people who might be interested in helping 
organise a BoF on Congestion Transparency (re-ECN) for a future IETF.

15:00 - 16:30 CET Thu 30 Jul Rm 501 @ Stockholm IETF conference venue

Pls give ideas for agenda items (I will too).

This isn't intended to be a general show-and-tell - it's mainly for 
people interested in helping/reviewing/discussing plans for a BoF to 
form an IETF working group. This should complement the design team 
work going on in ICCRG on a new capacity sharing architecture for the 
Internet. <http://trac.tools.ietf.org/group/irtf/trac/wiki/CapacitySharingArch>

For those who won't be able to attend (and those who will), this list 
would also be a fine place to start discussions.

The main idea is to get some protocol specification activity going 
around re-ECN. Probably initially experimental track. So we can make 
some practical progress. But there is also room for writing docs 
about uses of congestion transparency and so on.

My colleague Alan Smith has (finally) got the green light from our 
employers to open source the Linux kernel code he has written. And 
there are two implementations in ns2 that I know of, with another two 
being planned. So we ought to be making sure the spec becomes truly 
common property and starts to evolve to commonly agreed requirements.

That means we have to be open to any changes, including using 
better/different fields in protocol headers, choosing a different 
name, and so on. But the most important thing is to make some 
practical progress.



Bob


________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research